Connecting Codex CLI, Cursor, and Antigravity via MCP

I’ve spent this series building an orchestration system almost nobody else could see: a worker model, a supervisor, a retry loop, a Slack approval gate, all wired into one LangGraph process I run from my own terminal. Useful, but lonely. Only my orchestrator ever called any of it.

Today that changes. I turn the system into something other tools can plug into: Codex CLI, Cursor, and Google’s Antigravity IDE, all talking to the same tool hub through the Model Context Protocol (MCP). MCP is an open protocol that lets any AI client discover and call tools exposed by a server, without a bespoke integration for each pairing. If you’ve been following along, you already have the orchestrator — this post is about wiring more clients into it, not rebuilding it.

MCP Hub Architecture: Centralizing Tool Access for Multiple AI Clients

Instead of teaching every tool its own Slack logic, its own file-writing logic, its own retry logic, I centralise all of that behind one MCP server:

                ┌───────────────────────┐
                │     Codex CLI         │
                ├───────────────────────┤
                │       Cursor          │
                ├───────────────────────┤
                │     Antigravity       │
                └────────────▲──────────┘
                             │
                             │ MCP
                             │
                     ┌───────┴────────┐
                     │  MCP Tool Hub  │
                     │ (your tools)   │
                     └───────▲────────┘
                             │
                             │ tool boundary
                             │
                     ┌───────┴────────┐
                     │ LangGraph Core │
                     │ Orchestrator   │
                     └────────────────┘

The MCP hub exposes a small set of tools — write a file, request Slack approval, log an event — and anything that speaks MCP can call them. The orchestrator remains the brain. The MCP server becomes the one stable interface everything else talks to.

Why a Central MCP Hub Beats Per-Client Integrations

Without a shared MCP hub, I’d end up reimplementing side effects three times over: Codex CLI would need its own Slack integration, Cursor its own file-writing code, Antigravity its own execution logic. Every one of those copies is a place a bug can hide, and a place I’d have to fix it again later.

With the hub in place there’s one tool surface, one set of side effects, one approval gate, one place the logs come from. The orchestrator still decides what happens. The hub is simply how everyone reaches it.

The Three MCP Roles: Orchestrator, Tool Hub, Client

I think of the system as three separate roles now.

Orchestrator (LangGraph)

LangGraph is a graph-based orchestration framework for building stateful, multi-step LLM workflows in Python. In this system it decides the workflow, manages retries, waits for Slack approval, and tracks state across steps.

Tool hub (MCP server)

Executes side effects: writes files, posts to Slack, validates arguments, logs everything.

Clients (Codex CLI, Cursor, Antigravity)

Request actions and consume tools. They extend the system without ever touching its internals.

None of the three should reach around the others. A client that bypasses the hub to write a file directly has quietly broken the whole reason for building one.

Configuring MCP Servers in Codex CLI, Cursor, and Antigravity

Wiring up each client is the part I actually had to test, not just diagram.

Codex CLI

Codex CLI is OpenAI’s terminal-based coding agent, and it reads MCP servers from ~/.codex/config.toml (or a project-scoped .codex/config.toml), one [mcp_servers.<name>] table per server. Codex CLI supports both stdio (a locally launched child process) and Streamable HTTP transports:

[mcp_servers.orchestrator-hub]
command = "npx"
args = ["-y", "mcp-remote", "http://localhost:9000"]

Run /mcp inside a Codex session afterwards to confirm the server registered — full reference in OpenAI’s Codex MCP documentation.

Cursor

Cursor is an AI-native code editor that reads either a project file at .cursor/mcp.json or a global one at ~/.cursor/mcp.json; if a server is defined in both, the project-level config wins, according to Cursor’s MCP documentation:

{
  "mcpServers": {
    "orchestrator-hub": {
      "url": "http://localhost:9000"
    }
  }
}

One thing worth knowing before you plug in a dozen servers: Cursor caps you at roughly 40 active tools across everything connected, and quietly drops access past that limit rather than erroring loudly.

Antigravity

Antigravity is Google’s agentic IDE (built on Gemini), and it shares a single MCP configuration file with Gemini CLI: ~/.gemini/config/mcp_config.json. Edit it directly, or open Manage MCP Servers → View raw config from the IDE’s agent panel, per Antigravity’s MCP documentation:

{
  "mcpServers": {
    "orchestrator-hub": {
      "url": "http://localhost:9000"
    }
  }
}

Three different config files, three different tools, the same server, the same URL. That repetition across Codex CLI, Cursor, and Antigravity is the entire point.

Why MCP Is the Correct Abstraction for Multi-Client Tool Access

MCP is a standardised protocol that defines tool discovery, invocation, and argument structure, so a client and a server never need to have met each other before to work together — that’s the actual point of the MCP specification: one contract, any client, any server.

MCP’s single contract is what lets Codex CLI, Cursor, and Antigravity call the same tools without me writing three separate integrations for three separate tools.

MCP Mental Model: One Socket, Many Clients

Think of MCP like a hotel room’s universal power adaptor. Your laptop charger, your phone, your travel kettle — none of them were built with each other in mind, and none of them need to know about each other. They only need to agree on the socket. MCP is the socket. The orchestrator, the Slack approval gate, the file writer — those are the appliances. Codex CLI, Cursor, and Antigravity are just different plugs walking into the room.

MCP Client Setup Checklist

1. Confirm your MCP server is actually reachable at the URL you plan to register (curl http://localhost:9000 is enough of a check).
2. Add it to Codex CLI’s config.toml, restart the session, and run /mcp to confirm it registered.
3. Add the same URL to .cursor/mcp.json, keeping an eye on your total tool count if you already have other servers connected.
4. Add it to ~/.gemini/config/mcp_config.json for Antigravity, or use the IDE’s MCP Store instead of hand-editing the file.
5. Test one real tool call from each client before you trust it with anything that has side effects.

What Changes (and What Doesn’t) After Adding an MCP Hub

Adding a shared MCP hub doesn’t change what the LangGraph orchestrator does. It still decides, still retries, still waits for a human on Slack. What changes is who’s allowed to ask it to do something — a small change in code, and a much bigger change in how the whole project feels: less like a script I run myself, more like a platform other tools can lean on.

If you haven’t set up Codex CLI yet, I covered that in Getting Started with Codex CLI, and the local-MCP groundwork behind this post is in Local AI Agents with Cline, Ollama, and MCP.

References

• OpenAI — Model Context Protocol in Codex
• Cursor — Model Context Protocol (MCP)
• Google Antigravity — MCP servers
• Model Context Protocol — Specification (2025-06-18)
• Getting Started with Codex CLI
• Local AI Agents with Cline, Ollama, and MCP