Google Antigravity MCP: Context Cost and Permission Scoping

Google Antigravity speaks the Model Context Protocol, and in August 2026 that sentence carries almost no information. Every serious agentic harness speaks MCP. The questions worth asking about Antigravity MCP support are narrower: what happens to your context window when you connect a dozen servers, and what actually stops an agent from calling the one tool on your database server that drops a table. Google announced the platform on November 20, 2025 in a Developers Blog post, and it has since grown four surfaces: desktop app, IDE, CLI and Python SDK.

What the Configuration Format Actually Says

Antigravity’s MCP documentation puts server definitions in one of two files: a global ~/.gemini/config/mcp_config.json or a workspace-local .agents/mcp_config.json. Both use the familiar mcpServers object. A local server gets command, args, env and cwd. A remote server gets serverUrl, covering both SSE and streamable HTTP, plus optional headers. The docs are explicit that the legacy url and httpUrl fields are not supported.

Authentication has three routes: "authProviderType": "google_credentials" for Application Default Credentials, automatic OAuth against servers supporting dynamic client registration or an oauth block with clientId and clientSecret for servers that do not, or a bearer token in headers that now lives in a JSON file on disk.

Two optional fields matter more than their one-line descriptions suggest. disabled takes a boolean and turns a server off without deleting its entry. disabledTools takes an array documented as tool names "to withhold from the model." Hold onto that second one. It is the only lever the format gives you for the first hard problem.

The First Hard Problem Is Arithmetic, Not Philosophy

Every connected MCP server pays rent in your context window. Tool names, descriptions and full JSON Schema input definitions get serialized into the system prompt before the model has read a line of your code. Anthropic puts a five-server setup at roughly 55,000 tokens of definitions before any work starts. That is a vendor figure for a different harness, but the arithmetic is not vendor specific.

Antigravity’s MCP documentation does not discuss this. There is no statement that connected servers consume context, no guidance on how many servers to enable at once, and no description of lazy loading, deferred definitions or a tool search mechanism. The absence is the finding. The only mitigation the documented format offers is disabledTools, a manual denylist you maintain by hand, per server, by name.

There is indirect evidence about what the runtime does with those definitions. An open issue on the gemini-cli repository, filed May 7, 2026 and labeled priority/p2, reports that the Antigravity IDE refuses servers past a hardcoded ceiling with the error "enabled tools would exceed max limit of 100." The reporter hit it with a Google Workspace MCP server carrying roughly 110 tools, and notes that Gemini CLI handled servers with 300 or more tools without complaint. A hard numeric cap that fails loudly is the behavior of a system loading definitions up front, not deferring them.

How Other Harnesses Answer the Same Question

The contrast is sharpest against Claude Code, which treats context cost as a headline design constraint. Its MCP documentation states that tool search "keeps MCP context usage low by deferring tool definitions until Claude needs them. Only tool names and server instructions load at session start." It is on by default, and the docs say plainly that "Claude Code doesn’t impose a fixed per-server tool cap; the practical limit is your context window budget." An ENABLE_TOOL_SEARCH variable lets you force deferral, disable it entirely, or use a threshold mode that loads schemas up front only while they fit inside ten percent of the window.

The supporting numbers come from Anthropic’s own tool search documentation, which claims the technique "typically reduces this by over 85 percent" and that tool selection accuracy "degrades once you exceed 30-50 available tools." Those are vendor self-reported figures with no external replication. The architectural point stands regardless.

Cursor sits in between. Its MCP docs cover stdio, SSE and streamable HTTP transports and project-level .cursor/mcp.json configuration, but state no tool count limit and describe no deferral mechanism. VS Code offers a manual Configure Tools picker. So the field breaks into three camps: architectural deferral, manual curation, and a hard cap. Antigravity is in the third. Our comparison of Claude Code and OpenAI Codex covers how differently two harnesses resolve the same constraint.

The Antigravity MCP Permission Grammar

