MCP Server Implementation Reference - Anthropic, OpenAI, Google, Cloudflare, and AWS

First Published: 2026-05-16
Last Updated: 2026-05-16

[Snapshot: 2026-05] The contents of this article reflect the state as of the Last Updated date shown above. This article compares how five major AI vendors implement the Model Context Protocol (MCP) as of May 2026. Specification references are pinned to MCP 2025-11-25. The MCP ecosystem changes quickly, so capability claims that I have not personally verified are tagged [Per docs].

The Model Context Protocol (MCP) reached its first anniversary on 2025-11-25, and by mid-2026 every major AI vendor ships at least one production-grade MCP surface. What used to be a question of whether to support MCP is now a question of which vendor's implementation to standardize on — and that decision is harder than it looks because the protocol is uniform on paper but uneven in practice. Spec primitives such as sampling, roots, and elicitation are widely advertised but only partially implemented; transport choices look identical until you read each vendor's authorization story; and the operational features (multi-tenant quotas, observability, regional residency) that decide enterprise adoption are barely covered by the spec at all.

This reference maps five vendor implementations — Anthropic, OpenAI, Google, Cloudflare, and AWS — against the published MCP specification and against each other. The goal is to give MCP integrators and platform architects a single decision-grade reference: what each vendor actually supports, where the gaps are, and which deployment context favors which stack. All comparisons are compiled from vendor-public documentation, with author-verified items separated from documentation-only claims via the [Per docs] tag.

A companion article in this series, MCP Server Ecosystem Reference 2026, catalogs the servers available across the ecosystem. The present article focuses on the vendor platforms that host, broker, or call those servers. For agent and protocol terminology that appears below without an inline definition, see the AI Agent Engineering Glossary.

1. Scope, Methodology, and Protocol Recap

1.1 What this reference covers

The five vendors selected here all run first-party MCP infrastructure that customers can call without forking open-source code, and each one is large enough that a vendor lock-in decision actually matters. I deliberately excluded community frameworks (FastMCP, mcp-go, mcp-rust), inference-only providers without a managed MCP surface (Mistral, Cohere), and aggregator products that wrap other vendors (Pipedream, Composio) — those are covered in the ecosystem reference linked above.

For each vendor I evaluate:

Spec version compliance (which MCP-Protocol-Version headers the implementation accepts and emits).
Transport coverage (stdio, Streamable HTTP, the deprecated HTTP+SSE legacy transport, WebSocket).
Authorization model (OAuth 2.1 with PRM/DCR/PKCE, API keys, IAM SigV4, mTLS).
Primitive support (tools, resources, prompts, sampling, roots, elicitation, notifications).
Operational features (multi-tenant isolation, quotas, observability, regional residency).
Deployment surface (where customers actually run their MCP servers).

Each vendor section is anchored to first-party documentation URLs as of 2026-05. Where I cite a feature I did not personally exercise, I mark it [Per docs]. Where a feature is in a vendor's roadmap but not yet shipping, I mark it [Preview] or [Beta] consistent with the vendor's own labeling.

1.2 Protocol recap

MCP is a JSON-RPC 2.0 protocol between an MCP client (the LLM-side runtime that holds the conversation) and an MCP server (a process that exposes tools, resources, and prompts, and that may invoke client-side capabilities such as sampling, roots, and elicitation). The current spec is 2025-11-25, which marks the protocol's first-anniversary release. The protocol governance moved to the Agentic AI Foundation (AAIF), a Linux Foundation directed fund, in December 2025 [Per docs].

Relevant building blocks for this comparison:

Transports: stdio for in-process or sub-process servers, and Streamable HTTP (single endpoint, optional server-sent events on GET) for remote servers. The earlier HTTP+SSE transport (spec 2024-11-05) is deprecated but retained for backward compatibility. WebSocket is not in the spec; vendors that mention it are using a custom transport.
Authorization: MCP servers that are not local follow OAuth 2.1 with mandatory Protected Resource Metadata (RFC 9728), mandatory Resource Indicators (RFC 8707), and recommended Client ID Metadata Documents. Dynamic Client Registration (RFC 7591) is optional. PKCE is required for all public clients.
Primitives: Server-exposed primitives are tools, resources, and prompts. Client-exposed primitives are sampling (server-initiated LLM completions fulfilled by the client), roots (filesystem boundaries), and elicitation (server-to-user prompts for missing inputs). Notifications (notifications/cancelled, notifications/progress, notifications/message) flow both ways.
Sessions: Streamable HTTP defines MCP-Session-Id as an opaque server-issued ID returned on initialize and replayed on every subsequent request. Last-Event-ID allows clients to resume a broken SSE stream.

The MCP-Protocol-Version request header is mandatory from MCP 2025-06-18 onward. A server that does not understand the header value must return HTTP 400. A client that does not send it falls back to 2025-03-26 semantics.

1.3 Methodology

I retrieved each vendor's MCP documentation directly between 2026-04-25 and 2026-05-12. Wherever a vendor publishes a changelog or roadmap, I prefer those signals over indirect blog posts. Where vendors do not publish capability matrices, I read the SDK source or the public OpenAPI/Smithy model.

