The number that made me stop scrolling: 97 million. That's how many times developers downloaded an MCP SDK last month. The Model Context Protocol went from an Anthropic curiosity in late 2024 to a cross-vendor standard adopted by OpenAI, Anthropic, Google, and Mozilla by mid-2026.
So what does that actually mean for you?
It means the integration tax you've been paying — writing custom tool-calling glue for every new LLM provider, every new data source — is finally becoming optional. And that changes the architecture decisions you make today.
The Actual Problem MCP Solves
Before MCP, integrating an LLM with your codebase, a database, an API, meant writing one-off prompt engineering and hoping the model figured out when to call your function. It was brittle, model-specific, and required re-engineering every time you switched providers.
MCP replaces that with a standardized protocol. Instead of custom integrations, you point your agent at an MCP server and it can use whatever tools that server exposes — the same way, regardless of which LLM is running underneath.
Here's what that looks like in practice. Using the TypeScript SDK:
import { Client } from "@modelcontextprotocol/sdk/client";
const client = new Client({
name: "github-integration",
version: "1.0.0",
}, {
capabilities: { tools: {} }
});
await client.connect(new SSEServerTransport(
"github-mcp-server",
process.stdin,
process.stdout
));
// List available tools — no custom schema parsing
const tools = await client.request(
{ method: "tools/list" },
{ method: "tools/list", params: {} }
);
The protocol handles discovery, schema negotiation, and transport. Your code talks MCP. The server implements the tools. The model calls them. Vendor lock-in drops out of the equation.
What 97M Downloads Actually Tells You
Downloads aren't the same as production deployments. But the split is revealing: 5,800+ public MCP servers, official SDKs in TypeScript, Python, C#, Java, and Swift, and Linux Foundation stewardship since December 2025. This isn't a science project anymore.
The interesting signal is the enterprise data: 80% of Fortune 500 companies deploying active AI agents by early 2026, with MCP as the tool-integration layer. That's not startups experimenting — that's production infrastructure decisions being made at scale.
The spec itself is evolving fast. A release candidate ships July 28, 2026, with breaking changes. The transport layer is solidifying around SSE and stdio, and agent-to-agent coordination via A2A is on the roadmap for H2 2026. If you're building now, lock your dependencies and watch the changelog.
Evaluating MCP Systems in Production
Here's where most teams I've talked to go wrong: they test whether the model can call the right tool, and call it done. But MCP evaluation has three layers that are easy to conflate.
Tool Correctness — deterministic. Did the agent call the right tool with the right parameters? Check the schema against the call trace. This doesn't need an LLM judge; you can verify it directly.
Trajectory Quality — did the agent use the fewest necessary tools to get to the right answer? An agent that makes six tool calls when two would do is expensive to run and slow. Trace the full execution path and count hops.
Context Efficiency — this is where the 96-99% token waste number comes from. Every turn sends the full tool schema to the model, even when nothing changed. The mcp2cli project documents how dramatic the savings are when you cache and delta-encode schema diffs. Measure input token count per turn before and after optimization. That's your real efficiency metric.
# Simple trajectory logger you can drop into any eval run
def trace_trajectory(client, task_prompt):
calls = []
for response in client.iter_completion(task_prompt):
if response.tool_calls:
calls.append({
"tools": [tc.name for tc in response.tool_calls],
"input_tokens": response.usage.input_tokens,
"output_tokens": response.usage.output_tokens,
})
if response.finish_reason == "stop":
break
return calls
Track these three metrics separately. Conflating them is how you end up with a system that "passes" evaluation but costs three times more than it should in production.
Why This Matters More Than Model Benchmarks Right Now
Every month brings a new leaderboard entry. GPT-5.4, Claude Opus 4.6, Gemini 3.1 — they're all capable enough that the integration layer matters more than the marginal capability difference between them for most use cases.
If you're evaluating LLMs for a production agent system, ask: can I swap this model out with one click? If your tool-calling logic is MCP-based, you can. If it's custom prompt engineering and JSON parsing, you can't — and you won't, because the switching cost is too high.
That's the real strategic bet in the MCP ecosystem. It's not about which model wins. It's about not being stuck when the next one does.
The 97M downloads are a proxy for something real: teams deciding that standardized integration is worth building around, even when the spec is still maturing. That's the right call for anything running longer than six months.
What I Learned
Three things stand out from digging into MCP production deployments:
1. The protocol is stable enough to build on. The July 28 RC has breaking changes, but they're documented. Pin your SDK version, review the migration guide, and proceed.
2. Evaluation is the hard part, not integration. Getting MCP servers running is documented well enough. Getting confidence that your agent is using them efficiently — that's where the work is, and where most teams I've seen don't invest enough.
3. Watch the A2A protocol. Agent-to-agent coordination is coming in H2 2026. If you're building multi-agent systems, MCP's evolution toward that matters for your architecture decisions today.
The MCP ecosystem is past the point of "interesting experiment." It's production infrastructure for teams that have decided AI agents are going to run in their systems for the long haul. The 97M downloads are a signal that a lot of teams made that same calculation.
Top comments (0)