How the Protocol Won: MCP, One Year On

When something gets used 97 million times a month, by SDK download count, it stops being interesting in the "new framework" way. It becomes infrastructure. That's where the Model Context Protocol now sits.

The numbers, from Digital Applied's MCP adoption tracker, updated last month:

• 97 million-plus monthly SDK downloads.

• Around 10,000 active MCP servers in the public registry (9,652 at last count; 10K+ per Anthropic).

• 41% of surveyed software organizations in limited or broad production with MCP, per the Stacklok 2026 survey.

A year ago the answer to "how do I let my agent talk to my CRM" was "write a custom tool wrapper." The answer is now "use the MCP server" — and there's a 70% chance someone already wrote it.

That is what protocol-winning looks like. It's not loud. It's the moment "how do we integrate this" stops being a project and starts being a procurement question.

Why MCP and not something else

There were four serious contenders to be the agent-to-system protocol in 2024-2025. OpenAI's function-calling shaped the conceptual ground. LangChain's tool abstraction was the default for most agent frameworks. Microsoft had Semantic Kernel plugins. Anthropic had MCP.

MCP won for three boring, structural reasons:

1. It was vendor-neutral from day one. Anthropic shipped it as an open spec, with reference implementations, before anyone was forced to adopt. By the time it became dominant, every other model provider also supported it. That meant if you built on MCP, your investment didn't lock you to a model vendor.

2. The primitive set was small. Tools, resources, prompts. Three concepts. That's it. Compare to OpenAPI specs, which try to model everything. MCP was small enough that a smart engineer could implement a server in a day.

3. The ecosystem effects compounded fast. Once Cloudflare, Notion, Atlassian, Linear, GitHub, and Stripe all shipped first-party MCP servers, building one became table stakes for every SaaS company that wanted to be agent-addressable.

There is a fourth, less-discussed reason: MCP played well with how Claude actually behaved as a model. Claude was already the agent platform of choice for engineering teams in 2024. Building the protocol around the way the strongest agent model thought about tools made adoption frictionless.

The architecture that has emerged

Here is what an enterprise agent stack looks like in mid-2026, in the ones I'm working with. An agent (Claude, GPT, or open model) calls into a harness that handles orchestration, evals, and observability. The harness calls MCP servers — Notion, the internal CRM, Stripe, Jira, a handful of custom ones. The MCP servers, in turn, talk to the actual backing systems.

The MCP servers are the integration layer. They wrap legacy systems. They wrap modern systems. They wrap internal services. The agent never talks directly to the underlying API. It talks to the MCP server, which enforces auth, scope, audit, rate-limit.

This pattern matters for one specific reason: MCP servers are the place you put your security policy. The agent is non-deterministic. The model can be swapped. The harness can change. But the MCP server is deterministic code that you control, and it sits at the trust boundary. If you want to enforce that no agent can call a destructive endpoint without a human-in-the-loop, that lives in the server.

Three risks teams underestimate

I see three failure modes recur:

• Prompt injection through MCP tool descriptions. The descriptions are part of the agent's context. A malicious or compromised MCP server can put instructions in its tool descriptions and the model may follow them. Treat tool descriptions as untrusted input. Audit them in CI.

• Identity ambiguity. When the agent calls an MCP server, whose credentials does the server act on? The user's? The agent's own service account? A shared key? This is the question I'll spend Week 9 on, but the short answer is: define agent identity at the MCP-server level, not the framework level, because that is where the trust boundary is.

• Over-broad scopes. Most first-party MCP servers ship with permissive defaults to maximize developer experience. In production, you need scoped tokens. If your MCP server for Notion can read every page in your workspace, your agent can read every page in your workspace, regardless of which agent or which user asked.

What I'd procure today

If I were standing up an agent program from scratch in mid-2026, my MCP rubric for incoming systems would be:

1. Does this system ship a first-party MCP server? If yes, prefer it. The vendor has skin in the game and will keep it updated.

2. Does it support scoped tokens? If no, push back hard. Procurement leverage is real with vendors who want agent adoption.

3. Does it have audit logging at the MCP boundary? Not in the underlying system — at the server itself. This is where you'll need it when something goes wrong.

4. Is the server inspectable? Can you see what tools it exposes, what arguments they accept, what resources it can serve? Black-box MCP servers are a no.

That last point matters more than people realize. The reason MCP works is that it's introspectable. A blind agent can ask a server what it can do. You should be able to as well.

The thing protocols don't fix

MCP solved the integration-substrate problem. It did not solve the orchestration problem, the eval problem, the identity problem, or the governance problem. Those are still open — and each gets a dedicated post later in this series.

What MCP did do is take a question that consumed entire architecture meetings ("how do we let the agent reach the CRM") and reduce it to a procurement checkbox. That's the value. Protocols don't solve hard problems. They standardize the easy ones so that the hard ones have room to be hard.

If you want help thinking through your MCP architecture or which servers to procure first, that is the kind of embedded work my team at Applied Futures does with enterprise teams every week.

Next week, the most concrete capability jump of the last 18 months: browser agents went from a 15% benchmark score to 72.5%. What that actually means in production.