Two principles drive the analysis. First, capability is not the same as production readiness — a primitive that compiles but is gated behind a beta flag is reported as [Beta], not as fully supported. Second, authorization story dominates transport story — any vendor can ship Streamable HTTP, but the OAuth flow, scope model, and token-binding behavior is what separates production-grade implementations.

This is a documentation-derived snapshot, not a benchmark and not an independent measurement. Periodic refreshes are planned in line with the ecosystem reference cadence.

2. Anthropic Reference Implementation

Anthropic created MCP and donated the protocol to the Agentic AI Foundation in December 2025 [Per docs]. The reference implementation remains the most complete by primitive coverage and the closest tracker of spec changes. As of 2026-05 the Anthropic stack covers three integration surfaces: the open-source SDKs, the Claude.ai/Claude Desktop/Claude Code clients, and the Messages API MCP Connector.

2.1 The reference SDKs

Anthropic maintains six official SDKs under the modelcontextprotocol GitHub organization:

python-sdk
typescript-sdk
java-sdk
kotlin-sdk (co-maintained with JetBrains)
csharp-sdk (co-maintained with Microsoft)
php-sdk (co-maintained with The PHP Foundation)

Each SDK ships both a client and a server implementation, supports both stdio and Streamable HTTP transports, and implements every server-exposed primitive plus the client-exposed sampling, roots, and elicitation primitives. The Python and TypeScript SDKs are the most complete, with the others trailing by one minor spec revision on average. Combined monthly downloads of the Python and TypeScript SDKs exceeded 97 million in March 2026 [Per docs].

The typescript-sdk is the canonical implementation for a remote Streamable HTTP MCP server because it ships an mcp-remote adapter that translates a Streamable HTTP endpoint into a local stdio server for clients that only support stdio. That adapter is what makes Claude Desktop, Cursor, Zed, and similar tools able to consume remote servers despite their original stdio-only model.

2.2 Claude Desktop and Claude Code (local clients)

Claude Desktop reads claude_desktop_config.json and launches stdio MCP servers as child processes. Each entry in the mcpServers map specifies a command, arguments, and environment variables. Token storage uses the operating system keychain.

Claude Code (the CLI agent) accepts the same configuration, plus an --mcp-config flag for ad-hoc servers and a claude mcp add subcommand. Starting in mid-2025, Claude Code can speak Streamable HTTP directly without the mcp-remote adapter, so a remote MCP server no longer requires a local subprocess. Settings reference details are tracked in Claude Code Features and Settings Reference 2026.

2.3 Claude.ai Custom Connectors (browser client)

Claude.ai (the web product) exposes Custom Connectors which are remote Streamable HTTP MCP servers reached through Anthropic's cloud relay. Custom Connectors require OAuth 2.1 with PRM (RFC 9728) and DCR (RFC 7591) — the relay performs DCR against the target server, persists the resulting client_id and client_secret in Anthropic's vault, and uses Authorization Code with PKCE for the per-user grant. The user never sees a redirect URL; the OAuth callback terminates inside the Anthropic web origin.

Anthropic provides a hosted directory of more than 200 Custom Connectors for popular SaaS apps (Linear, Notion, Slack, Asana, Stripe, GitHub). Enterprises can deploy private connectors and gate them by Claude.ai workspace.

2.4 The Messages API MCP Connector (server-side)

Anthropic's Messages API supports an mcp_servers request field, allowing the API caller to attach remote MCP servers per conversation turn. This is sometimes called the MCP Connector and is currently [Beta] under the header anthropic-beta: mcp-client-2025-11-20. The connector:

Speaks Streamable HTTP and the legacy HTTP+SSE transport (both supported for now).
Accepts an authorization_token field that the caller pre-acquired through OAuth; the connector does not run the OAuth flow itself.
Currently calls only tools/list and tools/call — resources, prompts, and sampling are not exposed even if the server implements them.
Supports allowed_tools and denied_tools lists and per-tool defer_loading flags for lazy enumeration.
Is not available through Amazon Bedrock or Vertex AI Claude variants — those code paths must use the host platform's MCP integration (AgentCore Gateway, ADK MCPToolset) instead.

The Connector is the only Anthropic surface where a single API call can fan out to multiple remote MCP servers in one inference turn.

2.5 Strengths and weaknesses

Strengths: full primitive coverage in the SDKs, the most spec-current implementation, an outstanding mcp-remote shim that future-proofs stdio-only clients, and the Custom Connectors directory which already covers most consumer-grade SaaS.

Weaknesses: server hosting is not Anthropic's business — you bring your own runtime (Cloudflare Workers, AWS Lambda, a long-running container). Observability for the Messages API Connector is currently limited to inference-side logs; you cannot see tool-call traces in the Anthropic console. Resources and prompts are not exposed to the API yet, so RAG-style MCP servers can only be consumed through Claude.ai, not the API.

3. OpenAI MCP Support

OpenAI joined the MCP project as a co-founder of the Agentic AI Foundation in late 2025, and the company shipped its first-class MCP integration in two parts: the Responses API for server-side LLM use, and Custom Connectors for ChatGPT for consumer use. A third surface, the Agents SDK, ties both together for developers.

3.1 Responses API MCP tool

The Responses API accepts a tool of "type": "mcp". Each MCP tool definition includes a server_label, a server_url pointing at a Streamable HTTP endpoint, and an optional headers map for static authorization. The request shape is straightforward:

