Universal MCP: Shared Database for Claude Code and Cursor

You use Claude Code for major architectural refactors. You use Cursor for quick inline edits against live diffs. You launch Antigravity for tasks requiring a browser. You open VS Code to inspect a legacy subsystem you have not touched in months.

Four distinct developer tools, four fragmented MCP configurations, and four isolated memories that never speak to each other.

In the morning, you explain a nuanced database indexing decision to Claude Code. By afternoon, Cursor suggests a conflicting migration pattern because it has zero visibility into that morning conversation. You re-explain everything. Tomorrow, Antigravity repeats the exact same mistake.

Your AI agents are not incompetent. They simply lack a shared persistent memory layer.

Why Separate MCP Configs Quickly Collapse

Every AI editor enforces its own manifest schema:

• Claude Code parses project-level .mcp.json files alongside a global home directory configuration.
• Cursor stores mcp.json inside its application settings directory using a similar yet non-standard format.
• VS Code expects .vscode/mcp.json with additional nested inputs parameters.
• Antigravity relies on community schemas that shift between releases.

If you want to use a single tool across all four environments, you must maintain four separate entries. Add one new tool, and you edit four files. Change a binary path, and you edit four files again.

The maintenance surface multiplies quickly. Five MCP servers across four editors equals twenty configuration blocks. A single misplaced comma or trailing bracket causes silent failures: the editor will not show an error, but the tool simply vanishes.

The pitfalls of standalone HTTP daemons

Many early guides suggest running MCP servers as standalone HTTP services on fixed ports, pointing each editor to http://127.0.0.1:PORT.

In practice, this setup introduces three major operational issues:

• Port collisions. Two background servers fighting for port 8788 will fail to bind. You end up managing manual port assignments across a dozen internal tools.
• Process lifecycle fragility. HTTP servers must start before the editor launches and shut down gracefully when you finish. If the daemon crashes, all four editors lose tool access without warning.
• Accumulated latency. Every call traverses the TCP loopback stack, handles TLS handshakes, and parses JSON-RPC over HTTP. That latency adds up rapidly when an agent loop makes 40 tool calls per task.

The cost of fractured memory

Configuration sprawl is annoying, but fractured state is destructive. When each editor maintains its own isolated memory database, your coding agents suffer from cross-tool amnesia.

Decisions logged in Claude Code remain invisible to Cursor. Research gathered in Antigravity never reaches VS Code. You become a manual copy-paste courier, summarizing context between editor windows.

It feels like employing four developers in one room who each keep private notebooks and are strictly forbidden from sharing notes.

The Advantage: One Bridge, Four Editors, One Database

ACS Core addresses this at the systems layer: a single compiled binary, an in-process SQLite WAL database, and a unified Model Context Protocol server driven via stdio.

The architecture is straightforward. Each editor launches acs mcp serve as an internal child process. Communication flows directly through standard input and standard output (stdin/stdout). No TCP ports are opened, and no background services require supervision.

Because all four editors run the exact same binary and target the exact same SQLite database file, their memory graph is unified automatically. You never have to write custom sync scripts.

Four distinct access tiers

ACS separates access paths to maximize speed without sacrificing reliability:

• Tier 1, in-process stdio RPC. The primary channel for agent tool calls. Responses return in under 2 milliseconds with zero network overhead.
• Tier 2, CLI fastpath. Fast binary subcommands for terminal workflows, such as acs kanban summary or acs memory summary.
• Tier 3, direct database access. In-process SQLite WAL queries for fast local reads that do not require an active MCP server.
• Tier 4, local REST fallback. A local HTTP endpoint on port 20130, reserved strictly for legacy clients that cannot spawn stdio subprocesses.

This hierarchy is intentional. The REST fallback acts as a safety valve, not the primary runtime path.

One configuration across all editors

The configuration block is identical across all tools, changing only in file location:

{
  "mcpServers": {
    "acs": {
      "command": "acs",
      "args": ["mcp", "serve"]
    }
  }
}

Add this block to .mcp.json for Claude Code, to mcp.json for Cursor, to .vscode/mcp.json for VS Code, and into your Antigravity configuration. Four entry points, one single source of truth.

To eliminate manual copy-pasting, ACS provides an automated sync command that reconciles all four manifests from a central definition. Run it once after installing a new capability, and all four editors update in lockstep.

What Changes When Agent Memory Is Unified

The most visible improvement is not raw speed. It is the quality and consistency of your agents' technical decisions.

When Cursor proposes a refactor, it reads architectural decisions recorded by Claude Code yesterday. When Antigravity opens a target URL, it reuses existing authenticated browser sessions. Technical context never evaporates at the application boundary.

You stop writing manual recaps between tools. That typically returns 20 to 30 minutes of deep focus to your day.

Manifest Synchronization Blueprint

Here is the exact manifest directory structure, symlink hygiene rules, and reconciliation logic we deploy across production workstations.

Multi-IDE Manifest Configuration Blueprint

When This Setup Is Unnecessary

If your team works exclusively inside a single editor, a basic project-level configuration is sufficient. Adding a synchronization layer brings unnecessary complexity to a one-tool workflow.

Likewise, if your developers operate across separate physical workstations and must share memory over a network, stdio RPC does not apply. In that scenario, an authenticated centralized service is required.

For a single developer working across multiple local editors, a single binary paired with a local SQLite database provides the cleanest, lowest-maintenance architecture.

Explore the Architecture

To see how this bridge integrates with other capabilities, explore the MCP Arsenal overview. The suite bundles stealth browser automation, AST code intelligence, persistent memory, and web research into a single package.

To review licensing tiers and deployment steps, visit the pricing page. A single perpetual license covers the full toolchain and ensures manifest compatibility as editor ecosystems evolve. Explore the open protocol standard in Model Context Protocol Specification ↗.