What MCP Got Right That Earlier Plugin Standards Didn't

Software has a long, mostly unhappy history of plugin standards that launched with real momentum and quietly died within a couple of years. Browser plugin APIs that fragmented across vendors. Chatbot platform integrations that lived and died with a single company's product decisions. Early "AI plugin" specifications, including attempts that predate MCP by only a year or two, that generated initial developer interest and then stalled once the sponsoring platform's priorities shifted. Against that backdrop, MCP reaching 9,652 registry servers and roughly 97 million monthly SDK downloads by mid-2026 isn't just a success story — it's a survivor's story, and survivors are worth studying for what they did differently.

The scope discipline that most plugin standards skip

A common failure mode for integration standards is trying to specify too much. Early attempts often bundle UI conventions, authentication flows, billing hooks, and discovery mechanisms all into one sprawling spec, on the theory that a complete standard needs to cover the complete integration surface. That sounds thorough. In practice it means the spec has more surface area to disagree about, more reasons for different implementers to diverge, and more work required before anyone can ship a minimal, compliant implementation.

MCP's core abstraction — tools, resources, and prompts, with a clear capability negotiation model — is narrow by comparison. It specifies how a client and server exchange capabilities and calls, and mostly stays out of everything else. That narrowness wasn't a limitation, it was the design decision that let 9,652 different servers, built by wildly different organizations for wildly different purposes, all speak the same protocol without a central authority arbitrating every edge case. A spec that tries to standardize less, correctly, tends to get adopted by more people than a spec that tries to standardize everything and gets it wrong somewhere for everyone.

Transport-agnostic design as insurance against obsolescence

Plenty of earlier integration standards tied themselves tightly to a specific transport or hosting model that made sense for the constraints of their moment and then became a liability once those constraints changed. MCP's approach — supporting multiple transports and, as of the 2026-07-28 spec, moving to a stateless architecture specifically to support cloud-scale load balancing — reflects a design philosophy that treats the underlying infrastructure as something that will keep evolving, rather than something to be assumed fixed at launch. That's a harder spec to write initially. It's a much easier spec to keep alive once real-world deployment patterns turn out different from what the original authors guessed.

Governance that matched the neutrality claim

This is the theme that runs through the rest of this series, but it belongs here too as a design choice in its own right, not just a corporate decision. A lot of failed plugin standards were technically fine and died anyway because they stayed under the control of the single company that launched them, which capped adoption at that company's own competitive boundary — competitors had no reason to build on a rival's leverage point. MCP's donation to the Agentic AI Foundation under Linux Foundation stewardship, thirteen months after launch, removed that ceiling before it became load-bearing. That's a governance decision, but it's inseparable from the protocol's actual design success, because a technically excellent spec that stays vendor-controlled hits the same wall a mediocre one does — competitors won't build core infrastructure on either.

Timing the ecosystem couldn't have controlled, but caught well

Some of MCP's success is genuinely circumstantial rather than a pure design credit: it launched in November 2024, right as the industry-wide shift toward agentic AI systems — models that take actions, not just generate text — was accelerating hard. A protocol for standardizing how models call external tools landed at almost exactly the moment demand for that capability was about to explode. Earlier plugin standards, including some technically reasonable ones, launched into markets that weren't yet organized around agentic use cases the way 2025 and 2026 turned out to be. Timing doesn't explain the whole outcome — the security audit covered in this series shows plenty of the ecosystem still cutting corners under that same demand pressure — but it's honest to say MCP caught a wave that earlier attempts couldn't have, no matter how well-designed they were.

A specific comparison worth naming directly

Earlier AI-era plugin attempts often tied their integration model tightly to a single chat interface's conversational turn structure — designed around a specific product's UI conventions rather than a general-purpose calling model. That made them fast to build against for that one product and nearly useless anywhere else, because the assumptions baked into the spec didn't transfer. When the sponsoring product's priorities shifted, or a competing product wanted the same capability but couldn't adopt a spec built around a rival's UI, those standards had nowhere left to grow. They'd optimized for one company's roadmap instead of for the general problem.

MCP's tool/resource/prompt model, by contrast, doesn't assume anything about how the calling client presents information to a user — it just specifies how a client and server negotiate and exchange capabilities. That's the practical payoff of the scope discipline discussed above: a spec that doesn't encode one product's UI assumptions is a spec any product can adopt without fighting the spec's own design to do so. It's a small technical choice with an outsized effect on who's structurally able to build against the standard at all.

The trade-off this comparison surfaces

None of this means MCP got everything right. The stateless migration was a genuine breaking change that cost real implementer effort, evidence the original design didn't anticipate its own success. The 82% path-traversal rate in the 2026 audit is evidence that scope discipline in the spec didn't translate into security discipline in the implementations built on top of it — a narrow, well-designed core protocol doesn't automatically produce secure servers; that's a separate and unsolved problem for the ecosystem, discussed in more depth elsewhere in this series. Getting the protocol design and the governance model right was necessary for MCP to survive where earlier standards didn't. It wasn't sufficient to make everything built on top of it trustworthy.

The SDK quality bar as an underrated fourth factor

There's a fourth factor worth naming alongside scope discipline, transport-agnostic design, and matched governance: the actual quality of the reference SDKs. A protocol spec is a promise; an SDK is the thing a developer actually touches first, and a mediocre SDK can sink an excellent spec just as effectively as bad governance can. MCP's Python and TypeScript SDKs pulling a combined 97 million downloads a month isn't only an adoption signal, discussed elsewhere in this series with appropriate skepticism about what raw downloads prove — it's also evidence that the SDKs are good enough that developers who try them keep coming back, month over month, rather than trying once and moving on.

Earlier plugin standards frequently under-invested here, treating the SDK as an afterthought to the "real" spec document, and paid for it in bounce-off rates that never fully materialize in any public number but show up unmistakably in stalled adoption curves. MCP's early SDK investment — well-documented, idiomatic in each target language, not just a thin wrapper over raw JSON-RPC — lowered the cost of the first fifteen minutes with the protocol, and first-fifteen-minutes cost is a much bigger determinant of long-run adoption than most spec authors want to admit.

Why this comparison is worth making at all

It's tempting to treat MCP's success as self-evidently deserved — the numbers are good, so the design must have been right. Comparative history is a better test than raw numbers alone, because it isolates what MCP specifically did differently from the standards that came before it and didn't make it: narrower scope, infrastructure-agnostic design that could absorb an architectural rewrite without dying, and governance that matched its neutrality claims instead of just asserting them. Those are transferable lessons for anyone building the next integration standard, in AI or anywhere else. The plugin standard graveyard is full of specs that got the technical design roughly right and the governance wrong, or vice versa. MCP is one of the rare cases that got enough of both right to still be standing a year later — even while carrying real, unresolved problems of its own.

Part of the "MCP One Year In" series on aiskill.market.