{
  "tools": [{
    "type": "mcp",
    "server_label": "stripe",
    "server_url": "https://mcp.stripe.com/",
    "headers": { "Authorization": "Bearer ..." },
    "require_approval": { "never": { "tool_names": ["read_only_lookup"] } },
    "allowed_tools": ["create_customer", "list_invoices", "read_only_lookup"]
  }]
}

The Responses API supports multiple mcp tools per call and merges the resulting tool list into the model's function-calling surface. It calls tools/list and tools/call; resources, prompts, and sampling are not invoked. require_approval is the OpenAI-side gate that controls whether the user must approve a tool call before it executes — it has three modes (always, never, per_tool).

3.2 ChatGPT Custom Connectors

ChatGPT (the consumer product) accepts Custom Connectors that are remote MCP servers, similar to Claude.ai. The setup flow is OAuth 2.1 with mandatory PRM, DCR, and PKCE. The OAuth redirect_uri must terminate on chatgpt.com; ChatGPT performs DCR against the server's authorization endpoint and persists the result in OpenAI's vault.

ChatGPT Custom Connectors engage with all three server-exposed primitives (tools, resources, prompts) plus the client-exposed sampling primitive, though sampling is restricted to Enterprise and Edu tiers [Per docs]. Resources may be attached to a conversation as RAG context, and prompts may be invoked as slash-command-style affordances inside the ChatGPT UI.

3.3 OpenAI Agents SDK

The Python openai-agents package and its TypeScript counterpart provide a HostedMCPTool class that wraps the Responses API's MCP tool type. Agent definitions can list multiple MCP servers in the tools=[...] argument, and the SDK is responsible for refreshing the tool list when servers report a notifications/tools/list_changed event.

The SDK also implements a tool search feature for very large MCP servers: instead of sending the full tool list to the model, the SDK does an embedding search over tool names/descriptions and only attaches the top-k matches per turn. This is OpenAI's answer to the well-known problem of MCP servers that expose hundreds of tools and blow past the model's tool-list token budget.

3.4 Strengths and weaknesses

Strengths: the cleanest API-side ergonomics among the five vendors compared here, mature OAuth handling in ChatGPT Custom Connectors, a built-in require_approval gate that solves the largest UX problem in tool-calling agents, and a tool-search mechanism that scales beyond the spec's intended cardinality.

Weaknesses: the Responses API tool drives only tools/list and tools/call, ignoring the other server-exposed primitives (resources, prompts) and the client-exposed sampling primitive, and it provides no observability path for tool-call traces (developers must surface them through their own telemetry). The Agents SDK is Python- and TypeScript-only; Go, Java, and .NET developers must call the raw REST API. There is no first-party MCP server hosting product — OpenAI is a pure consumer of MCP, not a host.

4. Google MCP Support

Google's MCP story is the broadest of the five vendors because it spans developer SDKs, the consumer Gemini app, the Gemini Enterprise Agent Platform (formerly Vertex AI), and Apigee as an API-to-MCP bridge. The fragmentation reflects how recently Google rebranded its agent platform — the consolidated story is still settling as of 2026-05.

4.1 Agent Development Kit (ADK)

ADK is Google's open-source agent framework, released at Google Cloud Next 2025 and current as of the 1.x series. ADK's MCPToolset class is the developer-facing entry point for MCP integration. It supports both stdio and Streamable HTTP transports, and unlike OpenAI's Responses API it engages with all three server-exposed primitives plus the client-exposed sampling primitive. ADK reads roots/elicitation callbacks back into the agent loop, making it the most complete client-side MCP implementation among the five vendors compared here aside from the Anthropic SDKs.

ADK is model-agnostic — it works against Gemini, Anthropic Claude, and any LiteLLM-compatible model. That detail matters because it makes ADK the recommended client SDK even for engineers who are not using Gemini as their primary model.

4.2 Gemini CLI

The Gemini CLI (gemini binary) reads an ~/.gemini/settings.json configuration file and supports mcpServers entries with the same shape as Claude Desktop. The CLI's /mcp list and /mcp tools subcommands enumerate active servers and their exposed primitives. From the consumer side, the Gemini desktop app exposes a similar configuration panel [Per docs].

4.3 Gemini Enterprise Agent Platform (formerly Vertex AI)

At Google Cloud Next 2026, Vertex AI Agent Builder was rebranded to the Gemini Enterprise Agent Platform. Its MCP surface has three layers:

Managed MCP servers: Google operates first-party MCP servers for Google Maps, BigQuery, GKE, Compute Engine, and Google Security Operations. These are launched as [GA] services with regional residency tied to the customer's billing region. Authorization is via Google Cloud IAM tokens, mapped through a service account inside the agent's runtime.
Cloud API Registry: A console-driven inventory of MCP servers (customer-deployed plus managed) which Gemini Enterprise agents can attach to. This is [Preview] as of 2026-05.
Tool governance: The platform exposes per-tool allow/deny lists, scope-bound IAM, and Cloud Audit Logs entries that map a tool call to a user identity.

A higher-level architectural comparison between Gemini Enterprise Agent Platform, Amazon Bedrock AgentCore, and Microsoft Foundry can be found in Enterprise AI Agent Environment Design Notes Part 1.

4.4 Apigee as an MCP bridge

