Limitations

Known limitations

Tool-definition integrity

For predefined operation tools, Apollo MCP Server stores the executable GraphQL document separately from model-facing metadata. Changing only a tool description can't add a new server-side code path. However, Apollo MCP Server doesn't provide these controls:

• Automatic scanning of tool names, descriptions, or input descriptions for hidden or model-directed instructions

• Comparison of the live tools/list response with an approved snapshot

• A semantic diff or approval step before applying a hot-reloaded operation or schema source update

• Independent enforcement of the generated JSON inputSchema for predefined operation arguments

The execute tool accepts a new GraphQL document with each call, so the tool isn't bound to a previously reviewed predefined document.

Treat operation, schema, manifest, collection, and configuration sources as trusted inputs. Hot-reloaded changes are applied when observed, and model-facing text can steer an agent even when the stored operation itself is unchanged. For details, go to the guide that explains how to protect tool definitions from poisoning.

Intent-flow enforcement

Apollo MCP Server dispatches tool calls but doesn't compare a proposed call with the user's original goal. MCP Server doesn't detect instructions embedded in retrieved context, label tool results as untrusted for the model, detect intent drift, or require human confirmation before each call. Those kinds of controls require an MCP client, agent framework, or policy layer that participates in planning.

For predefined operations, the requested tool name must match an entry in the current operation catalog, and execution uses the stored GraphQL document for that entry. This bounds calls through the server to its live tool surface but doesn't establish that you reviewed every loaded operation or that a call is intended. Hot-reloaded sources can change that surface, and one operation's variables can address a broad set of data or resources.

Adopting execute expands the surface to agent-supplied queries and also permits agent-supplied mutations when mutation_mode is set to all. The upstream GraphQL API remains responsible for document validation, authorization, and other execution controls. For deployment guidance, go to Limit the impact of intent-flow subversion.

Operation validation and execution

Apollo MCP Server syntactically parses predefined and ad hoc GraphQL documents and enforces operation-type restrictions but doesn't validate the documents against the configured schema before exposing or forwarding them. As a result, an operation containing an unknown field, argument, or variable type can become a predefined tool or be sent through execute.

The upstream GraphQL endpoint performs GraphQL document and variable validation when it receives the request. The optional validate tool validates an ad hoc operation against Apollo MCP Server's configured schema without executing the operation, but clients aren't required to call validate before execute.

The base request path sends GraphQL as a structured JSON HTTP request and doesn't invoke an operating-system shell or child process from MCP tool input. Operator-provided Rhai scripts run before outgoing GraphQL requests and can change the endpoint or headers, read environment variables, and make their own HTTP requests. Treat the script directory as trusted code, and follow the Rhai security guidance.

OAuth token passthrough

Apollo MCP Server passes through validated OAuth tokens received from MCP clients to upstream GraphQL APIs by default. You can disable this behavior by setting disable_auth_token_passthrough: true in your transport auth configuration:

1transport:
2  type: streamable_http
3  auth:
4    disable_auth_token_passthrough: true

When disabled, Apollo MCP Server still validates tokens for MCP client authentication but doesn't automatically forward them to the upstream GraphQL API.

Rationale

The MCP authorization specification forbids token passthrough. By default, Apollo MCP Server retains the token for practical enterprise requirements like:

• Multi-user scenarios: Enterprise GraphQL APIs often require direct user identity to perform granular access control and tenant isolation.

• Existing enterprise patterns: Many organizations have GraphQL APIs that depend on the original Authorization header to identify users and apply existing identity-based access controls.

• Multi-tenant applications: Upstream APIs frequently need to read the Authorization header to identify the tenant and apply appropriate data filtering.

• User context propagation: The MCP specification lacks clear guidance on how user/session/identity information should reach upstream APIs when they need to perform their own authorization logic.

Security implications

• Token passthrough can lead to confused deputy vulnerabilities.

• Upstream APIs might treat successful MCP-server validation as proof that a token was issued for the upstream API.

• Tokens intended for the MCP server audience might be inappropriately used with different services.

• Forwarded credentials might be captured when upstream logging or tracing records request headers.

• If upstream APIs enforce proper audience (aud claim) validation, they should reject tokens that aren't intended for those APIs.

Recommended workaround

• Disable automatic passthrough and remove authorization from forward_headers when your GraphQL API doesn't require the caller's token.

• Adopt the MCP server only with GraphQL APIs that accept the same OAuth tokens and audiences.

• Make sure your OAuth authorization server issues tokens with appropriate audience claims for both the MCP server and upstream APIs.

• Verify that your upstream APIs validate token audiences, and redact authorization headers from logs and traces.

• Incorporate OAuth trust boundaries into your threat model to ensure comprehensive security.

Apollo MCP Server's telemetry omitted_attributes settings apply only to supported attributes exported by this server. They don't modify the forwarded authorization header or telemetry that the upstream API produces. Configure header capture and redaction independently at each telemetry producer and collector.

Future plans

We plan to address this limitation in a future release by implementing token exchange or separate authentication flows for upstream APIs, while still supporting the enterprise requirement for user identity propagation.