Claude Code, Cursor, Codex, and Antigravity: Same Server, Different Controls
Snapshot
~85 sec
Claude Code, Cursor, Codex, and Antigravity can expose the same MCP server through different control surfaces. The server contract may stay constant while configuration scope, tool visibility, approval behavior, and connection diagnostics change at the host. Choose by the control boundary your workflow needs, not by a brand ranking.
You will learn
- Separate an MCP server's tool contract from the host that configures and approves it.
- Compare project and global scope plus approval controls across four coding-agent hosts.
- Verify the same server read-first before enabling any mutating tool.
Target outcome
You can choose and verify an MCP host by scope and control needs while keeping the server contract unchanged.
Visual walkthrough
Visual walkthrough
~7 min
Keep four decisions separate
Server contract
Names, descriptions, schemas, annotations, and results exposed by the MCP server.
Connection surface
The host UI, command, or configuration file used to register and inspect that server.
Configuration scope
Whether the server is personal, project-specific, shared with a team, or available across workspaces.
Approval policy
The host decision that prompts, allows, limits, or denies a particular tool call.
One server, four current host control surfaces
Approach Connection surface Project or global scope Approval and tool control Best beginner verification Claude CodeRegister through its MCP command flow or configuration, then choose local, project, or user scope. Use the MCP CLI/status surfaces or a server entry supported by the current Claude Code documentation. Local stays private to one project; project scope can be versioned for a team; user scope follows the user across projects. Project-scoped server trust is reviewed, and Claude Code permission controls remain a separate boundary from connection. Confirm server status and discovered tools, then request a bounded console-warning summary. CursorRegister through Cursor's MCP settings or an MCP configuration file. Use the MCP settings surface or the current project/global JSON configuration described by Cursor. Project configuration keeps tools with one workspace; global configuration makes them available across projects. Tools can be enabled or disabled, and MCP calls ask by default unless the user deliberately changes auto-run behavior. Check that the server is connected and the intended read tool is enabled before asking it to inspect an invented hierarchy. CodexRegister through Codex MCP commands or config.toml layers shared by its local surfaces. Use Codex MCP commands, status, or a configured mcp_servers entry supported by the current Codex documentation. User config supplies personal defaults; trusted project .codex configuration can narrow behavior for a repository. Server allow/deny lists plus default and per-tool approval modes can keep write tools behind a prompt. Inspect MCP status and available tools, then call one read-only tool and compare its result with Unity. AntigravityRegister through its MCP Manager or the global/workspace MCP configuration. Use the MCP Manager, status rings, connection logs, or the current raw configuration surface. Global server setup follows the user; workspace setup keeps the connection with one project. Unconfigured MCP tools use Ask mode by default; policy can target a specific tool, server, or all MCP tools. Confirm a healthy status and inspect logs, then run one read-only request and compare the returned state. The host changes; the server contract does not
Each host connects to the same invented unity-context server. The host decides scope, visibility, and approval before the same read-only verification reaches Unity.
unity-context server
Same tool names, input schemas, annotations, and bounded results.
configured in
Claude Code host
Applies Claude Code scope and permission controls.
approves read
configured in
Cursor host
Applies Cursor workspace/global and tool controls.
approves read
configured in
Codex host
Applies config layers, allow/deny lists, and approval modes.
approves read
configured in
Antigravity host
Applies workspace/global config and Ask policies.
approves read
Read-only verification
Summarize warnings or inspect the invented PracticeRoom hierarchy.
Each host connects to the same invented unity-context server. The host decides scope, visibility, and approval before the same read-only verification reaches Unity. Reading order
- unity-context server
Same tool names, input schemas, annotations, and bounded results.
- Claude Code host
Applies Claude Code scope and permission controls.
- Cursor host
Applies Cursor workspace/global and tool controls.
- Codex host
Applies config layers, allow/deny lists, and approval modes.
- Antigravity host
Applies workspace/global config and Ask policies.
- Read-only verification
Summarize warnings or inspect the invented PracticeRoom hierarchy.
Connection explanations
- unity-context server → Claude Code host (configured in)
Claude Code stores and scopes the connection through its own current MCP surfaces.
- unity-context server → Cursor host (configured in)
Cursor registers the same server while retaining its own enable and approval controls.
- unity-context server → Codex host (configured in)
Codex connects the same contract through its MCP configuration and policy layers.
- unity-context server → Antigravity host (configured in)
Antigravity connects the same contract through its manager or configuration.
- Claude Code host → Read-only verification (approves read)
The host should prove the connection with a bounded read before any write is considered.
- Cursor host → Read-only verification (approves read)
Tool visibility and a successful read provide better evidence than a configured filename alone.
- Codex host → Read-only verification (approves read)
A read result can be checked without relaxing write approvals.
- Antigravity host → Read-only verification (approves read)
Status and logs establish transport; the read result establishes usable project context.
Test the same tool contract at two risk levels
Approach Goal Host control Expected evidence Read: summarize_consoleInvented read-only tool returns the latest bounded Unity warning entries. Verify server discovery and useful Editor context without changing the project. Enable only the read tool or approve that one call according to the selected host. The summary matches the Unity Console and the project diff stays empty. Write: create_game_objectInvented mutating tool proposes one disabled object under a named parent. Test a controlled mutation only after the read path is understood. Keep the write tool behind an explicit prompt and review its parent, name, components, and dry-run if available. Inspect the Hierarchy and scene diff, then deliberately keep, save, or revert the change. Choose by control needs
A small team wants one reviewable project-scoped Unity MCP connection, a visible connection check, and a prompt before every mutating tool. Which brand should they choose?
Expected reasoning
The requirements do not name a brand. Compare the four current official docs for project-scoped configuration, connection diagnostics, and per-tool or write approval behavior. Choose any host that demonstrably satisfies all three, verify it with summarize_console, and keep mutation disabled until its prompt and diff workflow are proven.
Go deeper
- Claude Code MCPOfficial Claude Code configuration, scope, and authentication controls.
- Cursor MCPOfficial Cursor MCP setup and server management guidance.
- Codex MCPOfficial Codex guidance for connecting and managing MCP servers.
- Antigravity MCPOfficial Antigravity MCP configuration and control guidance.