Apigee, Google Cloud's API management product, can transform an existing REST API into an MCP server through a managed adapter. The adapter handles OAuth 2.1 token exchange and emits a tools/list derived from the OpenAPI spec attached to the API proxy. This is a fast way to expose internal APIs to Gemini Enterprise without writing MCP server code, and it is in [GA] since early 2026.

4.5 ADK Sampling and Roots

ADK is the only client SDK among the five vendors compared here other than Anthropic's that implements sampling end-to-end — when a server invokes sampling/createMessage, ADK proxies the request back to the agent's model with the user's identity attached, allowing server-side agentic loops. roots is implemented through the standard ADK WorkspaceContext, automatically projecting the agent's working directory.

4.6 Strengths and weaknesses

Strengths: the only mainstream model-agnostic client SDK with complete primitive support, a managed MCP catalog that obviates self-hosting for the most common data sources, and Apigee as a one-click OpenAPI-to-MCP bridge for enterprises with existing API estates.

Weaknesses: the platform branding is in flux (Vertex AI → Gemini Enterprise Agent Platform) which complicates documentation searches and IAM examples. Tool governance features such as the Cloud API Registry are [Preview]. The managed MCP servers are tied to Google Cloud projects and IAM — customers outside Google Cloud cannot consume them without a federation setup.

5. Cloudflare AI Gateway and MCP Workers

Cloudflare positioned itself early as the de facto hosting platform for remote MCP servers, leveraging Workers (V8 isolates), Durable Objects (stateful sessions), and the Workers OAuth Provider library (OAuth 2.1 with PRM and DCR). Cloudflare is not a model vendor; instead it serves as the host between an MCP client and an MCP server, plus an inference gateway for upstream models.

5.1 The agents/mcp package

The agents/mcp npm package is Cloudflare's developer-facing MCP server toolkit. Two patterns are supported:

Stateless: createMcpHandler() returns a Cloudflare Worker fetch handler. Each request is independent; suitable for tools that don't need session state.
Stateful: The McpAgent class wraps a Durable Object, persisting MCP-Session-Id and per-session state across SSE streams. Required for long-running tools with cursor-based pagination or streamed results.

Both patterns speak Streamable HTTP as the primary transport. The legacy HTTP+SSE transport is supported through McpAgent.serveSSE() for backward compatibility with old clients but is no longer recommended.

5.2 Workers OAuth Provider

The @cloudflare/workers-oauth-provider library implements OAuth 2.1 with PRM (RFC 9728), DCR (RFC 7591), Resource Indicators (RFC 8707), and PKCE on the server side. The library is responsible for:

Hosting /.well-known/oauth-protected-resource (PRM) and /.well-known/oauth-authorization-server endpoints.
Generating and validating bearer tokens with audience binding.
Bridging upstream identity providers (Cloudflare Access, GitHub, Google, Auth0, WorkOS) via a withProviderFor() helper.

The bridge pattern — upstream IdP terminates the user identity, Workers OAuth Provider issues MCP-scoped tokens — is the cleanest enterprise deployment model for a Cloudflare-hosted MCP server.

5.3 mcp-remote

The companion mcp-remote package is a stdio-to-Streamable HTTP adapter that runs locally on the developer's machine and proxies traffic to a Cloudflare-hosted MCP server. This is functionally equivalent to Anthropic's adapter of the same name and is used for clients that have not yet adopted native Streamable HTTP.

5.4 RPC transport via Service Bindings

Cloudflare's Service Bindings allow one Worker to call another via an internal RPC mechanism that bypasses the HTTP edge. The agents/mcp package treats Service Bindings as a first-class transport, letting two Workers communicate via MCP without a public endpoint. This is unique to Cloudflare and useful for fan-out patterns where a parent agent Worker delegates to specialist tool Workers in the same account.

5.5 AI Gateway integration

Cloudflare AI Gateway brokers model calls (Anthropic, OpenAI, Workers AI, etc.) and adds caching, rate limiting, and per-tenant logging. Although AI Gateway is not itself an MCP server, it pairs naturally with agents/mcp Workers because both share Cloudflare's logging surface (Logpush) and identity model (Cloudflare Access).

5.6 Strengths and weaknesses

Strengths: by far the lowest-friction host for production-grade remote MCP servers (zero-config OAuth 2.1, Durable Objects for state, Service Bindings for internal fan-out), and the only vendor among the five compared here whose primary product is running other people's MCP servers rather than calling them. The Workers OAuth Provider library has had the most rigorous public review of any OAuth 2.1 + PRM implementation.

Weaknesses: Cloudflare is host-only; the AI inference must happen elsewhere, so a complete stack always pairs Workers with an external model provider. AI Gateway has no first-party MCP proxy/observation mode as of 2026-05; trace correlation across Gateway and Worker boundaries requires custom instrumentation. Sampling is technically supported by the SDK but client-side support (i.e., the model runtime) outside of ADK and Anthropic SDKs is rare, so server-side sampling on Cloudflare is currently theoretical for most stacks.

6. AWS Bedrock AgentCore Gateway

AWS Bedrock AgentCore reached [GA] on 2025-10-13 and consolidates AWS's MCP investments into a managed gateway, a managed runtime, an identity/credential broker, and a catalog. AgentCore is the most opinionated of the five implementations because it treats MCP as a gateway protocol between agents and existing AWS resources, not as a developer SDK. The Amazon Bedrock AgentCore Master Index aggregates the related deep-dive articles.

