Google Antigravity supports the Model Context Protocol the way Google has historically supported open standards: with first-class platform integration, deep enterprise-governance hooks, a substantial catalog of first-party servers wrapping Google’s own data and infrastructure, and a few specific paper cuts that reflect the tradeoffs of doing it the Google way. The result is the most Google-flavored MCP implementation in any major agentic IDE: opinionated where Google has opinions, generous where Google is integrating its own ecosystem, careful where enterprise customers need controls, and a little awkward where the per-product OAuth flows of Google’s existing surfaces haven’t fully unified yet. This piece is the focused satellite on how Antigravity specifically implements MCP. We assume you have context on Antigravity as an IDE (covered in our Antigravity 101 pillar) and context on what MCP is as a protocol (covered in our MCP explainer pillar).
What follows is the practical operational picture of Antigravity’s MCP support as of mid-2026: where MCP lives in the product surface, how to configure it, what ships in the first-party catalog, how authentication and governance work, how it compares to MCP support in the other major agentic IDEs (Cursor, Windsurf, Claude Code), and the honest limits worth knowing before you commit to building MCP-driven workflows on Antigravity specifically.
The short version is that Antigravity is the right MCP-enabled IDE for teams already invested in Google Cloud or Google Workspace, where the first-party server catalog plus the IAM-based governance plus the Model Armor prompt and response inspection give an enterprise-grade MCP story that no competing IDE matches. It is a less compelling MCP choice for teams whose primary MCP integrations are to non-Google services, where the smaller third-party catalog and the fragmented OAuth flows create more friction than competitors like Cursor present. Picking Antigravity for MCP is largely an extension of picking Antigravity for the IDE itself, with the MCP layer reinforcing the Google-platform bet either way.
Where MCP lives in Antigravity
MCP is a first-class capability across the entire Antigravity suite rather than an IDE-only feature. The four product surfaces that all consume the same MCP configuration:
The Antigravity IDE itself, which is the VS Code-fork desktop application that the original Antigravity launch shipped with. MCP servers configured here are available to the agentic-coding sessions inside the IDE.
The Antigravity 2.0 Manager desktop application, which launched at Google I/O on May 19, 2026 as the broader-purpose agentic surface that sits alongside the IDE. The same MCP servers are available inside the Manager.
The Antigravity CLI, which launched in spring 2026 as the replacement for the deprecated Gemini CLI (covered in our recent piece on the Gemini CLI sunset). The CLI consumes the same MCP configuration, which means a session that starts in the IDE and continues in the CLI sees the same connected tools.
The Antigravity Python SDK (google.antigravity), which gives programmatic agents the same MCP pipeline. Managed Agents built on the SDK can use the configured MCP servers in the same way that interactive sessions in the IDE or CLI can.
The unified-suite design is a meaningful differentiator from the other major agentic-IDE products. Cursor, Windsurf, and Claude Desktop each have their own configuration files and (in the case of Claude Code as a separate CLI) their own re-configuration cycles. Antigravity’s single shared configuration means a developer who sets up MCP once gets the same setup everywhere they work in the Antigravity ecosystem.
Configuration
The configuration file lives at ~/.gemini/config/mcp_config.json (the .gemini directory name persists from the pre-rename era and has not been renamed despite the Gemini-to-Antigravity branding transition). Per-workspace overrides go in .agents/mcp_config.json in the project root, following the standard pattern of allowing project-specific configuration on top of user-level defaults.
The schema follows the broader MCP configuration pattern with the standard mcpServers top-level key. Each entry under mcpServers is a named server configuration with a few common field patterns:
For stdio servers (the original MCP transport, where the server runs as a local process the IDE invokes), the configuration uses command and args to specify how to launch the server, plus an optional env block for environment variables the server needs at startup.
For HTTP and Server-Sent Events (SSE) remote servers, the configuration uses serverUrl (note: serverUrl, not the legacy httpUrl that earlier MCP versions used) plus an optional headers block and an oauth block for authentication.
For Google-hosted remote servers, an additional field authProviderType set to "google_credentials" tells Antigravity to authenticate using Application Default Credentials rather than the OAuth Dynamic Client Registration pattern that non-Google remote servers typically use.
In addition to direct JSON editing, Antigravity provides an in-app MCP Store at Settings → Customizations → Installed MCP Servers → Add MCP. The Store gives a discoverable interface to browse and install commonly-used servers without having to write JSON configuration by hand. For users who prefer GUI configuration, this is the recommended path.
The first-party server catalog
The first-party server catalog is Antigravity’s most-differentiated MCP feature relative to other agentic IDEs. The major first-party servers as of mid-2026:
Google Workspace servers cover the major Workspace surfaces: gws-gmail for Gmail message access and composition, gws-drive for Google Drive file operations, gws-calendar for Calendar events, gws-chat for Google Chat messaging, and gws-people for the People API and contacts. The Workspace servers let an Antigravity-driven agent read, search, and (with appropriate permissions) modify content across the user’s Workspace surfaces.
Google Data Cloud servers cover the data and analytics infrastructure: BigQuery (for the data warehouse), AlloyDB and Cloud SQL (for Postgres-compatible operational databases), Cloud Spanner (for the distributed database), Knowledge Catalog through Dataplex (for the data-discovery and metadata surface), Managed Apache Spark (for analytics jobs), and Looker through the broader Looker Toolbox. The Data Cloud servers are the bridge between Antigravity agents and the data warehouse / operational data stack that Google Cloud customers run on.
Google Developer Knowledge server provides access to Google’s documentation, samples, and reference material as MCP-queryable resources. An Antigravity agent looking up how to use a specific Google Cloud API or a specific Workspace feature can query the Developer Knowledge server rather than relying on the model’s parametric training data.
gcloud MCP wraps the gcloud CLI itself, letting Antigravity agents invoke Google Cloud operations through the same command-line surface that human Google Cloud operators use. This is the bridge into the full Google Cloud control plane.
Remote endpoints for Firestore, Cloud Resource Manager, and Stitch cover additional Google Cloud surfaces with specific MCP integrations.
The catalog is the part of Antigravity’s MCP story that does not have an equivalent in any other major agentic IDE. Cursor and Windsurf support third-party Google integrations through community MCP servers, but the first-party Google integrations with the IAM-and-Model-Armor governance described below are Antigravity-specific.
The OAuth story
Authentication for Antigravity’s MCP servers depends on which kind of server:
Google-hosted remote servers (the first-party catalog above) authenticate through authProviderType: "google_credentials". This uses Application Default Credentials: the Google credentials the user has configured at the operating-system level, typically through gcloud auth login. The pattern is convenient for users who are already authenticated to Google Cloud, since the same credentials they use for gcloud invocations are reused for MCP server access.
Workspace MCP servers use a manual paste-the-auth-code flow per surface. The first time a user invokes a Workspace operation through MCP, they get redirected to a Workspace OAuth flow, complete the authorization in a browser, and paste the resulting code back into Antigravity. The flow works but has a meaningful paper cut: the tokens are not centralized across the IDE, CLI, and Manager surfaces. A user who authenticates Gmail through the IDE may need to re-authenticate when they invoke Gmail through the CLI. This is friction that Google has acknowledged and is reportedly working on, but as of mid-2026 it’s still a real workflow issue for users who move between Antigravity surfaces.
Non-Google remote servers use standard OAuth 2.1 with PKCE. Antigravity attempts Dynamic Client Registration (DCR) by default; if the server does not support DCR (some don’t), the user supplies clientId and clientSecret manually in the configuration. The pattern works similarly to how Claude Desktop and Cursor handle remote OAuth.
The fragmented OAuth story for Workspace is the most-cited friction in Antigravity’s MCP support. The Workspace OAuth flow itself is fine; the per-surface re-authentication is the issue. For users who only use one Antigravity surface (just the IDE, for example), the friction is invisible. For users who actively use both the IDE and the CLI, the re-auth cycle is annoying enough to be worth flagging.
Tool discovery and surface
MCP-provided tools are auto-discovered on session start. When an Antigravity session launches, the MCP configuration is read, the servers are connected, the tools each server exposes are enumerated, and those tools become available to the agent harness alongside Antigravity’s built-in tools, Python function tools, and Skills.
Tools are namespaced with the pattern mcp(server/tool). This is the format used in permission rules, in tool invocation logs, and in the agent’s reasoning about which tool to call. The namespacing prevents naming collisions between similarly-named tools from different MCP servers (a query tool from a BigQuery MCP server is distinct from a query tool from a Cloud Spanner MCP server through this namespace).
For users who want to see what tools are available, the /tools command in the CLI and the equivalent surface in the IDE list all currently-available tools across all sources. This is useful both for debugging (when an expected tool isn’t available) and for capability discovery (when the user is figuring out what a particular MCP server actually offers).
The unified pipeline means MCP tools, Skills, and built-in tools all behave the same way from the agent’s perspective. There is no quality-of-life gap between built-in and MCP tools, which is the right design for an MCP-first agentic IDE.
Managed Agents and the Python SDK
The Antigravity 2.0 release introduced Managed Agents, which are programmatic agentic processes that run on Google’s infrastructure rather than on the user’s local machine. The Python SDK at google.antigravity is the developer surface for building Managed Agents.
MCP tools are available to Managed Agents through the same configuration model as interactive sessions. A Managed Agent built on the Python SDK reads the same mcp_config.json (or a programmatically-supplied equivalent), connects to the configured MCP servers, and uses the discovered tools in its execution. Subagents within a parent agent share the parent’s MCP context by default, with permissions mediated through the /agents panel in the IDE for interactive cases or through the SDK’s permission API for programmatic cases.
This is meaningful for production deployments because it means the same MCP integrations work whether the agent is running interactively for a developer in the IDE or running on Google’s infrastructure as a Managed Agent serving production workloads. The configuration patterns and the credentials carry over (with appropriate adjustments for the production environment’s credential management).
Security and governance
This is the area where Antigravity’s MCP support is most clearly differentiated from competing IDEs. Several specific governance capabilities:
Permission presets via the /permissions command let users choose among four modes: request-review (every tool invocation requires user approval), proceed-in-sandbox (tools run in a sandboxed environment without user approval), always-proceed (tools run with user approval automatically granted), and strict (the most restrictive mode). The default for unconfigured MCP tools is "Ask" mode, which prompts the user the first time a new tool is invoked.
Allow-rules use the mcp(server/tool) namespace pattern. Rules can be specific (mcp(bigquery/query)), server-wide (mcp(bigquery/*)), or universal (mcp(*)). The rule system gives fine-grained control over which tools the agent can invoke without user prompt.
Google Cloud MCP servers gate access on the IAM role roles/mcp.toolUser. Users without this role cannot invoke Google Cloud MCP tools through Antigravity even if the configuration is correct. This is the IAM bridge between Antigravity MCP and Google Cloud’s broader permission system.
Service-account impersonation is supported for the Google Cloud MCP servers. An Antigravity agent can invoke Google Cloud MCP tools as a specific service account rather than as the user’s own identity. This is the pattern that production deployments use for separation between development and runtime identities.
Model Armor integration provides prompt and response inspection for MCP-mediated operations. With Model Armor’s INSPECT_AND_BLOCK mode enabled, prompts that flow through MCP tools and responses that come back are inspected for policy violations (data leakage, malicious content, prompt injection patterns). Operations that fail inspection are blocked before they execute or before the response reaches the agent.
Centralized audit logging captures MCP tool invocations through Google Cloud’s standard logging infrastructure. Organizations with compliance requirements can produce audit trails showing what tools were invoked, with what arguments, and what responses were returned. This is the operational visibility that enterprise customers need.
IAM deny policies can restrict MCP tool invocations by OAuth client (limiting which client identities can invoke specific tools) or by read-only flag (forcing certain tools to operate in read-only mode regardless of their default capability). The deny policies are the operational mechanism for enforcing principle-of-least-privilege on MCP tool access.
The governance depth is meaningfully beyond what Cursor and Windsurf provide. Cursor and Windsurf have permission models for MCP tools, but they operate at the IDE level and don’t integrate with the IAM, audit logging, and policy-inspection infrastructure that enterprise customers need. Antigravity’s governance is the part of the product that justifies enterprise adoption for customers who would otherwise stay with their existing IDE.
How Antigravity MCP compares to competitors
The comparison points:
Cursor has the most mature general MCP user experience and the largest community catalog of third-party MCP servers. For developers whose MCP integrations are to community-maintained servers, Cursor is generally the easier path. Cursor’s UI for MCP server management is more polished than Antigravity’s in-app store. Cursor lacks the first-party Google catalog and the enterprise governance.
Windsurf sits between Cursor and Antigravity on the maturity curve. It has fewer first-party integrations than Antigravity and a smaller community catalog than Cursor, but it has added enterprise admin controls in recent releases that approach (without matching) Antigravity’s IAM-based governance.
Claude Desktop and Claude Code popularized the JSON-config pattern that Antigravity inherits. Claude’s MCP support is the cleanest baseline implementation: well-documented, broadly compatible, no specific vendor lock-in beyond Claude itself as the model provider. Antigravity has more depth on the enterprise side but Claude has been the reference implementation that the community looks to.
VS Code’s MCP extension support is the third-party-extension model: MCP integrations come from community extensions rather than from VS Code itself. The model is flexible but the experience is fragmented; each extension handles MCP slightly differently. Antigravity’s single-suite-wide MCP support is meaningfully more consistent.
The differentiation pattern: Antigravity wins on first-party Google integrations, enterprise governance, and unified configuration across the suite. Cursor wins on third-party catalog breadth, UI polish for MCP server management, and developer community engagement. The two products serve different ends of the market.
Common use cases
The MCP-driven workflows that have settled into common adoption patterns on Antigravity:
Antigravity plus BigQuery / Spanner. Data engineers and analysts use Antigravity with the BigQuery and Spanner MCP servers to do data exploration and analysis through agent-mediated SQL. The agent generates queries, executes them against the data warehouse, analyzes the results, and synthesizes the answer for the user.
Antigravity plus GitHub. Through the remote GitHub MCP server, Antigravity agents can read issues, propose changes through pull requests, and operate on the codebase metadata that GitHub holds. This is the standard pattern for development workflows.
Antigravity plus Workspace. Workspace-heavy organizations use the Workspace MCP servers for agent-driven Gmail triage, Drive document operations, and Calendar coordination. The use case is particularly visible in the operations and project management workflows where Workspace is the primary surface.
Antigravity plus Stitch. The Stitch design-to-code MCP integration lets Antigravity agents read design specifications from Stitch and produce corresponding implementation code. This is the most novel of the common patterns and is most relevant for product teams where design-to-code workflow is a real bottleneck.
The honest limitations
A few specific paper cuts worth flagging:
OAuth tokens not synced across surfaces. The Workspace OAuth flow needs to be completed independently in the IDE, the CLI, and the Manager. For users who only use one surface, this is invisible. For users who actively move between surfaces, the re-auth is friction.
Env-var pass-through bug. As of mid-2026, there is a reported bug where environment variables specified in the env block of an MCP server configuration are not always passed through to the server process correctly. The workaround is to hardcode API keys directly in the configuration, which is operationally worse for credential management. Google has acknowledged the bug; the fix is reportedly in progress.
Smaller third-party catalog than Cursor. The community-maintained MCP server ecosystem has built up most strongly around Cursor. Antigravity has a smaller third-party server catalog as a result. For most use cases this doesn’t matter (the servers that exist work the same on Antigravity as on Cursor), but the discoverability and the community-curated quality signals are less mature on Antigravity.
IDE-side MCP debugging is limited. When an MCP server doesn’t behave as expected, the debugging surface in Antigravity is less developed than what an experienced developer working with command-line MCP would have. The /tools command shows what tools are available but not why a specific invocation failed, which can make MCP debugging more painful than it needs to be.
Documentation fragmentation. The MCP support is documented across several places (the Antigravity main docs, the Codelabs tutorials, the Google Cloud Data Cloud extension docs, the Workspace MCP docs), and the documentation doesn’t always cross-link cleanly. Finding the right reference for a specific question can take longer than it should.
None of these are deal-breakers for using Antigravity with MCP. They are the kind of operational paper cuts that any first-generation enterprise integration has, and they will continue to get smoothed out through the next several Antigravity releases.
Frequently asked questions
Do I need Google Cloud to use Antigravity with MCP? No, not for non-Google MCP servers. You can use Antigravity with community MCP servers (Supabase, GitHub, Slack, and others) without any Google Cloud relationship. Google Cloud is required for the first-party Google Cloud MCP servers (BigQuery, Spanner, etc.) because those servers operate inside Google Cloud and require IAM authentication.
Can I use the Workspace MCP servers without paying for Workspace? No. The Workspace MCP servers require a Google Workspace account with the appropriate APIs enabled. Personal Google accounts have more limited Workspace API access than business Workspace accounts.
Is Antigravity’s MCP support compatible with the standard MCP protocol? Yes. Antigravity speaks standard MCP. Any MCP server that follows the protocol will work with Antigravity. The Antigravity-specific surfaces (the in-app store, the IAM governance) are additions on top of standard MCP rather than modifications to it.
Can I use Antigravity MCP with non-Google models? Yes, through the multi-provider support that Antigravity 2.0 introduced. MCP tools are available to whichever model is configured for the current session, whether that’s Gemini, Claude, or GPT.
Does the Antigravity MCP configuration migrate from Gemini CLI configuration? Mostly yes. The configuration file lived in the same ~/.gemini/config/ location for the Gemini CLI’s MCP support, and Antigravity reads from the same file. Configurations should carry over without migration steps. The schema details are slightly different (the migration from httpUrl to serverUrl, for example) but Antigravity handles the conversion for most cases.
Is there a programmatic way to discover what tools an MCP server provides? Yes. The /tools command in the CLI or the equivalent surface in the IDE lists all available tools. Programmatically through the Python SDK, the connected MCP servers expose their tool inventories through the SDK’s tool-introspection API.
How does Model Armor inspection affect MCP latency? Model Armor adds inspection passes for prompts and responses, which incurs some latency on each MCP tool invocation. The latency is typically tens of milliseconds rather than seconds, but for very-tight-loop workflows it can be noticeable. The trade-off is usually worth it for enterprise customers who need the inspection.
Can I write a custom MCP server for my organization’s internal APIs? Yes. The MCP protocol is open and Anthropic’s MCP SDK supports writing servers in Python, TypeScript, and several other languages. A custom server registered with Antigravity through the standard configuration patterns works the same as any first-party or community server.
Does Antigravity support MCP servers in containers? Yes, both for local development (stdio servers running in containers via Docker or Podman) and for remote servers (HTTP/SSE servers running in container orchestration). The configuration patterns are the same as for non-containerized servers.
What happens to my MCP configuration if I uninstall Antigravity? The configuration file at ~/.gemini/config/mcp_config.json remains on disk after uninstall. If you reinstall Antigravity or install Claude Code or another MCP-aware tool that reads from compatible locations, the configuration is reusable. The configuration is not Antigravity-specific in its format.
