{"slug": "how-to-build-an-antigravity-workflow-with-the-oracle-sqlcl-mcp-server-and-oracle", "title": "How to Build an Antigravity Workflow with the Oracle SQLcl MCP Server and Oracle AI Database", "summary": "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.", "body_md": "This article adapts the same MCP workflow pattern for Antigravity and Oracle AI Database.\n\n**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)** \n\nThe 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.\n\nAntigravity 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.\n\nProduction success depends less on clever prompting and more on boundaries, privileges, logging, scoped retrieval, and repeatable runbooks.\n\nThis guide is for developers who want Antigravity to work with Oracle AI Database through explicit tools, durable memory, and reviewable retrieval evidence.\n\nThe developer path through this guide is simple:\n\nDatabase-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.\n\nAntigravity 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.\n\nA 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.\n\nBy 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.\n\nThe 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.\n\nThe 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.\n\n| **Layer** | **Responsibility** | \n| Antigravity | Developer-facing MCP client and agent interface. | \n| SQLcl MCP | Exposes declared Oracle tools to Antigravity; it is the tool boundary. | \n| Oracle AI Database | Stores durable data, retrieval evidence, vectors, metadata, traces, and enforces database privileges. | \n| Oracle AI Agent Memory | Provides application APIs for users, agents, threads, durable memories, scoped retrieval, and context assembly. | \n| LangChain | Wraps Oracle-backed retrieval results as Document objects and supports application-side orchestration. | \n\nThe system naturally forms two execution loops:\n\nSQLcl 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.\n\nThe 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. \n\nThe AI coding agent should not invent database connections at runtime. It should reuse profiles you have already created and validated.\n\nPrerequisites before you connect Antigravity:\n\n`mcp_config.json`. `~/.dbtools`, created with password persistence for MCP use. \nThe 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`. \n\nThe 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.\n\nFor the saved connection itself, the important detail is `-savepwd`.  \n\n```\nconn -save antigravity_mcp -savepwd <ORACLE_USER>/<ORACLE_PASSWORD>@<ORACLE_DSN>\n```\n\nThe notebook validates this alias with SQLcl -name `antigravity_mcp` before Antigravity uses it. \n\nMCP 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.\n\n```\n{ \n  \"mcpServers\": { \n    \"sqlcl\": { \n      \"command\": \"<STANDALONE_SQLCL_EXECUTABLE>\", \n      \"args\": [\"-mcp\"] \n    } \n  } \n}\n```\n\nThat 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. \n\n``` php\ndef default_antigravity_mcp_config_path() -> Path: \n    return Path.home() / \".gemini\" / \"config\" / \"mcp_config.json\" \n \npreview_path = PROJECT_ROOT / \"antigravity_sqlcl_mcp_config.preview.json\" \npreview_path.write_text(json.dumps(mcp_config_json, indent=2) + \"\\n\", encoding=\"utf-8\")\n```\n\nA useful first prompt is intentionally constrained:\n\n```\nUse SQLcl MCP to list available saved Oracle connections. Do not run DML or DDL.\n```\n\nValidation checklist before expanding access:\n\n`sql -mcp` locally and confirm the server starts. \nGood first proof looks like this:\n\n`antigravity_tool_logs`. \nA 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.\n\n```\nMCP_TOOL_POLICY = { \n    \"list-connections\": {\"readOnlyHint\": True, \"risk\": \"LOW\"}, \n    \"connect\": {\"readOnlyHint\": True, \"risk\": \"LOW_TO_MEDIUM\"}, \n    \"run-sql\": {\"readOnlyHint\": True, \"risk\": \"LOW_TO_MEDIUM\"}, \n    \"run-sqlcl\": {\"readOnlyHint\": False, \"destructiveHint\": True, \"risk\": \"CRITICAL\"}, \n}\n```\n\nThe notebook is not just setup prose. It produces concrete checkpoints that make the workflow inspectable.\n\nThe 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:\n\n```\nstep  event_kind    actor             result \n1     CONVERSATION  user              initial support-job request \n2     CONVERSATION  assistant         SQLcl MCP read-only plan \n3     MCP_TOOL      list-connections  SUCCESS \n4     MCP_TOOL      run-sql           SUCCESS \n5     MCP_TOOL      run-sql           DENIED / PRIVILEGE_SCOPE \n6     CONVERSATION  assistant         grounded summary\n```\n\nThat 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.\n\nThe notebook combines lexical search, vector search, and hybrid search so retrieved context can include both exact operational terms and semantic matches.\n\nThe grounding package also returns visible evidence before the assistant answer is assembled:\n\n```\nStatus: READY \n \nTop evidence: \n- Saved SQLcl connections for MCP \n- SQLcl MCP execution boundary \n- Tool logging baseline \n- LangChain as orchestration glue\n```\n\nIf 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. \n\nIn a fully configured local environment, the final snapshot should show the main layers as ready:\n\n```\nAntigravity MCP config             generated \nSQLcl MCP runtime                  ready \nSQLcl saved connection             ready \nOracle AI Database memory          ready \nOracle AI Agent Memory package     ready \nLexical search                     ready \nNative VECTOR execution path       ready \nDemo embeddings                    demo ready \nHybrid retrieval                   ready \nLangChain wrapper                  ready \nvalidation_action_needed           0\n```\n\nSome rows may show `DEMO_READY`, `FALLBACK`, `OPTIONAL`, or `ACTION_NEEDED` depending on SQLcl discovery, catalog privileges, vector support, package availability, and local MCP validation. \n\nThat 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.\n\nOne 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.\n\nThose 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.\n\nThe 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. \n\nOnce 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.\n\nIf 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.\n\nThe 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.\n\nMemory categories that matter in practice:\n\nIn practice, hybrid retrieval for agent memory usually combines exact operational terms, such as `sql -mcp` or `antigravity_mcp`, with semantic search over memory records. \n\nThe 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.\n\nOracle 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.\n\nThe 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. \n\nThe 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.\n\nIn Oracle AI Agent Memory, use `MemoryExtractionConfig(extract_memories=False)` and `memory_store_id` for this notebook's package-backed setup. \n\n``` python\nfrom oracleagentmemory.apis.searchscope import SearchScope \nfrom oracleagentmemory.core import MemoryExtractionConfig \nfrom oracleagentmemory.core.oracleagentmemory import OracleAgentMemory \n \ndb_pool = oracledb.SessionPool( \n    user=CONFIG[\"ORACLE_USER\"], \n    password=CONFIG[\"ORACLE_PASSWORD\"], \n    dsn=CONFIG[\"ORACLE_DSN\"], \n    min=1, \n    max=4, \n    increment=1, \n) \n \nagent_memory = OracleAgentMemory( \n    connection=db_pool, \n    embedder=LocalAntigravityEmbedder(dimensions=32), \n    llm=None, \n    memory_extraction_config=MemoryExtractionConfig(extract_memories=False), \n    schema_policy=\"create_if_necessary\", \n    memory_store_id=\"ag_oam_local\", \n)\n```\n\nUse `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. \n\nImplementation 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.\n\n```\nCREATE TABLESPACE antigravity_memory_ts \nDATAFILE '/opt/oracle/oradata/FREE/FREEPDB1/antigravity_memory_ts01.dbf' \nSIZE 200M \nAUTOEXTEND ON NEXT 100M \nSEGMENT SPACE MANAGEMENT AUTO; \n \nCREATE USER antigravity_memory IDENTIFIED BY \"CHOOSE_A_STRONG_PASSWORD\"; \nGRANT CREATE SESSION, CREATE TABLE, CREATE SEQUENCE, CREATE VIEW, CREATE PROCEDURE TO antigravity_memory; \nALTER USER antigravity_memory DEFAULT TABLESPACE antigravity_memory_ts; \nALTER USER antigravity_memory QUOTA UNLIMITED ON antigravity_memory_ts;\n```\n\nA 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.\n\n```\nthread = agent_memory.create_thread( \n    user_id=AGENT_MEMORY_USER_ID, \n    agent_id=AGENT_MEMORY_AGENT_ID, \n) \n \nthread.add_memory( \n    \"Developer validated Antigravity CLI with SQLcl MCP alias antigravity_mcp \" \n    \"against local Oracle AI Database service FREEPDB1.\" \n) \n \nresults = agent_memory.search( \n    query=\"Antigravity SQLcl MCP alias validation and Agent Memory setup\", \n    scope=SearchScope(user_id=AGENT_MEMORY_USER_ID, agent_id=AGENT_MEMORY_AGENT_ID), \n)\n```\n\nThat 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.\n\nVector 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.\n\nThe notebook separates two ideas that are easy to accidentally blur:\n\nThe 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. \n\nThe final notebook snapshot makes this separation explicit with two rows: Native VECTOR execution path and Demo embeddings.\n\nLangChain 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.\n\nIn 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. \n\nBy 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.\n\n``` python\nclass OracleMemoryRetriever(BaseRetriever): \n    def _get_relevant_documents(self, query: str): \n        rows = hybrid_search(query, tenant_id=\"TENANT_A\", top_k=3) \n        return [ \n            Document(page_content=row[\"chunk_text\"], metadata={\"category\": row[\"category\"]}) \n            for _, row in rows.iterrows() \n        ]\n```\n\nUse 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.\n\nThe 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.\n\n**Access and privilege model:** \n\n**Observability model:** \n\n**Reliability model:** \n\n**Runtime failure: sql -mcp does not start.** \n\nCheck the absolute SQLcl path, confirm Java is available, and run sql -mcp outside Antigravity first. Resolve runtime issues before checking assistant behavior.\n\n**Discovery failure: Antigravity does not see tools.** \n\nCheck the Antigravity MCP configuration, confirm the configured command points to the SQLcl executable, and reload MCP servers after edits.\n\n**Connection failure: tools are present but queries fail immediately.** \n\nCheck 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.\n\n**Permission failure: queries execute selectively and fail on specific objects.** \n\nCheck 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.\n\n**Retrieval quality failure: answers are fluent but weakly grounded.** \n\nInspect 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.\n\nThe 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.\n\nFor 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.\n\nThe 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.\n\nFor 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.\n\nAn 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.\n\nThe 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.\n\nThat 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.\n\n**What is MCP in this context?** \n\nMCP is the protocol boundary that lets Antigravity call explicit tools exposed by a server instead of accessing systems implicitly.\n\n**What does MCP protect, and what does it not protect?** \n\nMCP 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.\n\n**Why use SQLcl for Oracle MCP?** \n\nSQLcl already understands Oracle workflows and can run as the Oracle SQLcl MCP server with sql -mcp, making the Oracle integration practical and direct.\n\n**Why include Oracle AI Database if MCP already works?** \n\nMCP handles the execution boundary. Oracle AI Database handles durable memory, retrieval, vector search, concurrency, observability, and governance.\n\n**Do I need an external model API key?** \n\nOnly if you change the notebook to use a provider-backed embedding or LLM service. The default notebook path uses a local deterministic embedder.\n\n**Why include LangChain if Oracle already stores memory?** \n\nMany teams already use LangChain-shaped retrievers and chains. The notebook shows how Oracle-backed retrieval can fit that interface.\n\n**What is the minimum viable setup?** \n\nSQLcl MCP configured for Antigravity, one safe saved Oracle connection, and a read-only validation flow.\n\n**Should production start with read-write permissions?** \n\nUsually no. Start read-only, log everything important, and add write scopes gradually with explicit approvals.\n\n**What is the best rollout strategy?** \n\nPilot 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.", "url": "https://wpnews.pro/news/how-to-build-an-antigravity-workflow-with-the-oracle-sqlcl-mcp-server-and-oracle", "canonical_source": "https://dev.to/oracledevs/how-to-build-an-antigravity-workflow-with-the-oracle-sqlcl-mcp-server-and-oracle-ai-database-65p", "published_at": "2026-09-21 14:21:09+00:00", "updated_at": "2026-09-21 14:32:28.952958+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-tools", "developer-tools", "ai-infrastructure"], "entities": ["Oracle", "Oracle SQLcl", "Oracle AI Database", "Antigravity", "Oracle AI Agent Memory", "LangChain", "MCP"], "alternates": {"html": "https://wpnews.pro/news/how-to-build-an-antigravity-workflow-with-the-oracle-sqlcl-mcp-server-and-oracle", "markdown": "https://wpnews.pro/news/how-to-build-an-antigravity-workflow-with-the-oracle-sqlcl-mcp-server-and-oracle.md", "text": "https://wpnews.pro/news/how-to-build-an-antigravity-workflow-with-the-oracle-sqlcl-mcp-server-and-oracle.txt", "jsonld": "https://wpnews.pro/news/how-to-build-an-antigravity-workflow-with-the-oracle-sqlcl-mcp-server-and-oracle.jsonld"}}