6.1 AgentCore Gateway

AgentCore Gateway is a managed service that exposes a single MCP endpoint per gateway and routes calls to targets. A target can be:

OpenAPI target: An OpenAPI 3.x specification (typically pointing to an existing API Gateway, ALB, or third-party API). The Gateway parses the schema and synthesizes tools/list entries from each operation.
Smithy target: A Smithy model. Same translation but native to AWS service shapes.
Lambda target: An AWS Lambda function whose event shape matches the MCP tools/call payload. The Lambda becomes one or more MCP tools.
MCP server target: An existing MCP server (running anywhere) attached as a downstream target so the Gateway can act as a federated front door.

The Gateway accepts incoming MCP requests over Streamable HTTP with MCP-Protocol-Version headers 2025-03-26, 2025-06-18, and 2025-11-25. Authorization is OAuth 2.1 via Amazon Cognito, Okta, or Auth0 (Authorization Code flow for user-facing tools; Client Credentials flow for service-to-service). Outbound authorization to downstream targets supports AWS IAM Signature V4 and the Credential Exchange feature which mints downstream OAuth tokens on demand.

A key Gateway feature is semantic tool search — the Gateway embeds tool descriptions and offers a search_tools(query) MCP tool that returns the top-k tools by relevance. This is AgentCore's answer to the same problem OpenAI solved with Agents SDK tool search, but implemented server-side so any MCP client benefits.

6.2 AgentCore Runtime

AgentCore Runtime is a managed container service for hosting agents and MCP servers. Runtime instances are ARM64 containers (Fargate-backed), with up to an 8-hour execution window per session — critical for long-running agentic workflows. An MCP server deployed on Runtime can register itself as a Gateway target through an mcp-server resource type.

6.3 AgentCore Identity

AgentCore Identity is the IAM-adjacent service that brokers downstream credentials. When a Gateway target needs an IAM role assumption or an OAuth token exchange, Identity is the broker that holds the upstream credentials. This is the AWS equivalent of the Cloudflare Workers OAuth Provider's withProviderFor() bridge.

6.4 awslabs/mcp and Agent Toolkit for AWS

The awslabs/mcp GitHub repository hosts AWS's collection of open-source MCP servers (Lambda Tool MCP Server, Serverless MCP Server, EKS MCP Server, and others). On 2026-05-06 AWS announced Agent Toolkit for AWS [GA], which packages the awslabs servers behind a managed remote MCP endpoint that any agent can call without deploying its own infrastructure.

6.5 AWS Agent Registry

The AWS Agent Registry is [Preview] as of 2026-05 and provides a searchable catalog of MCP servers and agents inside an AWS account. Amazon Q Developer, GitHub Copilot, Amazon Kiro, and Claude Code can query the Registry as an MCP server itself and consume the cataloged tools.

6.6 Companion guides

For implementation-level detail on the AWS pieces, see:

MCP Server on AWS Lambda Complete Guide — building Streamable HTTP MCP servers on Lambda with OAuth 2.1.
Amazon Bedrock AgentCore Implementation Guide Part 2: Multi-Layer Security with Identity, Gateway, and Policy — the Gateway security model end-to-end.
Amazon Bedrock AgentCore Implementation Guide Part 4: Multi-Agent Orchestration — supervisor and A2A patterns alongside MCP.

6.7 Strengths and weaknesses

Strengths: the only vendor among the five compared here that ships a managed MCP gateway (as opposed to a host or a client). OpenAPI/Lambda/Smithy target translation eliminates most server-side coding for AWS-native workloads. Semantic tool search is built in. The 8-hour Runtime session window is by far the longest of the five implementations and unblocks long-running agent patterns.

Weaknesses: Gateway and Runtime are AWS-only; multi-cloud deployments must either federate via IAM identity providers (complex) or duplicate infrastructure. AgentCore is younger than Cloudflare's agents/mcp, so production deployments have less community lore. Some primitives (prompts, roots, elicitation) are passed through but not first-class concepts in the Gateway UI — the console focuses on tools and resources.

7. Cross-Vendor Capability Matrix

The matrix below summarizes the dimensions covered in Sections 2-6. Status badges follow the convention used in MCP Server Ecosystem Reference 2026: [Full] means production support, [Partial] means support exists but with documented caveats, [Beta] or [Preview] follow the vendor's own labeling, and [N/A] means not implemented as of 2026-05.

For an at-a-glance view, the color-coded heatmap table below summarizes the entire matrix. The detailed tables that follow split the matrix into four sub-tables (Transport, Authorization, Primitives, Operational) so each axis can be cited independently.

* You can sort the table by clicking on the column name.

Capability	Anthropic	OpenAI	Google	Cloudflare	AWS
Spec Version	2025-11-25	2025-11-25	2025-11-25	2025-11-25	2025-11-25
Streamable HTTP	Full	Full	Full	Full	Full
stdio	Full	Partial	Full	Partial	Partial
OAuth 2.1 + PRM	Full	Full	Full	Full	Full
Tools	Full	Full	Full	Full	Full
Resources	Partial	Partial	Full	Full	Partial
Prompts	Partial	Partial	Full	Full	Partial
Sampling	Full	Partial	Full	N/A	Partial
Roots	Full	Partial	Full	Partial	Partial
Elicitation	Beta	N/A	Beta	N/A	N/A
Multi-tenant	Partial	Partial	Full	Full	Full
Observability	Partial	Partial	Full	Full	Full

