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 

---

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: 

---

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. 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 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. 

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: 

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: 

Good first proof looks like this: 

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

---

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: 

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.

---

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 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.

---

Where Oracle AI Agent Memory Fits 

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. 

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; 

---

Store and Search: What a Realistic Memory Looks Like 

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, Native VECTOR, and Demo Embeddings 

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. 

---

Where LangChain Adds Value 

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. 

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. 

---

How to Move This from Demo to Production 

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: 

---

What to Check When the Workflow Fails 

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. 

---

Choosing the Right Mix: MCP, Oracle AI Agent Memory, Direct SQL, and LangChain 

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. 

---

Conclusion 

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. 

---

Frequently Asked Questions 

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. 

---

Companion Troubleshooting Appendix 

---

Resources