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

This article adapts the same MCP workflow pattern for Antigravity and Oracle AI Database.

Companion notebook: Antigravity MCP with Oracle AI Database Workflow

Key Takeaways

• MCP turns AI-to-database access into an explicit tool contract instead of implicit system access.
• Oracle SQLcl in MCP mode, sql -mcp, is a practical way to connect Antigravity to Oracle AI Database through a local MCP server.
• Oracle AI Database provides persistent storage and vector search for memory workloads, while Oracle AI Agent Memory gives teams Python APIs for threads, durable memories, scoped retrieval, and context assembly.
• LangChain can be useful after the Oracle-backed memory and retrieval path exists, mainly as an application-side wrapper and orchestration layer.
• A practical pattern is hybrid: Antigravity plus MCP for interactive database work, Oracle AI Database plus Oracle AI Agent Memory for durable memory, and LangChain only when a consuming application needs reusable retrieval orchestration.
• 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:

1. Start with one approved Oracle connection and a read-only validation query.
2. Put SQLcl MCP in front of that connection so Antigravity sees tools, not raw database credentials.
3. Check the audit and activity trail before adding more tool access.
4. Add Oracle AI Agent Memory when the workflow needs durable thread context, scoped recall, or reusable context cards.
5. Add LangChain only when you need application-side retrieval orchestration beyond the MCP interaction loop.

Controlled Antigravity MCP + Oracle AI Database Workflow

Why This Architecture Is Useful for Developers

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

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.

The Two Execution Loops

The system naturally forms two execution loops:

• Loop A: Antigravity works with MCP to discover tools, inspect data, run bounded read-only queries, and return results immediately.
• Loop B: Application code writes history, tool logs, memory records, chunks, and embeddings to Oracle AI Database, then retrieves context before a later answer or workflow step.

Dual Execution Loop: MCP Interaction and Durable Memory

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.

Reproducing the Oracle SQLcl MCP Server and Antigravity Workflow

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

• Oracle SQLcl 25.2.0 or higher
• Oracle JRE 17 or 21
• Antigravity with MCP configuration available through mcp_config.json
• At least one saved SQLcl connection profile under ~/.dbtools, created with password persistence for MCP use
• A database user with the minimum permissions required for the workflow

Start with read-only access and a sanitized development or replica environment where possible.

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.

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

• Run sql -mcp locally and confirm the server starts.
• Reload Antigravity MCP servers and confirm the SQLcl tools are discoverable.
• Run one read-only query against an approved schema.
• Check database-side MCP activity logs and session metadata where available.
• Document the connection alias, database user, grant scope, restrict level, and troubleshooting owner.

Good first proof looks like this:

• The MCP server starts without a Java or path error.
• Antigravity lists the SQLcl MCP tools after the MCP reload.
• A read-only query succeeds against the expected schema.
• The notebook's simulated teaching audit trail records the expected tool interaction in antigravity_tool_logs.

For live Antigravity plus SQLcl MCP validation, confirm database/session activity through your normal Oracle monitoring path. A denied query fails because of the database role, not because a prompt asked nicely.

What a Useful MCP Boundary Looks Like

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.

• Read-only default: Start with inspection and diagnostics before allowing changes.
• Confirmation gate: Require explicit approval for medium-risk, write-like, or destructive actions.
• Scope control: Keep user, tenant, and schema filters close to the database query.
• Failure trace: Store denied calls and warnings as evidence instead of hiding them.

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"},
}

What a Successful Notebook Run Shows

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:

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.

Simulated Teaching Data, Not Live Antigravity Telemetry

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.

Why Put Application Memory Records in Oracle AI Database, Not Just Outputs

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