Legend:

[Full] - production support, no documented caveats.
[Partial] - support exists, with caveats noted inline.
[Beta] - the vendor labels the feature beta or behind a beta flag.
[Preview] - the vendor labels the feature preview, not yet GA.
[N/A] - not implemented as of 2026-05.

7.1 Transport coverage

* You can sort the table by clicking on the column name.

Vendor	Spec Version	Streamable HTTP	stdio	HTTP+SSE (legacy)
Anthropic	2025-11-25	[Full]	[Full]	[Partial] (Messages API Connector accepts)
OpenAI	2025-11-25	[Full]	[Partial] (Agents SDK launches subprocess)	[N/A]
Google	2025-11-25	[Full]	[Full]	[N/A]
Cloudflare	2025-11-25	[Full]	[Partial] (via mcp-remote adapter)	[Partial] (McpAgent.serveSSE for back-compat)
AWS	2025-11-25	[Full]	[Partial] (Runtime can host stdio servers)	[N/A]

7.2 Authorization model

* You can sort the table by clicking on the column name.

Vendor	OAuth 2.1 + PRM	DCR (RFC 7591)	API Key	IAM SigV4
Anthropic	[Full]	[Full] (Claude.ai Connectors)	[Partial] (Messages API Connector header)	[N/A]
OpenAI	[Full]	[Full] (ChatGPT Custom Connectors)	[Full] (Responses API `headers`)	[N/A]
Google	[Full]	[Partial]	[Full]	[N/A] (uses Google Cloud IAM tokens)
Cloudflare	[Full] (Workers OAuth Provider)	[Full]	[Full]	[N/A]
AWS	[Full] (Cognito/Okta/Auth0)	[Partial]	[Full]	[Full] (Gateway outbound, Credential Exchange)

7.3 Primitive support across the stack

* You can sort the table by clicking on the column name.

Vendor	Tools	Resources	Prompts	Sampling	Roots	Elicitation
Anthropic	[Full]	[Partial] (SDKs full, Messages API Connector tool-only)	[Partial] (SDKs full, Connector skips)	[Full]	[Full]	[Beta]
OpenAI	[Full]	[Partial] (ChatGPT only, not Responses API)	[Partial] (ChatGPT only)	[Partial] (ChatGPT Enterprise/Edu)	[Partial]	[N/A]
Google	[Full]	[Full]	[Full]	[Full] (ADK)	[Full]	[Beta]
Cloudflare	[Full]	[Full]	[Full]	[N/A] (host-side support; clients rarely consume)	[Partial]	[N/A]
AWS	[Full]	[Partial] (Gateway passes through)	[Partial]	[Partial]	[Partial]	[N/A]

7.4 Operational features

* You can sort the table by clicking on the column name.

Vendor	Multi-tenant	Per-tool Observability	Quotas	Regional Residency
Anthropic	[Partial] (workspace scope)	[Partial] (inference logs only)	[Partial]	[Partial]
OpenAI	[Partial] (org/project scope)	[Partial]	[Full] (project quotas)	[Partial]
Google	[Full] (project/IAM)	[Full] (Cloud Audit Logs)	[Full]	[Full]
Cloudflare	[Full] (account/zone)	[Full] (Logpush)	[Full]	[Full] (Smart Placement)
AWS	[Full] (account/Cognito)	[Full] (CloudWatch, X-Ray)	[Full]	[Full] (per-region Gateway)

7.5 Key observations

