Advanced Architectural Analysis of Model Context Protocol (MCP) Client Configurations

Full report

On this page

The Model Context Protocol (MCP) represents a paradigm shift in how artificial intelligence models interface with external computational environments, bridging the gap between isolated large language models (LLMs) and dynamic, enterprise-grade data systems1. Originally pioneered as an open standard to facilitate uniform discovery and execution of external tools, MCP allows autonomous coding agents and AI-assisted integrated development environments (IDEs) to query databases, manipulate local file systems, and execute commands across remote cloud infrastructures3. As adoption has accelerated, major platforms—including OpenAI Codex, Anthropic Claude Code, Cursor IDE, and the Google Gemini/Antigravity suite—have independently implemented MCP client capabilities6. Despite the unification offered by the protocol's underlying tool execution logic, severe fragmentation has emerged at the configuration layer. Each AI client dictates its own specific schemas, file path hierarchies, precedence rules, and authentication flows6. This architectural divergence creates significant friction for developers seeking to deploy standardized MCP servers across disparate workflows. This report provides an exhaustive, comparative analysis of these configuration formats, mapping the precise file paths, environmental interpolation mechanics, and transport mechanisms utilized by each ecosystem. By isolating the simplest one-key and one-file setup flows, this analysis delineates how developers can achieve frictionless integration with Streamable HTTP remote servers across all four primary client environments.

The Evolution of Transport Layers and the Strategic Shift to Streamable HTTP

To fully contextualize client-specific configuration schemas, one must analyze the transport mechanisms mandated by the Model Context Protocol. The protocol segregates communication strategies based on the proximity and security context of the server relative to the AI client2. The stdio (Standard Input/Output) transport mechanism is predominantly utilized for localized, lightweight integrations2. Under this paradigm, the AI client acts as a host, spawning the MCP server as a local child process. This approach is highly effective for utilities requiring direct access to the developer's file system, local Git repositories, or proprietary executable binaries2. Configuration parameters for stdio servers universally require the declaration of an executable command (such as npx, python, or docker) and an array of execution arguments1. Conversely, the integration of enterprise data sources, cloud-hosted Application Programming Interfaces (APIs), and managed infrastructure necessitates remote transport mechanisms. Historically, remote MCP servers relied heavily on Server-Sent Events (SSE) to maintain a persistent unidirectional stream of updates, paired with secondary endpoints for bidirectional command execution3. However, SSE introduces complexities regarding corporate firewalls, reverse proxies, and load balancers, leading to its systematic deprecation across modern MCP ecosystems3. The industry standard has subsequently coalesced around Streamable HTTP. This transport mechanism leverages robust bidirectional communication over standard web ports, seamlessly facilitating enterprise proxies and complex OAuth 2.0 authentication flows1. Streamable HTTP requires the client configuration to define a remote URL endpoint and inject secure authentication parameters—typically in the form of Bearer tokens or customized HTTP headers—directly into the connection handshake1. The nuances of how each AI client maps these URL endpoints and safely injects sensitive keys form the crux of the configuration fragmentation observed today.

OpenAI Codex: TOML-Driven Systems Architecture and Secure Delegation

