The Model Context Protocol settled its place as a standard by now. What's more interesting for anyone building on top of it is how differently the three big vendors implemented the same spec, because those choices decide what you can actually ship.
What MCP standardized
MCP defines how a model talks to external tools and data through a server that exposes tools, resources, and prompts over a defined transport. Before it, every integration was bespoke client code. After it, a tool author writes one server and any MCP client can call it.
The adoption curve backs this up. Monthly SDK downloads across the Python and TypeScript SDKs went from around 2 million at launch (November 2024) to over 97 million by March 2026. The public server count passed 10,000. In December 2025 Anthropic donated the protocol to the Agentic AI Foundation under the Linux Foundation, with OpenAI, Google, Microsoft, and AWS backing it, which is what turned it from an Anthropic project into a neutral standard.
So the spec is shared. The implementations are not. Here's where they diverge.
Claude: local-first, servers on your machine
Anthropic treats MCP as part of Claude's native agentic loop. The servers run locally, in the desktop app or the terminal, over stdio. That means direct access to local folders, your running dev environment, and databases on your machine with no network hop in between.
Tradeoffs for a developer:
- Full local access and the most complete protocol support, since Anthropic authors the spec.
- Custom, non-catalog servers still mean editing JSON config by hand. That's fine for developers and rough for everyone else.
- The official Connectors Directory reached 439 entries by June 2026 for the one-click path, but the power is in wiring your own.
- MCP Apps (January 2026) added interactive UI previews pulled from tools like Figma and Slack into the chat surface.
If you're building developer tooling, this is the most flexible target.
ChatGPT: remote-only, rendered as apps
OpenAI went the opposite direction on transport. ChatGPT supports remote MCP servers only, reached over streamable HTTP. No local servers, no stdio.
What that buys and costs:
- Zero client-side setup for the end user. They enable your tool in settings and it works. No install step.
- You cannot run a local dev-style server the way you can with Claude or Cursor. Your server has to be hosted.
- The Apps SDK extends MCP so tool output renders as inline interactive widgets: cards, charts, forms, data tables, shown in an iframe inside the conversation.
- The App Directory opened to third-party submissions in December 2025 and passed 60 apps in early 2026.
This is the target if you want a consumer-facing tool that feels native to the chat, not a config screen.
Gemini: MCP behind Google Cloud governance
Google's implementation wraps MCP in enterprise infrastructure. The path runs from an enterprise data lake such as BigQuery, through Google Cloud IAM for permissions, into a centralized and audited MCP server, then to the model.
For a developer or platform team:
- Access goes through the Gemini CLI for local work and a fully managed remote MCP server for the Gemini Enterprise Agent Platform, launched June 30 2026.
- Google positions itself as the governed intermediary, so data stays inside its cloud boundary and audit trail even when a workflow routes to other models.
- Responses are structured rather than rendered as interactive UI. No iframe widgets yet.
- Google reported more than 50 managed MCP servers, with a cap of 100 enabled actions per custom server.
This is the target when governance and data residency matter more than UI polish.
Why the differences matter
The transport choice alone (local stdio vs remote HTTP) decides whether you can build a local dev tool or a hosted consumer app. The rendering choice (raw structured output vs interactive iframe widgets) decides whether your tool feels like a function call or a product. The governance choice decides whether an enterprise security team will let it near their data.
MCP made the connection layer a solved problem. That pushed the real competition up a level, to the experience built on top. Whichever platform you target, you're not choosing a protocol anymore. You're choosing a philosophy about where code runs, who renders the UI, and who holds the data.
Figures are the most recent public numbers as of mid-2026 and use different counting methods per vendor (a curated connector directory, an app store, a managed-server count), so read them as scale, not a like-for-like scoreboard.
Top comments (0)