How to Build an Antigravity Workflow with the Oracle SQLcl MCP Server and Oracle AI Database

A developer has published a practical guide and companion notebook showing how to connect Antigravity, an MCP-capable AI coding environment, to Oracle AI Database through the Oracle SQLcl MCP server. The workflow uses SQLcl as a declared tool boundary that executes SQL and returns bounded results, keeping large result sets out of the agent context window, while Oracle AI Database stores durable memory records, retrieval evidence, vectors, and tool traces. The guide emphasizes privileges, logging, scoped retrieval, and repeatable runbooks over prompting, and validates lexical, vector, and hybrid retrieval plus Oracle AI Agent Memory initialization.

This article adapts the same MCP workflow pattern for Antigravity and Oracle AI Database. Companion notebook: Antigravity MCP with Oracle AI Database Workflow https://github.com/oracle-devrel/oracle-ai-developer-hub/blob/main/notebooks/antigravity mcp oracle ai database.ipynb The Oracle SQLcl MCP server is useful for Antigravity workflows because database questions can run through a declared local MCP tool instead of being copied into the agent context as raw data. SQLcl executes SQL against Oracle AI Database and returns bounded results, which helps an AI coding agent inspect business data without pulling large result sets into the context window. Antigravity refers to the MCP-capable AI coding environment used as the developer-facing agent interface. In this pattern, Antigravity does not connect directly to Oracle AI Database. Antigravity calls SQLcl MCP tools, SQLcl uses a saved Oracle connection, and Oracle AI Database remains the durable store for memory records, retrieval evidence, vectors, and tool traces. Oracle AI Agent Memory and LangChain sit in the application layer after that database-backed path is in place. Production success depends less on clever prompting and more on boundaries, privileges, logging, scoped retrieval, and repeatable runbooks. This guide is for developers who want Antigravity to work with Oracle AI Database through explicit tools, durable memory, and reviewable retrieval evidence. The developer path through this guide is simple: Database-connected assistants are most useful when the access path is visible. The goal is not just to let Antigravity produce SQL-shaped text; the goal is to make the database path approved, observable, and easy to debug later. Antigravity sits near the developer's real work: code, terminal commands, notebooks, configuration, and implementation details. A developer can move from a failing local flow to a database inspection path inside the same working loop. That closeness is useful, but it also makes the database boundary more sensitive. A practical workflow preserves the request, the tool call, the database identity, the retrieved context, and the reason a risky action was allowed, blocked, or sent for confirmation. By the end of this guide, you should know how to connect Antigravity to Oracle AI Database through a controlled MCP boundary, when local Antigravity context is enough and when Oracle-backed memory is needed, and how to build a retrieval path that can be queried, audited, and scaled. The companion notebook is intentionally practical. It validates SQLcl and Java discovery, writes a sanitized Antigravity MCP config preview, checks the saved SQLcl connection alias, creates memory tables, inserts simulated Antigravity/MCP teaching traces, tests lexical, vector, and hybrid retrieval, initializes Oracle AI Agent Memory with the current configuration shape, and finishes with a validation snapshot. The workflow has five cooperating layers. Antigravity is the developer-facing agent interface. SQLcl MCP is the tool boundary. Oracle AI Database is the durable substrate for memory, traces, and retrieval. Oracle AI Agent Memory is the application-side memory API. LangChain is the optional orchestration wrapper. The companion notebook sits outside all five, as the build-and-validation harness that proves the pieces are wired correctly before the workflow is handed to Antigravity. | Layer | Responsibility | | Antigravity | Developer-facing MCP client and agent interface. | | SQLcl MCP | Exposes declared Oracle tools to Antigravity; it is the tool boundary. | | Oracle AI Database | Stores durable data, retrieval evidence, vectors, metadata, traces, and enforces database privileges. | | Oracle AI Agent Memory | Provides application APIs for users, agents, threads, durable memories, scoped retrieval, and context assembly. | | LangChain | Wraps Oracle-backed retrieval results as Document objects and supports application-side orchestration. | The system naturally forms two execution loops: SQLcl MCP handles live tool use. Oracle AI Agent Memory handles durable memory and scoped recall. Most production setups need both loops, but they solve different problems. The setup should be reproducible. SQLcl runs in MCP mode with sql -mcp . Antigravity launches it as an MCP server and talks to Oracle through declared tools, not through direct access. Connections come from saved SQLcl profiles that you create and test before Antigravity uses them. The AI coding agent should not invent database connections at runtime. It should reuse profiles you have already created and validated. Prerequisites before you connect Antigravity: mcp config.json . ~/.dbtools , created with password persistence for MCP use. The notebook treats the saved SQLcl connection alias as a first-class artifact. In local development, that alias is what lets SQLcl MCP connect without forcing the agent to assemble credentials dynamically. In this notebook, the alias is antigravity mcp . The notebook then generates a sanitized Antigravity MCP config preview. The preview is intentionally safe: it shows the server command and arguments without exposing secrets. It does not overwrite your real Antigravity MCP configuration. For the saved connection itself, the important detail is -savepwd . conn -save antigravity mcp -savepwd <ORACLE USER /<ORACLE PASSWORD @<ORACLE DSN The notebook validates this alias with SQLcl -name antigravity mcp before Antigravity uses it. MCP cannot stop and ask a human for a password each time the agent invokes a database tool. The saved alias becomes the repeatable local path Antigravity can use after you have reviewed it. { "mcpServers": { "sqlcl": { "command": "<STANDALONE SQLCL EXECUTABLE ", "args": "-mcp" } } } That JSON block defines the connection between Antigravity and SQLcl MCP Server. Save it in .agents/mcp config.json for a workspace-scoped setup or ~/.gemini/config/mcp config.json globally, then reload MCP servers from Antigravity's MCP manager. php def default antigravity mcp config path - Path: return Path.home / ".gemini" / "config" / "mcp config.json" preview path = PROJECT ROOT / "antigravity sqlcl mcp config.preview.json" preview path.write text json.dumps mcp config json, indent=2 + "\n", encoding="utf-8" A useful first prompt is intentionally constrained: Use SQLcl MCP to list available saved Oracle connections. Do not run DML or DDL. Validation checklist before expanding access: sql -mcp locally and confirm the server starts. Good first proof looks like this: antigravity tool logs . A useful MCP boundary is more than tool discovery. The notebook models read-only defaults, confirmation requirements, scope checks, and controlled failure examples so denied and warning states are visible. MCP TOOL POLICY = { "list-connections": {"readOnlyHint": True, "risk": "LOW"}, "connect": {"readOnlyHint": True, "risk": "LOW TO MEDIUM"}, "run-sql": {"readOnlyHint": True, "risk": "LOW TO MEDIUM"}, "run-sqlcl": {"readOnlyHint": False, "destructiveHint": True, "risk": "CRITICAL"}, } The notebook is not just setup prose. It produces concrete checkpoints that make the workflow inspectable. The first useful result is a deterministic Antigravity/MCP timeline. The sample data uses explicit event sequence values and simulated event timestamps so the workflow order is stable every time the notebook is rerun: step event kind actor result 1 CONVERSATION user initial support-job request 2 CONVERSATION assistant SQLcl MCP read-only plan 3 MCP TOOL list-connections SUCCESS 4 MCP TOOL run-sql SUCCESS 5 MCP TOOL run-sql DENIED / PRIVILEGE SCOPE 6 CONVERSATION assistant grounded summary That ordering matters because operational memory is only useful if the answer can be traced back to the request, the tool calls, and the permission boundary that shaped the result. The notebook combines lexical search, vector search, and hybrid search so retrieved context can include both exact operational terms and semantic matches. The grounding package also returns visible evidence before the assistant answer is assembled: Status: READY Top evidence: - Saved SQLcl connections for MCP - SQLcl MCP execution boundary - Tool logging baseline - LangChain as orchestration glue If retrieval is empty or too weak, the notebook returns INSUFFICIENT CONTEXT and displays a safe empty-result message instead of trying to select columns from missing evidence. In a fully configured local environment, the final snapshot should show the main layers as ready: Antigravity MCP config generated SQLcl MCP runtime ready SQLcl saved connection ready Oracle AI Database memory ready Oracle AI Agent Memory package ready Lexical search ready Native VECTOR execution path ready Demo embeddings demo ready Hybrid retrieval ready LangChain wrapper ready validation action needed 0 Some rows may show DEMO READY , FALLBACK , OPTIONAL , or ACTION NEEDED depending on SQLcl discovery, catalog privileges, vector support, package availability, and local MCP validation. That is the practical bar for this demo: setup artifacts are generated, SQLcl MCP prerequisites are validated, Oracle memory tables are populated, retrieval works, Agent Memory initializes, and the notebook separates native VECTOR readiness from deterministic demo embeddings. One important boundary in the companion notebook is that the operational records are simulated teaching data. The notebook inserts sample conversation rows and sample tool-log rows to show what a production workflow should preserve: the user's request, Antigravity's plan, tool calls, outcomes, controlled failures, and retrieval evidence. Those rows are not live telemetry captured from Antigravity, and the notebook does not automatically observe, scrape, or stream Antigravity activity. Live Antigravity validation still happens through Antigravity's MCP configuration and the SQLcl MCP server. The notebook proves the database-backed memory, retrieval, and validation pattern around that workflow so the pieces are inspectable and repeatable. The optional live audit cell is separate on purpose. After a real Antigravity plus SQLcl MCP prompt, it tries to inspect DBTOOLS$MCP LOG and V$SESSION module/action metadata. If catalog visibility is unavailable, it reports ACTION NEEDED instead of pretending simulated logs prove live MCP traffic. Once the first MCP tool calls work, the next challenge is continuity. This is where long-term memory for AI agents becomes different from short-lived chat context. If memory lives only in chat context, the system is fragile. If memory is scattered across files without structure, retrieval and auditing become expensive over time. For workflows that need auditability, scoped retrieval, and repeated use across sessions, a database-backed memory model is easier to operate than scattered files or prompt-only context. The companion notebook builds this memory layer from scratch so the mechanics are visible, then shows how Oracle AI Agent Memory sits on top of it once the substrate is working. Memory categories that matter in practice: In practice, hybrid retrieval for agent memory usually combines exact operational terms, such as sql -mcp or antigravity mcp , with semantic search over memory records. The notebook shows the lower-level mechanics first so the storage and retrieval path is visible. This is also a context engineering problem: the application has to decide which memories, tool traces, and retrieval results should be assembled before Antigravity or another assistant answers. Oracle AI Agent Memory then gives application code a higher-level package API over that same database-backed idea. Oracle AI Agent Memory sits between your application code and Oracle AI Database. The package manages conversation threads, durable memory records, scoped retrieval, and context assembly while Oracle AI Database remains the storage layer underneath. The notebook includes an abbreviated package-backed memory pattern. It initializes OracleAgentMemory with a database connection pool and a custom local deterministic embedder. LocalAntigravityEmbedder is notebook code, not a built-in Oracle AI Agent Memory embedder. The local embedder is intentionally billing-free, which makes the notebook runnable for people who do not want to attach paid model usage to a tutorial. In Oracle AI Agent Memory, use MemoryExtractionConfig extract memories=False and memory store id for this notebook's package-backed setup. python from oracleagentmemory.apis.searchscope import SearchScope from oracleagentmemory.core import MemoryExtractionConfig from oracleagentmemory.core.oracleagentmemory import OracleAgentMemory db pool = oracledb.SessionPool user=CONFIG "ORACLE USER" , password=CONFIG "ORACLE PASSWORD" , dsn=CONFIG "ORACLE DSN" , min=1, max=4, increment=1, agent memory = OracleAgentMemory connection=db pool, embedder=LocalAntigravityEmbedder dimensions=32 , llm=None, memory extraction config=MemoryExtractionConfig extract memories=False , schema policy="create if necessary", memory store id="ag oam local", Use oracleagentmemory from your application layer when you need package-managed users, agents, memories, threads, scoped retrieval, and context assembly. Keep systems of record separate from memory records: memory helps provide context, but application logic and authoritative data sources should still decide what is true, allowed, and final. Implementation note: Use a schema whose default tablespace supports the JSON objects created by Agent Memory. For an Antigravity-specific local setup, the notebook now suggests antigravity memory ts and antigravity memory in the sample SQL. CREATE TABLESPACE antigravity memory ts DATAFILE '/opt/oracle/oradata/FREE/FREEPDB1/antigravity memory ts01.dbf' SIZE 200M AUTOEXTEND ON NEXT 100M SEGMENT SPACE MANAGEMENT AUTO; CREATE USER antigravity memory IDENTIFIED BY "CHOOSE A STRONG PASSWORD"; GRANT CREATE SESSION, CREATE TABLE, CREATE SEQUENCE, CREATE VIEW, CREATE PROCEDURE TO antigravity memory; ALTER USER antigravity memory DEFAULT TABLESPACE antigravity memory ts; ALTER USER antigravity memory QUOTA UNLIMITED ON antigravity memory ts; A realistic Antigravity memory is not generic trivia about a user. For this workflow, memory should capture how a developer actually works: the connection name they used, the SQLcl path that succeeded, the MCP config location, the failed privilege boundary, the retrieval query that helped, and the final fix that should be reused later. thread = agent memory.create thread user id=AGENT MEMORY USER ID, agent id=AGENT MEMORY AGENT ID, thread.add memory "Developer validated Antigravity CLI with SQLcl MCP alias antigravity mcp " "against local Oracle AI Database service FREEPDB1." results = agent memory.search query="Antigravity SQLcl MCP alias validation and Agent Memory setup", scope=SearchScope user id=AGENT MEMORY USER ID, agent id=AGENT MEMORY AGENT ID , That kind of memory pays off because it is operational. It can help Antigravity answer the next question with context from a previous debugging session, but it is still scoped and retrievable through a database-backed API. Vector search is part of the Oracle AI Database memory story. In a real application, embeddings usually come from a model and are indexed with Oracle AI Database vector capabilities. The notebook separates two ideas that are easy to accidentally blur: The deterministic embeddings are useful for portability and inspection, but they should not be described as production semantic embeddings. For production, replace the notebook's demo embed or LocalAntigravityEmbedder with a supported embedding model after cost, latency, privacy, and retrieval-quality review. The final notebook snapshot makes this separation explicit with two rows: Native VECTOR execution path and Demo embeddings. LangChain should not be treated as the source of truth. Antigravity does not call LangChain directly in this architecture, and LangChain is not the permission boundary, memory store, or audit layer. In this notebook, LangChain is used as a compatibility layer. The custom Oracle-backed hybrid search path performs retrieval, then the results are wrapped as LangChain Document objects so applications that already expect LangChain interfaces can consume them. By the time LangChain is introduced, the database tables, package memory, retrieval scores, and validation snapshot already exist. LangChain becomes a wrapper around evidence, not a substitute for evidence. python class OracleMemoryRetriever BaseRetriever : def get relevant documents self, query: str : rows = hybrid search query, tenant id="TENANT A", top k=3 return Document page content=row "chunk text" , metadata={"category": row "category" } for , row in rows.iterrows Use it when the consuming application already expects retrievers, documents, chains, or tool orchestration. If the application only needs direct SQL, package-backed Agent Memory search, or a simple evidence table, the extra abstraction can make debugging harder. The difference between demo success and production success is disciplined operations. In this workflow, the first failures to check are usually integration issues: SQLcl discovery, Java runtime, saved connection aliases, database permissions, and retrieval configuration. Access and privilege model: Observability model: Reliability model: Runtime failure: sql -mcp does not start. Check the absolute SQLcl path, confirm Java is available, and run sql -mcp outside Antigravity first. Resolve runtime issues before checking assistant behavior. Discovery failure: Antigravity does not see tools. Check the Antigravity MCP configuration, confirm the configured command points to the SQLcl executable, and reload MCP servers after edits. Connection failure: tools are present but queries fail immediately. Check the saved SQLcl connection alias, confirm the profile lives under the expected SQLcl connection store, and verify password persistence for the MCP workflow. Then test the same connection outside Antigravity. Permission failure: queries execute selectively and fail on specific objects. Check the database role first. A selective failure can be the right outcome when least privilege is working. Add grants intentionally and keep read-write access separate from the initial validation path. Retrieval quality failure: answers are fluent but weakly grounded. Inspect the retrieved records before blaming the model. Check chunk size, metadata filters, embedding choice, top-k settings, and whether the query is asking for exact history, semantic similarity, or operational logs. The hybrid model is not automatically the right answer for every team. It is useful when one workflow needs live tool execution, durable memory, retrieval evidence, and application-side orchestration without forcing one layer to do every job. For simple read-only inspection, direct SQL through the Oracle SQLcl MCP server may be enough. Add Oracle AI Agent Memory when the workflow needs durable scoped recall across sessions. Add LangChain when another application already expects retrievers, documents, or chains. The hybrid approach works because it does not force one layer to do everything. MCP handles live tool execution, Oracle AI Database keeps durable evidence, Oracle AI Agent Memory provides the memory API, and LangChain is added only when the application needs that shape. For this workflow, the value is that the assistant can stay in the developer loop without becoming an unreviewed database actor. Antigravity can help plan, inspect, and explain. SQLcl MCP exposes the database path as tools. Oracle AI Database keeps the durable evidence. An Antigravity and SQLcl MCP workflow becomes useful when it is treated as an engineering pattern, not just a setup trick. Antigravity keeps the developer moving, SQLcl MCP keeps database access explicit, and Oracle AI Database keeps the evidence durable enough to inspect later. The result is a workflow a team can inspect. You can see what Antigravity asked for, which tool path ran, what the database allowed, which memory records were retrieved, and how the final answer was assembled. That is the shift that matters: from assistant access that is implicit and hard to audit, to explicit boundaries, durable memory, and evidence a developer can actually debug. What is MCP in this context? MCP is the protocol boundary that lets Antigravity call explicit tools exposed by a server instead of accessing systems implicitly. What does MCP protect, and what does it not protect? MCP makes the tool interface explicit and reviewable. It does not replace database security. The saved SQLcl connection profile, database user, grants, roles, network controls, and database policies determine what those tools can actually access or change. Why use SQLcl for Oracle MCP? SQLcl already understands Oracle workflows and can run as the Oracle SQLcl MCP server with sql -mcp, making the Oracle integration practical and direct. Why include Oracle AI Database if MCP already works? MCP handles the execution boundary. Oracle AI Database handles durable memory, retrieval, vector search, concurrency, observability, and governance. Do I need an external model API key? Only if you change the notebook to use a provider-backed embedding or LLM service. The default notebook path uses a local deterministic embedder. Why include LangChain if Oracle already stores memory? Many teams already use LangChain-shaped retrievers and chains. The notebook shows how Oracle-backed retrieval can fit that interface. What is the minimum viable setup? SQLcl MCP configured for Antigravity, one safe saved Oracle connection, and a read-only validation flow. Should production start with read-write permissions? Usually no. Start read-only, log everything important, and add write scopes gradually with explicit approvals. What is the best rollout strategy? Pilot in development with read-only access and strong logging, then expand capabilities in controlled phases as the team learns which memory and tool paths are actually useful.