Streamable HTTP is universally [Full] as of 2026-05. The deprecated HTTP+SSE legacy transport survives only because Anthropic's Messages API Connector and Cloudflare's McpAgent.serveSSE() still accept it for backward compatibility.
OAuth 2.1 with PRM is [Full] on all five implementations — making this the most uniformly implemented authorization layer in the MCP ecosystem, in lockstep with the 2025-11-25 spec's MUST requirements for PRM (RFC 9728), Resource Indicators (RFC 8707), and PKCE.
sampling is the most uneven primitive: [Full] on Anthropic and Google (ADK), [Partial] on OpenAI (ChatGPT Enterprise/Edu only), [N/A] on Cloudflare server-side (the SDK can declare it but most clients can't consume it), and [Partial] on AWS (Gateway passes through but Runtime client implementations vary).
elicitation is [Beta] or [N/A] on all five vendors. This is the youngest spec primitive (added in 2025-11-25) and has yet to receive a flagship implementation.
Multi-tenant quotas and per-tool observability are the clearest differentiators — Cloudflare, Google, and AWS lead, OpenAI and Anthropic trail because their primary product is inference, not hosting.

8. Decision Framework by Deployment Context

The decision table below maps each common deployment context to a recommended primary vendor and a fallback. The framework is intentionally short — a small table is more memorable and more cite-able than a flowchart. The rationale column lists the single decisive factor; secondary factors are discussed in Section 9. For a higher-level multi-cloud architectural comparison (cost, operations, security posture), see Enterprise AI Agent Environment Design Notes Part 3.

* You can sort the table by clicking on the column name.

Deployment Context	Recommended Primary	Fallback	Decisive Factor
Local desktop tool	Anthropic SDK	Cloudflare Workers + mcp-remote	stdio is the simplest transport; the Anthropic adapter ships the longest and is the reference for every other client.
Enterprise agent platform (AWS-resident)	AWS Bedrock AgentCore Gateway	Cloudflare Workers	Managed gateway, IAM-aligned auth, CloudWatch/X-Ray traces, and OpenAPI/Lambda target translation eliminate most server code.
Enterprise agent platform (Google Cloud resident)	Gemini Enterprise Agent Platform	ADK self-hosted on GKE	Managed MCP catalog (Maps, BigQuery, GKE, etc.) plus Apigee as an OpenAPI-to-MCP bridge.
Multi-cloud / cloud-neutral SaaS	Cloudflare Workers + Workers OAuth Provider	AWS AgentCore Gateway with cross-account IAM federation	Cloudflare is the only host whose deployment, authorization, and observability story does not assume a single underlying cloud.
Consumer-facing chat UX	ChatGPT Custom Connectors or Claude.ai Custom Connectors	Self-hosted UI on Workers + Agents SDK	Do not build your own chat UI; both consumer products are mature and well-documented.
Rapid prototype / hackathon	Cloudflare Workers (createMcpHandler + wrangler deploy)	AWS Lambda + Function URL	Deploy time is single-digit minutes; no OAuth needed for the first round if you use an API key header.
Multi-agent / supervisor pattern	AWS AgentCore Runtime + Gateway	Cloudflare Workers with Service Bindings	The 8-hour Runtime session window is the only managed implementation that comfortably hosts long-running supervisor loops.

9. Common Integration Pitfalls

The five pitfalls below are the most frequent integration failures I have observed during MCP onboarding engagements between late 2025 and mid-2026. Each is structured as Pattern → Failure mode → Mitigation so the entry is directly cite-able.

9.1 Treating OAuth 2.1 with PRM as optional

Pattern: An engineer reads the MCP spec, sees the Authorization section, and decides to ship with an API key header because "it's just a personal server."
Failure mode: When the server is later promoted to a remote endpoint, every downstream client (Claude.ai, ChatGPT Custom Connectors, Cloudflare Workers OAuth Provider, AgentCore Gateway) refuses to onboard it because PRM is mandatory for remote servers. The server needs a rewrite.
Mitigation: Implement PRM (RFC 9728) and DCR (RFC 7591) from day one; the Workers OAuth Provider library or the AgentCore Gateway take this off the developer's hands entirely.

9.2 Confusing the legacy HTTP+SSE transport with Streamable HTTP

Pattern: Tutorial code from 2024 uses two endpoints (one POST, one GET-with-SSE) and labels them as "the HTTP transport." A new server copies that shape.
Failure mode: The server is rejected by clients that require Streamable HTTP semantics (single endpoint, MCP-Session-Id header, optional GET-SSE).
Mitigation: Ensure every code path uses Streamable HTTP (2025-03-26 spec onward); the legacy HTTP+SSE transport is deprecated and exists only for backward compatibility.

9.3 Assuming sampling works everywhere

Pattern: An MCP server developer reads the spec, sees sampling/createMessage, and implements server-driven agentic loops. The server works against Anthropic SDKs in unit tests.
Failure mode: When deployed to OpenAI Responses API or AWS AgentCore Gateway, the server's sampling calls return errors because the host doesn't proxy sampling back to the model.
Mitigation: Gate sampling on initialize capability negotiation; fall back to a stateless tool when sampling is unavailable. Section 7 lists the support matrix.

9.4 Exposing too many tools

Pattern: A server developer auto-generates one MCP tool per OpenAPI operation. The resulting MCP server exposes 300 tools.
Failure mode: The model's tool-list token budget is exhausted before the user message is processed. Tool calling becomes unreliable.
Mitigation: Use a vendor with server-side or client-side tool search (AgentCore Gateway, Agents SDK HostedMCPTool), or split the server into multiple smaller MCP servers grouped by domain.

9.5 Skipping Resource Indicators (RFC 8707)

Pattern: The OAuth flow is configured but the resource parameter is omitted.
Failure mode: Tokens issued by the authorization server are bearer-bound but not audience-bound. A token leaked from one MCP server can be replayed against another MCP server on the same authorization server.
Mitigation: Always send resource=<server_url> on the authorization request and validate the audience claim on every tool call. The MCP spec marks this MUST in 2025-11-25.

10. Frequently Asked Questions

10.1 Which MCP implementation should a small team standardize on if it has no existing cloud commitment?

Cloudflare. The agents/mcp package plus the Workers OAuth Provider library is the lowest-cognitive-load path to production: a single command (wrangler deploy) ships a TLS-terminated, OAuth-2.1-compliant remote MCP server with PRM and DCR already wired in. Switching costs later are also lowest because the server is just a TypeScript fetch handler — the same code re-deploys to Node.js, Bun, or any other Streamable HTTP host with minimal changes.

10.2 If we already run on AWS, is AgentCore Gateway the right answer for every internal MCP use case?

Almost — with one caveat. If your downstream is a Lambda function, an OpenAPI-described API, or a Smithy model, AgentCore Gateway gives you a managed MCP front door with semantic tool search at no per-call code overhead. The caveat is when your downstream is another MCP server (typically built for portability). In that case you can still attach it as a target, but you sometimes inherit lower control over the per-tool behavior than you would in Cloudflare. For most AWS-resident teams the Gateway is still the right answer; the caveat applies mostly to hybrid setups.

10.3 Why does Anthropic's Messages API Connector only support tools when the SDKs support every primitive?

The Connector is currently in [Beta] (header mcp-client-2025-11-20). Anthropic has stated that tool-only support is a deliberate scoping decision for the beta because sampling and resources both require additional cross-API plumbing (sampling proxies inference requests back to the host model; resources require chunking into the model's context window). Full primitive coverage is on the roadmap but does not have a public ship date as of 2026-05.

10.4 Is WebSocket ever the right transport for MCP?

Almost never. WebSocket is not in the MCP spec — vendors that mention it are using a non-standard transport. Streamable HTTP already supports bidirectional streaming via the optional SSE side channel on GET requests, and it inherits the entire HTTP ecosystem (TLS, proxies, load balancers, OAuth). Use WebSocket only if you need ultra-low-latency duplex inside a single trusted network and you control both ends.

10.5 What is the difference between OAuth 2.1 with PRM and a plain Bearer Token?

OAuth 2.1 with Protected Resource Metadata (PRM, RFC 9728) is a discovery protocol that lets a client find the authorization server given the resource URL. A plain Bearer Token says nothing about which authorization server issued it or which resource it is valid against. PRM is mandatory for MCP servers because MCP clients (Claude.ai, ChatGPT, AgentCore Gateway) onboard servers by URL alone — they need a deterministic way to discover where to redirect users for authorization.

10.6 Is the deprecated HTTP+SSE transport safe to remove from a new MCP server?

Yes, as of mid-2026. Every major client (Anthropic SDKs, OpenAI Responses API, ADK, Cloudflare mcp-remote, AgentCore Gateway) accepts Streamable HTTP and is on a deprecation path for HTTP+SSE. New servers should ship Streamable HTTP only.

10.7 How do I expose an internal REST API as an MCP server without writing MCP code?

Two managed options exist: AWS AgentCore Gateway with an OpenAPI target, and Google Apigee with the MCP adapter. Both parse an OpenAPI 3.x spec and synthesize a tools/list. Authorization is brokered by the platform (Cognito/Okta/Auth0 on AgentCore, Google IAM on Apigee).

10.8 What are the practical operational differences between hosting an MCP server on Cloudflare Workers vs AWS Lambda?

The two runtimes differ along three operationally significant axes. Cold-start behavior: Workers run on V8 isolates and start in single-digit milliseconds, while Lambda cold-starts on ARM64 are typically tens to hundreds of milliseconds depending on the runtime and package size — for sub-second tools this difference is user-visible. Session state: Workers pair naturally with Durable Objects for MCP-Session-Id persistence and SSE resumption, whereas Lambda requires external state (DynamoDB, ElastiCache) because the function execution model is fundamentally stateless. Identity and authorization: Lambda integrates with IAM SigV4 and AgentCore Gateway's Credential Exchange for AWS-resident downstreams, while Workers integrate with Cloudflare Access and the Workers OAuth Provider for upstream IdP federation. Choose based on which side of the boundary your downstream resources live on. The MCP Server on AWS Lambda Complete Guide covers the Lambda path in implementation detail.

10.9 Can a single MCP server be attached to all five vendors at once?

Yes, provided it implements Streamable HTTP and OAuth 2.1 with PRM. The same server can be:

Registered as a Claude.ai Custom Connector.
Listed as a ChatGPT Custom Connector.
Configured as a Gemini Enterprise Agent Platform managed MCP target.
Hosted on Cloudflare Workers or attached as an external target via mcp-remote.
Attached to AgentCore Gateway as an MCP server target.

The single-server-many-clients pattern is what the spec was designed for. The most common reason teams end up with vendor-specific forks is when they unnecessarily depend on a non-portable feature (Service Bindings, Lambda event shape, IAM SigV4 outbound auth). Keep the server protocol-pure to maximize reuse.

11. Summary

By mid-2026 the MCP ecosystem has settled into a stable five-vendor pattern: Anthropic supplies the reference SDKs and the largest connector directory; OpenAI offers the cleanest API-side ergonomics and built-in approval gates; Google has the broadest model-agnostic developer kit and the deepest managed-server catalog; Cloudflare is the lowest-friction host for production-grade remote MCP servers; and AWS ships the most opinionated managed gateway through Bedrock AgentCore. The decisive variable when choosing between them is rarely raw protocol coverage — it is which surface (client, host, gateway, broker) you actually need.

The protocol itself is converging faster than vendor implementations. OAuth 2.1 with PRM is now the universal floor. Streamable HTTP is the universal transport. The remaining variation lives in sampling (uneven), elicitation (just landing), and the operational dimensions (quotas, observability) that the spec deliberately leaves to platforms. For platform architects that means the capability tables in Section 7 are the highest-yield artifact in this article: they show where you must compensate with platform features for what the protocol does not specify.

A periodic refresh of this reference is planned in coordination with the ecosystem reference. If you spot a vendor change between snapshots, please confirm against the official sources linked in Section 12 before acting. [Snapshot: 2026-05]

12. References

MCP specification and governance:

Anthropic:

OpenAI:

Google:

Cloudflare:

AWS: