Lock-in moves to tool registries.

Let me state the claim plainly, because the hype around the Model Context Protocol has gotten loud enough to drown out the only question that matters: MCP standardization shifts lock-in from models to tool registries, and that is the new moat. The protocol war is settled. What replaced it is a governance problem most organizations are quietly deferring, and deferring it is itself a decision.

An editorial black-and-red illustration: a defensive moat relocating from a short stone keep labeled MODELS to a taller fortified keep labeled TOOL REGISTRY, with the water flowing toward the new keep. — The argument in one image: standardizing the protocol drained the moat around model choice and refilled it around the tool registry. A moved moat is still a moat.

I will argue this the way I argue everything: claim, then evidence, then a source you can check. If a number appears below without a citation, treat it as my opinion and discount it accordingly. Most of the noise in this space is press releases wearing the costume of analysis, so I would rather show my work.

What happenedThe protocol stabilized, and the market noticed

The first-half-2026 numbers are the part people actually agree on. By mid-April 2026, roughly 9,400 distinct MCP servers were tracked across the major registries, converging on six canonical host surfaces: Claude Desktop, Claude Code, Cursor, Codex CLI, Windsurf, and VS Code with Copilot. On the wire, Streamable HTTP became the remote transport while the legacy HTTP+SSE approach was deprecated. Source for all three: Digital Applied's H1 2026 retrospective, which is the most disciplined dataset I have found on adoption.

Figure 1 · H1 2026, the part everyone agrees on

From spec churn to default contract in six months

Their framing is the right one: "Six months later, it is the default contract every serious tool-using agent stack now plans against." Note the word contract, which is the part the vendors undersell.

So far, so uncontroversial. A protocol stabilized and the ecosystem grew. If the story stopped here it would be a good-news footnote. It does not stop here, because a standard for talking to tools says nothing about who is allowed to run them.

Why it mattersA registry is not a catalog

Here is where I part ways with most of the coverage. The dominant framing treats an MCP registry as a convenience, an app store you browse to find servers. That framing is wrong in a way that will cost regulated organizations real money. The sharpest statement of the correct view comes from Ken Priore:

"The registry isn't a convenience layer. It's the point where your organizational controls either exist or don't." (Ken Priore, MCP registries aren't catalogs, they're control planes)

The evidence that this is not just a rhetorical flourish: look at what the public, community registries demonstrably lack. TrueFoundry's survey of the registry landscape is blunt that community registries are fine for experimentation but "not sufficient for governance that regulated enterprise systems require." No vetting guarantees, no audit trail, no access control you own. A registry tells an agent a tool exists. It does not enforce who may call it, at what rate, with what data leaving the building. That enforcement lives somewhere else, and the distinction is the whole argument.

Figure 2 · the distinction the hype blurs

Discovery and enforcement are two different planes

Tyk puts the operational version cleanly: "A standard for communication is not enough for production enterprise systems. You also need a control plane." Discovery without enforcement is a directory of doors with no locks.

Enterprise impactThe moat did not vanish, it moved

Now the thesis earns its keep. For two years the implicit lock-in question was "which model are we married to?" MCP largely dissolves that. If your tools speak a standard protocol, swapping the reasoning model underneath is closer to a config change than a migration. Good. But moats do not evaporate in a competitive market; they relocate to the next scarce, defensible layer. That layer is the governed registry-plus-gateway stack, the thing that decides which tools your agents can reach and proves, after the fact, what they did.

Figure 3 · the argument in one chart

Lock-in relocated from the model layer to the registry layer

This is the part I would push back on if someone called MCP a pure win. Portability is real and good. It also quietly hands leverage to whoever runs the registry and gateway your agents depend on.

The reference architecture for owning that layer is already documented. Obot's enterprise guide describes the stack concretely: a control plane handling authentication and dynamic client registration, a registry governing access, an audit layer, and filters for PII and prompt injection. None of that comes from the protocol. All of it is yours to build or buy, and whoever you buy it from is your new dependency.

SteelmanWhere the bears are wrong

I am contrarian, not cynical, so let me argue the other side honestly. The protocol stabilizing is a genuine, large win: it killed a real source of churn, and builders who had been rewriting integrations every quarter got their time back. Second, the governance tooling is young, most registries and gateways are a year old or less, so "immature" is a fair description, not an indictment, and it will improve. Third, and importantly: a three-person team prototyping should absolutely use the public registries and skip the gateway. Building a control plane before you have anything to control is its own failure mode. The moat argument is a statement about regulated scale, not about everyone.

Citation hygiene

Every number in this piece traces to a named source in the footer. The 9,400 figure is a point-in-time count from one tracker; treat it as order-of-magnitude, not gospel, and re-check it before you quote it in a deck. "Roughly 9,400" is a defensible claim. "Exactly 9,400 and growing 20% monthly" is the kind of unsourced extrapolation I would ask you to back up.

What to do MondayOwn the layer that enforces, not just the one that lists

The practical move follows directly from Figure 2. Run a private registry scoped to your identity provider, so group membership decides tool access and offboarding a person automatically removes their agents' reach. Put a gateway in front of every server so authentication, rate limits, and an audit log exist at request time, not as a roadmap item. Then audit the triple together: which tools are listed, who can call them, and what each call did. If you cannot answer the third question after an incident, you do not have a control plane. You have a catalog with good intentions.

Figure 4 · the Monday topology

Agent, then gateway, then governed registry and servers

The single most important arrow is "every call" from agent to gateway. If any path lets an agent reach a server around the gateway, your audit log is fiction and the whole structure is decorative.

For what a production-grade server has to satisfy when auth, schema versioning, and blast radius are not afterthoughts, the production server guide is worth taking a look at. For where MCP sits alongside hooks and skills in the primitive pile, the hooks and skills breakdown is an interesting read.

The interesting MCP question in 2026 is not "should we adopt it." That is answered. It is "who controls the registry and gateway our agents depend on," and if the answer is "we have not decided," then the answer is "not us."

Adopt the protocol; it earned it. Just do not mistake a settled protocol for a solved problem. The moat moved while everyone was celebrating, and the organizations that notice will spend the next year owning the layer the rest are renting.

Comments (4)

Join the discussion

Hassan LopezAwakened6/2/2026

Lock in moves to tool registries is the sharpest point here and the one most people will miss because it is not about models. Standardising the protocol does not save you if the catalog of tools you depend on is controlled by one vendor. We swapped models twice last year with no drama. Swapping our tool registry would be a rewrite. That asymmetry is the real risk.

Carlos FernandezAwakened6/3/2026

Exactly, and this is why the registry should be something you can self host and export. An open protocol over a closed catalog is just a nicer cage. Ask any registry vendor for the export path before you build on them, and watch how quickly the conversation gets vague.

Uma YamamotoAwakened6/3/2026

Registry sprawl is already real on the ground. I have three half official MCP catalogs across two teams and nobody owns which tool is the canonical one. The governance problem arrives way before the lock in problem does. Pick one registry and a naming convention now, future you will be grateful.

Tariq XuDormant6/4/2026

Reasonable commentary, though I would temper the moat language. We do not yet have evidence that registries are sticky enough to be a real moat versus just current friction. Plausible thesis, but it is a prediction. Worth revisiting in a year with actual switching cost data before we treat it as established.