Dora NodaThe protocol won. The Model Context Protocol went from an Anthropic experiment to the default interface between AI agents and tools in about sixteen months: more than 10,000 active public servers, roughly 97 million monthly SDK downloads, and native support in Claude, ChatGPT, Gemini, Copilot, Cursor, and VS Code. In December 2025, Anthropic donated MCP to the newly formed Agentic AI Foundation under the Linux Foundation, co-founded with Block and OpenAI. Nobody owns the spec anymore — which is exactly why the question of who owns everything around the spec just became the most important one in the ecosystem.
Because lock-in moved up the stack. The wire format is open; the discovery layer, the client defaults, and the trust signals are centralizing fast. If your roadmap includes an infrastructure MCP server — deploy from chat, fleet operations through an agent, machine-readable infrastructure state — here is the ownership case in one table:
| Layer your deploy path depends on | Rented version | Owned version |
|---|---|---|
| The server itself | A vendor-hosted endpoint that can change tools under you | A remote MCP server on your own machines, Streamable HTTP + OAuth 2.1 |
| The tool catalog | Whatever the client ships as defaults | A pinned catalog of audited server versions your team approved |
| Discovery and trust | A public directory's ranking, namespace, and moderation queue | A private registry surface where only your servers are listed |
An open spec does not keep your infra server discoverable, trusted, or under your control if the catalog layer centralizes. The rest of this post is the evidence for that claim and a sketch of what owning all three layers actually takes.
The spec is open. The ecosystem is centralizing.
Start with how fast the center of gravity formed. OpenAI adopted MCP in April 2025, Microsoft wired it into Copilot Studio that July, and by early 2026 the ecosystem counted 10,000+ public servers with SDK downloads near 97 million a month — growth one H1 2026 retrospective pegged at roughly 4,750% in sixteen months, a pace that took the React npm package about three years. Remote MCP servers are up 4x since May 2025. MCP is no longer a protocol teams evaluate; it is infrastructure teams assume.
That assumption is where the leverage moved. Four chokepoints now sit above the open wire format:
1. The official registry as the discovery chokepoint. The official MCP Registry launched in preview in September 2025 as an open catalog with a REST API, moderation, and namespace verification — effectively DNS for the ecosystem. It held roughly 9,650 server records by May 2026, while third-party directories like mcp.so and Glama report 20,000 or more because they count every fork and abandoned demo the curated registry excludes. Curation is the point and the problem: whoever runs the canonical listing decides what "the MCP server for X" is, which namespaces are verified, and whose entries survive moderation. GitHub's own MCP Registry launch, positioned as the discovery home base for Copilot and agents, adds a second gravitational center with the same dynamics.
2. Client defaults. Native MCP support now ships in every major AI client, and defaults are destiny: the servers a client bundles, suggests, or one-click-installs get the traffic. When ChatGPT, Claude, and Gemini each curate their own marketplace surface, "works with the protocol" and "reachable from the client your team actually uses" become two different bars.
3. Enterprise gateways. Microsoft, IBM, TrueFoundry, Composio, Kong, and HAProxy all ship MCP gateway products that proxy, filter, and policy-wrap server access. Gateways solve real problems — rate limiting, audit logging, response scanning — but each one is also a policy layer between your agent and your tools that somebody else versions, prices, and deprecates.
4. Hosted-server-first documentation. The major providers' docs increasingly present the hosted endpoint as the primary path, with self-hosted stdio servers as the legacy or advanced option. Sanity deprecated its npm-distributed MCP server in 2026 in favor of its hosted remote endpoint. Each such move is reasonable in isolation; in aggregate, the ecosystem's center of mass drifts from "run the server" to "call our endpoint."
None of this violates the open spec. That is the whole point: protocol openness constrains the wire, not the marketplace. The lock-in that matters for an infrastructure team is no longer "can we speak MCP" — it is "can our agents find, trust, and keep using our servers without permission from someone else's catalog."
Why an infrastructure server feels this first
Most MCP servers read data. An infrastructure server does things: it deploys apps, restarts services, rotates credentials, mutates fleet state. That makes it the worst possible place to rent trust — and MCP's trust model is still the ecosystem's weakest layer.
The threat set has names now, thanks largely to Invariant Labs' disclosures: tool poisoning (malicious instructions hidden in a tool description the model reads but the user never sees), rug pulls (a server that passes review today and rewrites its tool descriptions tomorrow, after the user already clicked "trust"), tool shadowing (one server's description reshaping another server's tool behavior), and naming collisions like typosquatted server names. OWASP files schema poisoning as MCP03:2025 in its MCP Top 10, and more than 30 CVEs targeting MCP infrastructure were filed in the first two months of 2026 alone, 43% of them exec or shell injection.
Read that threat set through the lens of a deploy-capable server and the rented-trust model falls apart twice. First, a rug pull against a deploy tool is not a data leak — it is arbitrary infrastructure mutation authorized by a trust decision made weeks ago against different tool definitions. Second, the ecosystem's own guidance concedes the gap: OpenAI's MCP documentation warns developers to prefer official servers hosted by the actual service provider and to treat third-party servers with caution. The official registry, still in preview, delegates actual code scanning to package registries and downstream aggregators. When the platform vendors themselves tell you the directory is not a trust boundary, believe them — and stop treating it as one for the server that can push to production.
This is the deploy-from-chat implication the TODO-sized version of this argument sometimes skips: the more capable your infra server is, the less its trust can come from a public catalog's ranking or a client's default list. Those signals were designed for discoverability, not for authorizing production deploys. The fix is not a better directory. It is owning the layers.
The ownership stack, concretely
Self-hosting "the MCP server" undersells the job. There are three layers, and each one you rent back reintroduces the dependency you just removed:
Layer 1: the server. Run a remote MCP server on machines you control, speaking Streamable HTTP with OAuth 2.1 + PKCE — the spec's required auth for multi-user remote servers. The July 2026 spec release hardened this further with RFC 9207 issuer validation, binding client credentials to the issuer that minted them. This is the easy layer: it is a container behind HTTPS, the same shape as every other service on your fleet. Kubernetes-native patterns are converging here — Google, Red Hat, and AWS are all standardizing on remote MCP servers deployed on Kubernetes rather than local stdio processes — and the rule of thumb from platform teams running this in production is blunt: stdio is for experimentation, HTTP is for team-scale access.
Layer 2: the catalog. Decide exactly which servers, at which versions, your agents may use — and pin it. A private catalog means a deploy-tool update is a reviewed change to your own manifest, not a silent upstream edit that lands the next time an agent session starts. This is also where the rug-pull defense lives: fingerprint tool definitions at approval time and reject silent drift, the way Microsoft's agent-governance work frames it as "definition drift from registered fingerprint." Your catalog is the list your agents are allowed to trust; everything else is untrusted input, including the public directory.
Layer 3: the registry surface. Give your agents a discovery endpoint you operate — Azure's private-MCP-registry pattern is the clearest enterprise template: a single source of truth for remote servers, internal or public, with your gateway applying policy in front. Your agents resolve tools against your registry, so a public directory's ranking change, namespace dispute, or moderation decision cannot silently reroute or delist the server your deploy pipeline depends on.
The honest limits, because "self-host everything" is a slogan, not a plan: you still inherit client behavior (how Cursor or Claude renders tool descriptions, how much context each tool costs), you still track the spec's evolution under AAIF governance, and you are now responsible for the availability of a service your deploy path depends on. What you bought is narrower and more valuable: no third party can change, delist, or re-trust your infrastructure tools without going through your review.
What self-hosting actually takes
Concretely, standing up the owned stack for one infrastructure server looks like this:
- Package the server as a container exposing Streamable HTTP on
/mcp, with OAuth 2.1 wired to your existing issuer. Fail closed: no token, no tools. - Deploy it like any other production service — health checks, replicas, TLS, audit logging of every tool invocation. If your fleet already runs HTTPS services from git push, this step adds nothing exotic.
- Pin it in your private catalog with a fingerprint of its tool definitions. Upstream releases become pull requests against your catalog, each one re-auditing descriptions for poisoning before promotion.
- Point your agents at your registry, not the public directories. Client configs reference your endpoint; discovery resolves against your list.
- Scan continuously: description-drift detection on every update, rate limits per tool, and an invocation log you can actually audit — the controls the enterprise gateways sell, applied to a server you own.
None of these steps requires permission from a foundation, a marketplace, or a client vendor. That is the test the rented stack fails: at least one layer of it always does.
Own the layers your deploy path depends on
MCP's first sixteen months were a standardization success story — one protocol, every client, foundation governance, hockey-stick adoption. Its next phase is an ownership story. The spec being open guarantees you can implement an infrastructure server; it guarantees nothing about whether your agents will find it, whether they should trust it, or whether it will still be the same server tomorrow. Those guarantees now live one layer up, in registries, defaults, and gateways — and that is exactly where a team running production infrastructure should be most reluctant to rent.
The good news is the owned stack is small: a container, a pinned catalog, a private registry surface. Build it once and your deploy-from-chat roadmap depends on your own review process instead of someone else's directory. In an ecosystem of 10,000 servers and 97 million downloads, the scarcest resource is not tools. It is justified trust — and that, you have to host yourself.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
