# One Year of MCP: What's Working, What Isn't > Anthropic released the Model Context Protocol in November 2024. A year on: millions of server downloads, OpenAI and Google adoption, thousands of public servers. An honest read on what it delivered, where the gaps still are, and what I want from year two. Author: Abdul Hannan Shaikh, senior technical PM at APIMatic. Published: 8 October 2025 Topic: Agent-readiness Reading time: 8 min read Canonical: https://soch.ahshaikh.com/blog/one-year-of-mcp-whats-working/ --- The Model Context Protocol (**MCP**) turned one this week, give or take. Anthropic [released it in November 2024](https://www.anthropic.com/news/model-context-protocol) as an open protocol for letting LLMs talk to external data, tools, and systems. A year later the metrics are wild: **millions of server downloads**, **thousands of public servers**, [OpenAI](https://openai.github.io/openai-agents-python/mcp/) and [Google](https://techcrunch.com/2025/04/09/google-says-itll-embrace-anthropics-standard-for-connecting-ai-models-to-data/) support on top of Anthropic's own. By any normal measure of protocol adoption, MCP has cleared escape velocity. I want to write the honest one-year read. Not the marketing version. What MCP has delivered, where the gaps actually are, and what I'd want to see from the next twelve months. I am a product manager at APIMatic, where I own Context Plugins, an MCP server that gives coding agents deterministic API context. I have skin in the question because the integrations our customers want for their AI products keep coming back to MCP. The story I tell here is the story I tell in spec reviews. ## What's worked, more than expected ### The protocol shape was right [Tools, resources, prompts](https://modelcontextprotocol.io/) as the three primitives. It's a small surface area and it composes cleanly. The early objection was that JSON-RPC + STDIO was clunky compared to HTTP-based alternatives. A year in, the simplicity is the moat: every language has a working SDK because the protocol is small enough to implement in a weekend. ### The ecosystem unlocked fast Within six months of the launch, the [MCP server count](https://github.com/modelcontextprotocol/servers) went from "a handful Anthropic shipped" to thousands. Most of those are amateur or single-purpose, but the long tail matters. It means an agent integrating with an enterprise customer's stack can usually find a working MCP server (or a half-broken one to fork) for the third-party tools the customer already uses. That's the network effect a protocol needs to survive. ### OpenAI adoption was the legitimization moment [In March 2025](https://news.ycombinator.com/item?id=43485566), OpenAI announced MCP support across the Agents SDK, Responses API, and ChatGPT desktop. That converted MCP from "Anthropic's protocol" to "the protocol", roughly overnight. [Google followed in April](https://techcrunch.com/2025/04/09/google-says-itll-embrace-anthropics-standard-for-connecting-ai-models-to-data/) with Gemini. There's now no major model provider that doesn't speak MCP. ### The Inspector was underrated Anthropic shipped [a debugging UI](https://github.com/modelcontextprotocol/inspector) early. Point it at any MCP server, see the tools, resources, and prompts the server exposes, call them interactively. It's the kind of unsexy developer experience investment that produces a thousand more servers than the marketing material does. Reminds me of how Postman expanded REST API adoption: give people a way to poke at the surface and the surface grows. ## What hasn't worked, or hasn't worked yet ### Auth is still a mess MCP's auth story has improved ([OAuth 2.1 support](https://modelcontextprotocol.io/specification/draft/basic/authorization) landed mid-2025) but the practical reality is that connecting an MCP server to an enterprise identity system is still custom work every time. A good fraction of the public MCP servers I've audited either skip auth entirely (fine for local-only use, dangerous for anything else) or roll a bespoke pattern that won't audit clean. The protocol can't fix this alone (enterprise auth is a slow problem), but the gap between "MCP server works on a developer's laptop" and "MCP server is approved for an enterprise deployment" is wider than the launch posts suggested. ### Discovery is unsolved There's no canonical MCP registry. The closest things are loose lists on GitHub and a few independent directories. When an agent wants to use an MCP server for "Stripe", there's no authoritative answer about which one to use. Two servers might exist; one might be Stripe's official one; one might be a community fork; the agent has no signal for which is trustworthy. Postman has a registry. npm has a registry. Even crates.io and PyPI, with their imperfections, have a registry. MCP needs one. I expect a foundation move on this in the next twelve months. There are reasonable arguments for whether it should be Anthropic-owned, foundation-owned, or distributed, but the status quo (a GitHub awesome-list) doesn't scale to ten thousand servers. ### Production-grade context is rarer than it looks A working MCP server isn't the same as a useful one. I've watched agents integrate against MCP servers that technically exposed the right tools but whose descriptions were unhelpful, whose error messages were inscrutable, and whose example responses were absent. The agent technically had access to the API. It still hallucinated. The protocol gives you a connection. It doesn't give you good context. The work of producing context that an agent can use without guessing (naming, examples, error model, idempotency signals) is the same work that goes into good API docs. Most MCP servers are still skipping it because the protocol "works" without it. > **Diagram.** The anatomy of an MCP call, and the two gaps in it A call travels downward through six stacked layers, split into two bands. The upper band, labelled the connection layer, holds the host app (ChatGPT desktop, Agents SDK, Responses API), the MCP client (the Inspector), the transport (JSON-RPC and STDIO), and the MCP server. The lower band, labelled the context layer, holds the three primitives (tools, resources and prompts) and the external data, tools and systems behind them. Two gaps are called out. Gap one, auth, sits between the transport and the MCP server: OAuth 2.1 landed mid-2025, but connecting an MCP server to an enterprise identity system is still custom work every time. Gap two, context quality, sits on the boundary between the MCP server and its tools, resources and prompts: descriptions unhelpful, error messages inscrutable, example responses absent. The two gaps sit at different boundaries, which is the point: the protocol standardises the connection and does not standardise the context. *The two gaps sit at different boundaries. Auth breaks at the transport edge, where the server meets an enterprise identity system. Context quality breaks one layer lower, inside the tools, resources and prompts the server already exposes cleanly. A server can clear the first band entirely and still leave an agent guessing.* ## The pattern I keep seeing Companies build an MCP server in a weekend because the SDK makes it cheap. They ship it as a beta. Real customers connect. Then the gaps start showing: auth that doesn't survive procurement review, descriptions that aren't agent-readable, no example payloads, no error model documentation. The MCP server gets pulled or quietly deprecated. Six months later the team is rebuilding it. The lesson isn't that MCP is wrong. It's that MCP is the easy part. The hard part is the same hard part that's always been hard: producing the structured, deterministic context that lets an agent integrate without supervision. ## What I want from year two Four things, in roughly the order I think they'll happen: - A canonical registry, either foundation-stewarded or a clear community-blessed default. The discovery problem isn't going away on its own. - Better auth primitives: first-class OAuth flows that map cleanly to enterprise identity systems, not bespoke wrappers. - Server quality benchmarks: community-shared evals for whether an MCP server actually helps agents complete real tasks, not just whether it parses cleanly. - A serious conversation about "AI-agent-ready" beyond MCP. The protocol is necessary, not sufficient. The next category of investment is in the context layer above it, and I think that's where the strategic differentiation lives. Year one was the protocol gaining critical mass. Year two is where the gap between "works" and "useful" gets noticed, and the teams building for that gap will own the agent-integration layer. Everyone else gets to rebuild their server next year. ## Further reading - [Introducing the Model Context Protocol](https://www.anthropic.com/news/model-context-protocol) (Anthropic, November 25, 2024): the launch post. - [modelcontextprotocol.io](https://modelcontextprotocol.io/): spec, docs, and SDK entry points. - [MCP specification](https://modelcontextprotocol.io/specification): the protocol surface itself. - [Authorization (OAuth 2.1)](https://modelcontextprotocol.io/specification/draft/basic/authorization): the auth section of the spec referenced above. - [MCP GitHub organization](https://github.com/modelcontextprotocol) and [reference servers repo](https://github.com/modelcontextprotocol/servers). - [MCP Inspector](https://github.com/modelcontextprotocol/inspector): the debugging UI mentioned above. - [OpenAI Agents SDK, MCP support](https://openai.github.io/openai-agents-python/mcp/) (March 2025). - [Google to embrace Anthropic's MCP standard](https://techcrunch.com/2025/04/09/google-says-itll-embrace-anthropics-standard-for-connecting-ai-models-to-data/) (TechCrunch, April 2025): the Gemini adoption announcement.