OpenAI Codex adopts a distinct architectural philosophy, eschewing the JSON conventions utilized by its competitors in favor of TOML (Tom's Obvious, Minimal Language)8. This decision aligns Codex with modern systems programming environments and command-line interface (CLI) ecosystems, offering enhanced human readability for deeply nested configuration tables1.

Hierarchical Scoping and Trust Boundaries

Codex enforces a rigid configuration hierarchy designed to balance global developer preferences with project-specific tooling requirements. The fundamental configuration resides at the user level, stored globally in the developer's home directory at \~/.codex/config.toml1. This global configuration acts as the baseline, defining the default MCP servers available to the Codex CLI and the Codex IDE extension regardless of the active working directory1. To support collaborative workflows, Codex permits project-scoped overrides via a .codex/config.toml file located at the repository root1. However, the loading of this project-scoped file is strictly gated by a trust mechanism; Codex will only parse this file if the developer explicitly marks the repository as a trusted environment1. Furthermore, Codex enforces stringent security isolation by prohibiting the project-level TOML from overriding critical machine-local keys13. Settings such as provider metadata, authentication credentials, telemetry routing, and host-owned application request metadata cannot be hijacked by a malicious repository payload, ensuring that the execution environment remains secure even when interacting with untrusted codebases13.

Streamable HTTP Mapping and Environment Resolution

Within the Codex TOML architecture, individual MCP servers are instantiated by defining a dedicated \[mcp\_servers.\<server-name\>\] table1. The transition from local stdio processes to remote Streamable HTTP servers is handled seamlessly through key mapping. Instead of utilizing the command and args fields, remote servers are mapped via the mandatory url key, which points directly to the server's network address1. Codex implements a highly secure credential delegation system. Rather than hardcoding plaintext secrets directly into the TOML configuration, developers utilize the bearer\_token\_env\_var field1. This directive instructs Codex to retrieve the authentication token dynamically from the designated local environment variable at runtime1. Codex then automatically structures this token and injects it into the Authorization HTTP header during the initial connection sequence1. For remote servers necessitating complex or proprietary header structures, Codex provides additional mapping capabilities. The http\_headers field accepts a map of static key-value pairs, while the env\_http\_headers field allows developers to bind specific header names to dynamic environment variables, enabling highly flexible authentication strategies without compromising security1. The underlying behavior of these servers can be heavily customized through a variety of operational policies. Developers can define a startup\_timeout\_sec (defaulting to 10 seconds) and a tool\_timeout\_sec (defaulting to 60 seconds) to prevent remote latency from hanging the AI client1. Furthermore, Codex supports granular tool governance via enabled\_tools allowlists, disabled\_tools denylists, and the default\_tools\_approval\_mode parameter, which dictates whether tools from a specific server operate in auto, prompt, or approve states1.

Plugin Architectures and Managed Hooks

Codex also supports MCP servers bundled directly within installed plugins. For these plugin-provided servers, the configuration syntax shifts slightly to the \[plugins."\<plugin-name\>".mcp\_servers.\<server-name\>\] table1. While the transport command is managed inherently by the plugin and cannot be altered by the user, developers retain full control over the enabled state and the per-tool approval\_mode policies, ensuring that third-party plugins cannot autonomously execute dangerous operations without explicit consent1. For enterprise environments demanding strict configuration compliance, administrators can enforce the allow\_managed\_hooks\_only \= true directive within a top-level requirements.toml file14. This setting instructs Codex to actively ignore user, project, and session hook configurations, strictly enforcing lifecycle hooks loaded from centrally managed configuration layers14.

The Simplest One-Key Flow for Codex

The most frictionless operational deployment for OpenAI Codex minimizes direct interaction with the TOML files by leveraging the integrated CLI commands. When connecting to modern servers that support standard OAuth flows, a developer can simply execute codex mcp login \<server-name\>1. This command triggers an autonomous authentication sequence, capturing the necessary tokens and saving the connection state without manual file editing. If the OAuth provider requires a fixed callback port or a custom base URL (e.g., for routing through a remote Devbox ingress), developers can define mcp\_oauth\_callback\_port and mcp\_oauth\_callback\_url at the top level of the config.toml to stabilize the redirect flow1. For developers integrating third-party APIs utilizing static keys, the simplest one-file, one-key flow bypasses the CLI in favor of a targeted edit to the user-level global file. By modifying \~/.codex/config.toml, the developer maps the remote url, defines the bearer\_token\_env\_var, and immediately creates a nested env table to store the plaintext key locally1. This approach encapsulates the entire configuration within a single, globally accessible file while avoiding the risks associated with checking secrets into project-level repositories.

Anthropic Claude Code: Multi-Tiered Granularity and Enterprise Governance

Claude Code, Anthropic’s command-line interface tailored for AI-assisted software engineering, employs a sophisticated, multi-tiered JSON configuration system15. Claude Code embraces the Model Context Protocol to grant the underlying LLM autonomous access to external resources, enabling complex workflows involving database queries, log analysis, and code scaffolding3.

Scope Hierarchy and Precedence Resolution

Claude Code distributes MCP configurations across four distinct scopes, prioritizing flexibility and granular control over the execution environment. When identical settings or server names appear across multiple scopes, Claude Code resolves conflicts through a strict precedence hierarchy17. The architectural scopes are structured as follows:

• User Scope (Global): Defined in the \~/.claude.json file located in the user's home directory, this scope applies to all projects executing on the host machine12. This is the optimal location for universal utilities, such as a centralized Notion integration or personal API credentials3. User scope holds the lowest precedence in the hierarchy17.
• Project Scope: Defined in a .mcp.json file located at the root of a specific repository12. This configuration is explicitly designed to be committed to version control, ensuring that all developers collaborating on a codebase have access to an identical suite of tools, such as project-specific linting servers or staging database connectors3.
• Local Scope (Default): Also stored physically within the \~/.claude.json file, but logically mapped and isolated under the specific project's directory path3. This is the default behavior when adding a server via the CLI, allowing developers to experiment with new tools without cluttering the shared .mcp.json or polluting their global user environment3. Local scope overrides both project and user configurations17.
• Managed Scope (Enterprise): Designed for rigid organizational compliance, the managed scope possesses the highest precedence and cannot be overridden by any local, project, or user settings17. On macOS, this configuration is delivered via Mobile Device Management (MDM) platforms targeting the com.anthropic.claudecode preference domain or explicitly written to /Library/Application Support/ClaudeCode/managed-mcp.json17. On Windows, it is enforced via Group Policy registry keys at HKLM\\SOFTWARE\\Policies\\ClaudeCode or stored in C:\\Program Files\\ClaudeCode\\managed-settings.json (replacing the legacy C:\\ProgramData\\ path)17.

JSON Schema Aliasing and Environment Interpolation

The schema for Claude Code centers on the mcpServers object12. Within this structure, developers must explicitly define the transport layer using the type property. For remote HTTP endpoints, Claude Code accepts either "http" or "streamable-http" as valid values12. The inclusion of "streamable-http" functions as an exact alias, directly mirroring the nomenclature established by the official MCP specification to allow seamless copy-pasting from external server documentation12. Network endpoints are declared via the url field, and authentication parameters are managed through the headers object12. To mitigate the severe security risks associated with hardcoding API keys into files destined for version control (such as the project-scoped .mcp.json), Claude Code implements robust environment variable interpolation12. Developers can inject secrets dynamically using the ${env:VAR\_NAME} syntax, ensuring that sensitive tokens remain safely within the local environment while the configuration structure is shared with the team12. Additionally, Claude Code supports path expansion variables, such as ${CLAUDE\_PROJECT\_DIR}, which dynamically resolves to the stable project root, and ${CLAUDE\_PLUGIN\_ROOT} for resolving paths within bundled plugins12. Claude Code also heavily utilizes plugins to distribute pre-configured MCP servers. When a plugin (e.g., mcp-server-dev@claude-plugins-official) is enabled, its bundled servers start automatically12. To avoid naming collisions in the tool registry, plugin-provided tools are automatically prefixed with a complex namespace pattern: mcp\_\_plugin\_\<plugin-name\>\_\<server-name\>\_\_\<tool-name\>12. This namespace must be referenced exactly when constructing permission rules or defining allowed tools for subagents12.

The Simplest One-Key Flow for Claude Code

The intended setup path for Claude Code relies on its interactive CLI wizard. By executing claude mcp add \--transport http \<server-name\> \<url\>, the developer initiates a guided setup process12. To inject keys securely, developers append the \--env flag (e.g., \--env API\_KEY=secret\_value), which passes the variable securely to the server's execution context without writing it in plaintext to the local configuration12. However, the CLI wizard can become cumbersome when configuring highly complex servers or rapidly iterating on custom toolchains, as any typographical error requires restarting the interactive sequence18. For advanced users seeking the simplest one-file, one-key flow, the optimal strategy involves bypassing the CLI and directly editing the user-scoped \~/.claude.json3. Because this global file is isolated from project-level Git tracking, developers can safely hardcode their API keys directly into the "Authorization" string within the headers object12. This approach consolidates the entire setup into a single file edit, immediately activating the server across all active Claude Code sessions18.

Cursor IDE: Agentic Harness and Protocol Fallback Mechanics

Cursor, a leading AI-native IDE, embeds MCP directly into its agentic framework, empowering its integrated LLM to autonomously navigate codebases, execute terminal commands, and interface with remote services6. While Cursor's underlying configuration architecture closely mirrors the JSON structure utilized by Claude Desktop and Claude Code, its approach to transport negotiation and graphical user interface (GUI) management introduces unique operational dynamics.

Configuration Symmetry and Implicit Typing

Cursor simplifies its configuration hierarchy into two distinct paths, both utilizing a standard mcpServers object6.

• Global Configuration: Stored at \~/.cursor/mcp.json. Servers defined here are universally available across any workspace opened within the IDE6.
• Project Configuration: Stored at .cursor/mcp.json within the root directory of a specific repository. This localized file overrides global configurations in the event of naming conflicts, ensuring that project-specific tool versions or endpoints take precedence6.

Unlike Claude Code, Cursor relies on implicit typing to determine the transport mechanism7. If an mcpServers entry contains a command field, Cursor initializes a local stdio process7. If the entry bypasses the command field and instead provides a url and optional headers, Cursor automatically infers that the server is a remote HTTP target7.

The Streamable HTTP vs. SSE Fallback Failure

While implicit typing simplifies the configuration syntax, Cursor's V2 connection handler has exhibited significant protocol negotiation flaws when interfacing with remote servers20. When connecting to a URL defined in mcp.json, Cursor preferentially defaults to the modern Streamable HTTP protocol, dispatching an initial POST request to the target endpoint (e.g., POST /sse)20. If the remote server relies on the legacy Server-Sent Events (SSE) transport protocol, it will actively reject this POST request, typically returning a 404 HTML error payload20. Standard network fallback protocols dictate that upon receiving this failure, the client should gracefully degrade to a GET request to initiate the standard SSE handshake20. However, Cursor's current V2 Finite State Machine (FSM) fails to execute this fallback, prematurely terminating the connection and rendering the server permanently unreachable within the IDE20. To bypass this critical connection failure, developers must implement a bridging workaround. Instead of defining the server as a remote HTTP target via the url field, developers force Cursor to initialize a local stdio process using the mcp-remote utility6. The configuration maps the command to npx and passes mcp-remote and the target URL as arguments20. This utility acts as a local proxy, translating Cursor's stdio outputs into properly formatted SSE GET requests, effectively sidestepping Cursor's native transport negotiation logic20.

Security Governance and the Simplest One-Key Flow

Cursor's reliance on graphical interfaces drastically streamlines the integration of third-party MCP servers. Modern servers frequently feature "Add to Cursor" deep links within their documentation; clicking these links automatically populates the IDE's GUI with the necessary endpoint and transport data, entirely abstracting the underlying JSON configuration7. For servers requiring authentication, Cursor triggers an embedded browser OAuth flow, securing the tokens without exposing them to the filesystem in plaintext7. For environments requiring the manual configuration of static API keys, the simplest one-key workflow utilizes the native GUI. The developer navigates to Cursor Settings \> Tools & MCP, selects "Add New MCP Server," chooses the "Streamable HTTP" transport option, and pastes the endpoint URL6. The static API key is pasted directly into the GUI's header input fields. Cursor automatically serializes this data and writes it to the global \~/.cursor/mcp.json file6. While this GUI-driven flow is exceptionally user-friendly, it carries significant security implications. The IDE writes the sensitive API key to the filesystem in raw plaintext within the headers object6. Although the global \~/.cursor/mcp.json file is generally shielded from accidental Git commits (unlike project-level configurations), it remains highly vulnerable to local credential harvesting or malicious filesystem scans. To mitigate potential damage from compromised remote servers, security best practices dictate that developers must disable Cursor's "auto-run mode," forcing the IDE to prompt for explicit human approval before invoking any remote tool, and ensure that all injected tokens operate strictly on a least-privilege, read-only basis7.

Google Gemini and the Antigravity Suite: Centralized Orchestration

The Google developer ecosystem has recently undergone a comprehensive architectural consolidation. The standalone Gemini CLI, which previously relied on a .gemini/settings.json file and a deprecated httpUrl field, has been aggressively transitioned into the unified Antigravity suite (often abbreviated as "Agy")9. This suite seamlessly integrates Antigravity 2.0 (a desktop agent manager), the Antigravity IDE, the Antigravity SDK, and the newly rebuilt, high-performance Go-based Antigravity CLI9. This consolidation fundamentally unified the MCP configuration paradigms across all Google developer surfaces, shifting focus toward robust, enterprise-grade authentication and centralized policy enforcement9.

Sparse Configurations and Shared File Paths

To support execution across diverse environments—ranging from terminal interfaces to full IDEs—Antigravity separates its MCP definitions into sparse, dedicated configuration files rather than relying on a monolithic settings block23. The primary configuration paths utilized by the Antigravity suite are:

• Global Server Setup: \~/.gemini/config/mcp\_config.json. This file acts as the ultimate source of truth, synchronizing MCP server access instantly across the Antigravity 2.0 desktop app, the IDE, and the CLI9.
• Workspace Local Setup: .agents/mcp\_config.json. Located within the active project directory, this file facilitates project-specific tool integrations23.

Cloud-Native Authentication and OAuth Complexity

Within the mcp\_config.json file, Streamable HTTP servers are declared using the serverUrl parameter, entirely replacing the legacy httpUrl syntax9. The defining characteristic of the Antigravity ecosystem is its profound integration with Google Cloud security infrastructure5. When configuring internal Google Cloud remote MCP servers (such as BigQuery or Cloud SQL endpoints), developers can completely bypass the risks of managing static API keys by utilizing Application Default Credentials (ADC). By setting the authProviderType field to "google\_credentials", the Antigravity suite automatically authenticates against the remote endpoint using the developer's underlying Google Cloud identity21. For connections to external Streamable HTTP endpoints or protected Google Workspace APIs (such as Gmail, Drive, or the People API), the configuration must utilize an oauth block containing a clientId and clientSecret21. Because the Antigravity suite spans multiple disparate application surfaces, these OAuth tokens cannot be centralized; the authentication sequence must be initiated manually on a per-surface basis22. In the CLI, developers type /mcp to invoke an interactive Terminal User Interface (TUI) panel23. Selecting a server and triggering the "Authenticate" action opens a secure browser window; the developer must then copy the resulting authorization code and paste it back into the terminal prompt to finalize the handshake27. This reliance on external browser redirects highlights a current limitation within the Antigravity architecture: the IDE lacks a secure, native, in-memory OAuth client28. Consequently, complex proxy scripts are occasionally required to intercept and manage the authentication handshake for strict OAuth servers that reject standard CLI redirects28.

Enterprise Security: Model Armor and Agent Gateways

To satisfy enterprise compliance requirements, Google has layered extensive security protocols over its remote MCP connections. Traffic directed to Google Cloud remote MCP servers can be optionally routed through Model Armor5. Model Armor proactively screens both the user's prompt and the MCP server's response against Sensitive Data Protection (SDP) filters to detect personally identifiable information (PII) or malicious injection attempts26. Administrators can enforce these protections via centralized Agent Gateway policies, determining whether the connection operates in a FAIL\_OPEN state (allowing traffic if the screening service goes offline) or a FAIL\_CLOSED state (blocking all traffic to preserve data security)26. For custom MCP data stores integrated directly into the Gemini Enterprise console, administrators can force read-only execution by injecting the readOnlyHint: True annotation into the Python tool definitions, entirely bypassing the mandatory user confirmation prompts that normally govern destructive tool invocations26.

The Simplest One-Key Flow for Antigravity

For standard, third-party API connections that utilize a Bearer token rather than complex OAuth handshakes or Google ADC, the simplest one-key flow in Antigravity requires a manual edit to the shared global file22. The developer modifies \~/.gemini/config/mcp\_config.json, defines the remote serverUrl, and pastes their static API key directly into the nested headers object9. Because this file is monitored by all Antigravity surfaces, saving the file immediately populates the server across the ecosystem9. The developer simply opens the IDE's Customization panel and clicks "Refresh", or runs the /mcp command in the CLI, to instantly bind the remote tools to the agent's context window23. While Antigravity supports POSIX variable expansion ($VAR\_NAME) within the configuration to avoid plaintext secrets, directly pasting the key provides the absolute fastest path to an operational state21.

Comparative Synthesis of Streamable HTTP Configurations

To distill the architectural divergences across these platforms, the following table compares the essential file locations, schema formats, and exact key placements required to map a standard, Bearer-token secured Streamable HTTP MCP server.

Emergent Trends in Agent Permissions and Tool Governance

The rapid evolution of these configuration schemas underscores a fundamental shift in the AI landscape: the transition from passive chat interfaces to highly autonomous, agentic systems capable of orchestrating complex backend workflows2. As MCP servers evolve from simple data parsers into executable toolchains capable of modifying databases, committing code, and provisioning infrastructure, the necessity for robust, configuration-level permission controls has become paramount1. This demand for security has forced clients to heavily integrate execution policies directly into their underlying JSON and TOML schemas. Codex allows administrators to define a default\_tools\_approval\_mode, dictating exactly when a remote HTTP call can execute autonomously or when it must halt to prompt the user1. The Antigravity suite implements a sophisticated wildcard policy configuration (e.g., mcp(server/\*)), allowing developers to whitelist specific remote tools to bypass the default protective "Ask" mode23. In enterprise environments utilizing custom registries, administrators can enforce regular expression (Regex) pattern matching to strictly control which file paths or remote ports an MCP server is permitted to access, ensuring that local developer configurations cannot circumvent organizational security postures31. As the Model Context Protocol continues to standardize the foundational communication layer, the defining differentiation between AI clients will increasingly hinge upon these governance features. The transition away from SSE toward Streamable HTTP directly supports this trend, as standard HTTP endpoints are significantly easier to monitor, proxy, and secure within corporate networks3. Ultimately, while the fragmentation of file paths and JSON schemas presents immediate challenges for developers, the rapid maturation of environmental interpolation, integrated OAuth handling, and granular tool approval modes ensures that these autonomous AI systems can operate securely and effectively at an enterprise scale.

Works cited

1. Model Context Protocol – Codex \- OpenAI Developers, https://developers.openai.com/codex/mcp
2. How to Set Up MCP Servers with OpenAI Codex CLI \- Inventive HQ, https://inventivehq.com/knowledge-base/openai/how-to-set-up-mcp-servers
3. Claude Code MCP Servers: How to Connect, Configure, and Use Them \- Builder.io, https://www.builder.io/blog/claude-code-mcp-servers
4. Connect Codex to MCP Servers via Docker MCP Toolkit, https://www.docker.com/blog/connect-codex-to-mcp-servers-mcp-toolkit/
5. Use the Agent Platform remote MCP server \- Google Cloud Documentation, https://docs.cloud.google.com/gemini-enterprise-agent-platform/reference/use-agent-platform-mcp
6. MCP Config File Location: Claude Desktop, Cursor & Claude Code (Mac, Windows, Linux), https://mcpplaygroundonline.com/blog/complete-guide-mcp-config-files-claude-desktop-cursor-lovable
7. MCP Servers in Cursor: Setup, Configuration, and Security (2026 Guide) \- Truefoundry, https://www.truefoundry.com/blog/mcp-servers-in-cursor-setup-configuration-and-security-guide
8. MCP Configuration Across AI Agents \- Uno Platform, https://platform.uno/blog/mcp-configuration-across-ai-agents/
9. Configuring MCP Servers and Skills for Antigravity CLI and IDE | by Dazbo (Darren Lester) | Google Cloud \- Community | May, 2026 | Medium, https://medium.com/google-cloud/configuring-mcp-servers-and-skills-for-antigravity-cli-and-ide-a938c7eebb78
10. How to Add MCP Servers to Claude Code with Docker MCP Toolkit, https://www.docker.com/blog/add-mcp-servers-to-claude-code-with-mcp-toolkit/
11. MCP JSON Configuration FastMCP, https://gofastmcp.com/integrations/mcp-json-configuration
12. Connect Claude Code to tools via MCP, https://code.claude.com/docs/en/mcp
13. Configuration Reference – Codex | OpenAI Developers, https://developers.openai.com/codex/config-reference
14. codex/docs/config.md at main · openai/codex \- GitHub, https://github.com/openai/codex/blob/main/docs/config.md
15. Connect to MCP servers \- Claude Code Docs, https://code.claude.com/docs/en/mcp-quickstart
16. Claude Code | Products \- Documentation \- IONOS, https://docs.ionos.com/cloud/ai/mcp-server/connect-to-an-ai-client/claude-code
17. Claude Code settings \- Claude Code Docs, https://code.claude.com/docs/en/settings
18. Configuring MCP Tools in Claude Code \- The Better Way \- Scott Spence, https://scottspence.com/posts/configuring-mcp-tools-in-claude-code
19. MCP in Cursor AI. In this article we will add tools to… | by Lovelyn David | Medium, https://medium.com/@lovelyndavid/mcp-in-cursor-ai-02e3d96eb593
20. Cursor fails to fall back from Streamable HTTP to SSE transport for remote MCP servers, https://forum.cursor.com/t/cursor-fails-to-fall-back-from-streamable-http-to-sse-transport-for-remote-mcp-servers/154390
21. MCP servers with Gemini CLI, https://geminicli.com/docs/tools/mcp-server/
22. Google Workspace MCP servers in Google Antigravity 2.0, IDE, and/or CLI \- Codelabs, https://codelabs.developers.google.com/google-workspace-mcp-antigravity
23. Model Context Protocol (MCP) \- Google Antigravity Documentation, https://antigravity.google/docs/mcp
24. Plugins & Skills \- Google Antigravity Documentation, https://antigravity.google/docs/cli-plugins
25. Configure the Google Workspace MCP servers \- Google for Developers, https://developers.google.com/workspace/guides/configure-mcp-servers
26. Set up your custom MCP server data store | Gemini Enterprise, https://docs.cloud.google.com/gemini/enterprise/docs/connectors/custom-mcp-server/set-up-custom-mcp-server
27. Configure the People API MCP server \- Google for Developers, https://developers.google.com/people/v1/configure-mcp-server
28. \[Guide\] Fixing Authentication for the Google Developer Knowledge MCP Server (and other Cloud Servers) in Antigravity, https://discuss.ai.google.dev/t/guide-fixing-authentication-for-the-google-developer-knowledge-mcp-server-and-other-cloud-servers-in-antigravity/136601
29. Use MCP servers | Google Cloud Data Agent Kit extension for Antigravity IDE, https://docs.cloud.google.com/data-cloud-extension/antigravity/use-mcp-servers
30. Connect Google Antigravity IDE to Google's Data Cloud services, https://cloud.google.com/blog/products/data-analytics/connect-google-antigravity-ide-to-googles-data-cloud-services
31. Cascade MCP Integration \- Devin Docs, https://docs.devin.ai/desktop/cascade/mcp
32. Cascade MCP Integration \- Devin Docs, https://docs.devin.ai/windsurf/plugins/cascade/mcp