Six months ago, the Model Context Protocol was the exciting new thing. By the middle of 2026, it had become something less exciting but far more important: a piece of infrastructure that much of the AI ecosystem now depends on.

Over the first half of the year, MCP changed hands, gained a user interface, had its core protocol rewritten, and ran into the security problems that tend to appear once millions of people rely on something. None of those are the problems of a promising idea. They are the problems of working infrastructure, and the first half of 2026 is when MCP started dealing with them.

If you are new to the protocol, our overview — Model Context Protocol (MCP): A Unified Standard for AI Agents and Tools — is the place to start. The rest of this post assumes the basics and focuses on what actually changed.

Governance moved to a neutral foundation

The most important change happened right at the start of the period, and it shaped everything that followed.

On December 9, 2025, Anthropic donated MCP to the newly formed Agentic AI Foundation, a fund under the Linux Foundation. Block and OpenAI were co-founders, and AWS, Google, Microsoft, Cloudflare, and Bloomberg joined as platinum members.

This matters more than it might sound. A protocol controlled by a single AI lab is a risk for every competing lab that adopts it, because that lab could change the standard in its own favor. Handing MCP to a neutral foundation removes the concern, since changes now go through a public proposal process in which every major lab and cloud provider has a seat, and none of them benefits from breaking the protocol for the others.

Google’s A2A protocol moved under the same foundation, with a clear division of responsibility: MCP connects agents to tools, while A2A coordinates communication between agents. Together, these two moves settled much of the fragmentation the ecosystem had worried about throughout 2025.

Adoption kept climbing

To put that in perspective, the React npm package took about three years to reach the download numbers MCP reached in sixteen months.

The composition of that growth is as telling as its size. Fewer than 5% of public servers are monetized, so the ecosystem remains largely open source, and the momentum is shifting from community experiments toward vendor-built connectors and private, enterprise-internal servers. In short, MCP is moving from something developers try out to something companies run in production.

The protocol matured

Two releases turned MCP from a promising design into something built for scale.

The first was MCP Apps, which shipped in January as the protocol’s first official extension. It lets a tool return an interactive HTML interface that renders directly inside the conversation, such as a dashboard, a form, or a live visualization, all running in a sandboxed iframe. Figma used it to offer inline component editing, and Hex used it to render a filterable dashboard. It is worth noting that Anthropic and OpenAI developed the extension together, and it launched with support in Claude, ChatGPT, Goose, and VS Code on the first day.

The second was the 2026-07-28 release candidate, locked in May, which is the largest revision to the protocol since it launched. Its central change is that MCP becomes stateless.

• The initialize handshake and the Mcp-Session-Id header are gone. Protocol version, client information, and capabilities now travel in the _meta field of every request.
• This matters because a stateless server can sit behind an ordinary load balancer, with no sticky routing, no session store, and no long-lived streams to maintain. That is what allows MCP to scale on standard HTTP infrastructure.
• The release also adds operational features, including required Mcp-Method and Mcp-Name headers that let gateways route traffic, and HTTP-style caching fields on discovery responses.
• Finally, it introduces a formal deprecation policy. Roots, Sampling, and Logging are deprecated, but nothing is removed for at least twelve months.

Most existing servers continue to work unchanged. But the intent behind the release is clear: MCP is being re-engineered to be predictable and unremarkable, which is exactly what dependable infrastructure should be.

Security caught up with adoption

Rapid growth came with a cost. In January and February alone, more than thirty MCP-related CVEs were filed, including a remote-code-execution flaw rated 9.6 on the CVSS scale.

The defining issue was tool poisoning, and the problem is structural rather than a bug in any single server. A tool’s description is text the server controls, and it lands in the model’s context as if it were a trusted instruction. A malicious server can hide a directive in that description — for example, telling the model to read the user’s SSH key and pass it as a parameter — and an instruction-following model will comply. The user never sees the directive, because tool descriptions are not shown in the interface.

The underlying weakness is a gap in trust. A tool’s description is reviewed once, when the agent first connects, but the tool’s responses flow into the model afterward without any equivalent check. The defenses that emerged are layered: sanitizing tool metadata and responses, isolating high-privilege tools, scanning server manifests, and disabling the “always allow” settings that run tools without confirmation.

These are the problems of a widely used protocol rather than a niche one. The March roadmap responded to them directly by making enterprise readiness — audit trails, single sign-on, and gateway support — its top priority, to be delivered mostly through extensions rather than changes to the core.

What this adds up to

Taken together, the first half of 2026 tells a single story. MCP finished moving from a clever idea owned by one company to shared infrastructure governed by a foundation, and it began to behave accordingly.

What makes the period unusual is that all of this happened at once: record adoption alongside a candid acknowledgment, through both the rewrite and the security work, that the original design was not built for the scale it had reached. That is less a contradiction than a sign of maturity. MCP has moved past the stage of being interesting and into the more demanding stage of being relied upon.

Where SerpApi fits

If you are building agents on top of MCP, live search is one of the most useful capabilities you can give them, and you do not need to build the connector yourself.

The SerpApi MCP server exposes a single search tool that any MCP client — Claude Desktop, Cursor, VS Code, or your own agent — can call to query more than 100 engines and receive structured JSON in return. We have also exposed each engine’s schema as an MCP resource, which improves the accuracy of tool calls and aligns well with the discovery and caching direction the new specification is taking.

If you would prefer a lighter setup inside Claude Code, the SerpApi Claude Code plugin gives Claude native search through a single skill, with no server to run. MCP is the better choice when you work across several clients, while the plugin is simpler when you work primarily in one.