The second hard problem gets a much better answer. Antigravity runs MCP tools through the same unified permissions system that governs shell commands, file reads and writes, URL fetches and interactive browser actions. Rules take the form action(target). The action vocabulary includes read_file, write_file, read_url, execute_url, command, unsandboxed and mcp.

For MCP specifically the patterns are mcp(server/tool) for a single tool, mcp(server/*) for everything on one server, and mcp(*) for the lot. Every rule lands in one of three buckets: Deny blocks immediately, Ask pauses for approval, Allow runs without prompting. Conflicts resolve by a stated precedence: Deny beats Ask beats Allow. That ordering matters, because it means a broad mcp(github/*) allow rule cannot quietly override a narrow mcp(github/delete_repository) deny rule.

The default is the right one. Unconfigured MCP tools run in Ask mode, so a freshly connected server cannot execute anything without a human clicking through. Rules live at three scopes, Project, Shared and Global, editable in the CLI through an interactive /permissions panel with allowlist, denylist and asklist tabs. Antigravity MCP permissions are also editable inline: during an approval prompt you can widen the grant for files, URLs and MCP tools, though notably not for terminal commands.

Enforced Versus Merely Configured

A permission grammar is only worth what the enforcement layer behind it is worth.

Two things here are genuinely enforced. Deny and Ask are evaluated by the client at call time, before the request reaches the server. And the precedence rule is deterministic rather than order-dependent, which removes a whole class of configuration accidents.

Two things are not what they look like. First, the protocol’s own metadata is not a security boundary. The MCP specification attaches optional annotations to tools, including a destructive hint, and then warns that clients "MUST consider tool annotations to be untrusted unless they come from trusted servers." A server can label a tool that wipes your production schema as read only. Nothing in Antigravity’s documented permission model reads those annotations anyway, which is arguably the safer choice, but it means you get no automatic classification of destructive tools. You write every deny rule by hand, and only the ones you thought of.

Second, sandboxing does not reach MCP. Antigravity’s sandbox documentation describes OS-level process isolation for local execution commands and shell operations launched by agents. It says nothing about MCP servers or MCP tool calls. That matches the permission vocabulary, where unsandboxed modifies command, not mcp. A stdio MCP server is a process running with your privileges, and the sandbox is not between it and your filesystem. Our look at CMS-side MCP agent permissions makes the same point from the server side: the client prompt is not the last line of defense.

Hooks Are the Real Enforcement Story

Antigravity does ship a programmable enforcement layer. Its hooks documentation defines five events, including PreToolUse, which fires before a tool executes and returns a decision field. That field accepts allow, deny, ask, force_ask and deny_unless_prior_grant, with deny documented as a hard block. Hooks live in hooks.json in .agents/ or ~/.gemini/config/. That is a real policy engine: you can inspect arguments, not just tool names, and refuse a delete call against production while permitting the same tool against staging.

The caveat is community-sourced rather than official. A test report posted August 6, 2026 on Google’s AI Developers Forum describes registering a probe hook through every documented route, then watching it fire on every tool call in the CLI while producing zero invocations in the IDE at v2.1.1 and the desktop app at v2.5.0, with no error either way. No Google reply appears in the thread. One tester is not proof, and an earlier July 2026 write-up reported hooks firing more broadly. But if a PreToolUse deny is what keeps an agent away from a destructive MCP tool, verify it on your exact surface before you trust it.

A Practical Configuration For Teams

Treat the two problems separately, because Antigravity handles them at different levels of maturity.

For context, curate aggressively. Prefer several narrow servers to one broad one, since disabled operates per server and is far less work than maintaining name-by-name disabledTools arrays. Keep the workspace-local .agents/mcp_config.json minimal and per project. If a session degrades once another server connects, that is your budget speaking.

For permissions, write deny rules before allow rules, at tool granularity. mcp(*) as an Allow is the configuration equivalent of running everything as root. Keep the Ask default for anything newly installed, and reserve Allow for read-only tools you have inspected. Put compliance requirements in a PreToolUse hook, then confirm the hook runs on your surface. Background on the wider harness landscape sits in our explainers on Claude Code and cloud agent sessions.

Frequently Asked Questions