Fix Antigravity MCP "Context Deadline Exceeded"

context deadline exceeded means an MCP operation missed a client deadline; it does not identify the cause by itself. The reliable fix is to inspect Antigravity's MCP status and logs, validate the documented config fields, then isolate launch, stdio, credentials, and remote-network failures one at a time.

This guide deliberately does not recommend undocumented timeout fields or environment variables. Google's current Antigravity MCP documentation lists the supported configuration surface and provides built-in status, reload, and log views.

If the first concrete log error is calling initialize: EOF, the server exited or closed stdout before initialization completed. Treat that as an immediate launch or transport failure and start with the direct-process and stdio checks below, not with timeout tuning.

What the Error Does—and Does Not—Mean

A deadline can expire while Antigravity is launching a local process, establishing an MCP connection, discovering tools, or waiting for a later request. Do not assume the server was healthy merely because it printed a startup line, and do not assume every deadline is a fixed "60-second timeout." The public docs do not specify one universal duration.

The Fast Diagnostic Path

1. In Antigravity 2.0, open Settings → Customizations → Installed MCP Servers. In the IDE, open MCP Servers → Manage MCP Servers. Use Refresh once and note the status change.
2. In Antigravity CLI, enter /mcp. The official manager shows active, disconnected, and loading states and lets you reload configuration or inspect connection logs.
3. Record the first concrete error before the deadline line: executable not found, process exit, invalid JSON, authentication failure, DNS/TLS error, or a server-specific exception.
4. Temporarily disable every unrelated server using the UI toggle or the documented disabled property. Reproduce with one server so concurrent cold starts do not hide the cause.

Refresh is a diagnostic, not a durable repair. If it works only after refresh, compare the first-launch logs with the refreshed connection and fix the difference—often executable resolution, a missing working directory, authentication, or cold package installation.

Use Only the Supported Antigravity Schema

Global servers belong in ~/.gemini/config/mcp_config.json; workspace-local servers belong in .agents/mcp_config.json. The root object is mcpServers. For local stdio servers, Antigravity documents command, args, env, cwd, disabled, and disabledTools.

{
  "mcpServers": {
    "example-local": {
      "command": "/absolute/path/to/node",
      "args": ["/absolute/path/to/server/index.js"],
      "cwd": "/absolute/path/to/project",
      "env": {
        "EXAMPLE_MODE": "production"
      },
      "disabled": false
    }
  }
}

Find the executable outside Antigravity, then copy the resolved path into command:

# macOS / Linux
command -v node
command -v npx

# Windows PowerShell
Get-Command node
Get-Command npx

An absolute path removes ambiguity about which runtime a GUI launch sees. Set cwd when the server resolves relative files. Put only server-documented variables in env, keep values as strings, and never commit a config containing secrets.

Check stdio Without Silencing Valid Logs

The MCP stdio rules are unambiguous: the server reads MCP messages from stdin, writes only valid newline-delimited MCP messages to stdout, and may write informational, debug, or error text to stderr. Clients should not interpret stderr output as failure by itself. See the official MCP stdio transport specification.

• Fix stdout pollution: move banners, progress bars, and debug text to stderr.
• Keep stderr available: it is the correct place for startup diagnostics and often reveals the real dependency or credential failure.
• Check process exit: an immediate exit or closed stdout is a transport failure, even if Antigravity later summarizes it as a deadline.

Run the exact configured executable and arguments in a terminal. A stdio server may appear to wait because it expects MCP input; that is different from exiting with a stack trace. Do not type arbitrary text into its stdin, because the protocol requires valid MCP messages there too.

Reduce Cold-Start Work

If logs show the process launches correctly but spends the deadline installing a package or connecting to a dependency, move that work out of startup:

• Install or cache the server package using the server publisher's documented installation method, then point command at the installed executable.
• Pin a known-good server version instead of downloading an unbounded latest version on every launch.
• Start required databases, browsers, or local services first and verify their own health independently.
• Use cwd so the server does not scan or resolve from an unintended directory.
• Leave a problematic entry disabled until it can start reliably, rather than slowing every Antigravity launch.

These are server-startup repairs. They do not change Antigravity's client deadline, and they should be validated against the particular server's documentation.

Remote Server Checks

Remote SSE or Streamable HTTP entries use the exact camel-case key serverUrl. Antigravity's docs explicitly say legacy url and httpUrl are unsupported; serverURL is also not the documented spelling.

{
  "mcpServers": {
    "example-remote": {
      "serverUrl": "https://mcp.example.com/mcp/"
    }
  }
}

For authentication, use the documented options: automatic OAuth where the server supports dynamic client registration, an oauth block for registered client credentials, authProviderType: "google_credentials" for Google ADC, or explicit headers. If the MCP log shows DNS, proxy, certificate, or HTTP authentication failures, resolve that layer before changing local launch settings. The corporate proxy and TLS guide covers the adjacent network diagnosis.

Do Not Add Undocumented Timeout Knobs

As of July 21, 2026, Google's documented Antigravity MCP properties do not include a per-server timeout field. The docs also do not document ANTIGRAVITY_MCP_TIMEOUT_MS, MCP_TOOL_TIMEOUT, or MCP_SERVER_REQUEST_TIMEOUT as Antigravity client controls.

A particular MCP server may define its own environment variable, but that is server-specific and must come from that server's documentation. Do not present a server's internal request limit as a way to extend Antigravity's connection deadline. Unknown config keys can create false confidence while the underlying launch or transport error remains.

Verify the Fix and Escalate with Evidence

1. Save the config and use Refresh or /mcp reload.
2. Confirm the server changes from loading/disconnected to active.
3. Invoke one read-only tool and confirm a normal result.
4. Restart Antigravity and repeat the same tool call to prove the cold-start path works.
5. Re-enable other servers one at a time.

If it still fails, report the Antigravity product and version, operating system, transport type, first relevant connection-log error, launch duration, and a redacted server entry. Remove tokens, OAuth secrets, headers, usernames, and private paths. The Antigravity MCP setup guide is the best cross-check for a clean baseline; if config state itself looks corrupted, use the backup-first reset guide.

Frequently Asked Questions

All Sources and Links

Primary and official sources, accessed July 21, 2026:

• Google Antigravity documentation: MCP configuration, managers, supported fields, and authentication
• Google Antigravity documentation: Gemini CLI migration and MCP config paths
• Model Context Protocol draft: stdio transport requirements
• Model Context Protocol draft: versioning and backward compatibility