Dora NodaThe Model Context Protocol crossed 10,000 public servers and 97 million monthly SDK downloads in 2026, and every major model vendor now ships MCP support by default. The protocol war is over — MCP is the USB-C port of AI. But look one layer up and the leverage has moved: registries, managed gateways, and model-vendor tooling are quietly becoming the new lock-in surface. If you run agents against infrastructure, the question is no longer which protocol but who owns the endpoint, the credential scope, and the audit log. This post argues you should own all three — while speaking the standard.
About the numbers: the 10,000-server figure counts public MCP servers indexed across community registries (crossed in March 2026, up from roughly 1,000 at the start of 2025); the 97M figure is monthly SDK downloads across the official TypeScript and Python SDKs, up roughly 970x from ~100,000 in the first month. Both come from March–September 2026 ecosystem commentary. Caveats apply: registry counts include forks and duplicates, and download counts include CI reinstalls — but the order of magnitude is the point, and no competing agent-tool protocol is within one of it.
The short version for teams running a deploy-authority MCP server — one whose tools can ship code, restart services, or touch production:
| Decision | Own the endpoint (self-hosted) | Rent the managed layer |
|---|---|---|
| Discovery | Your registry/catalog, your approval workflow | Curated vendor registry; delisting risk |
| Credentials | Scoped tokens vaulted on your fleet | Per-user OAuth via vendor; keys transit vendor infra |
| Audit trail | Per-tool-call log exported to your SIEM | Vendor dashboard; export tiers and retention limits |
| Policy | Per-tool ACLs and allowlists you define | Policy model the vendor exposes |
| Cost shape | Fixed fleet capacity + ops time | Per-seat/per-token metering that scales with agent usage |
If your MCP tools are read-only conveniences, renting is fine. If they carry deploy authority, own the perimeter. The rest of this post shows why the protocol's victory makes that bet durable rather than contrarian.
How MCP became the layer nobody can route around
MCP's path from experiment to infrastructure ran through four milestones, each of which removed one objection to betting on it:
- November 2024 — Anthropic open-sources MCP. The pitch is the N×M integration problem: without a standard, every agent needs custom glue for every tool. The initial reception is curious but cautious — a single vendor's side project.
- March 2025 — OpenAI adopts it. Once the two leading labs back the same tool-calling standard, "what if we pick the Betamax of agent protocols" stops being a serious planning question.
- December 2025 — Anthropic donates MCP to the Linux Foundation's Agentic AI Foundation (AAIF). Neutral governance alongside Block's goose and OpenAI's AGENTS.md, with platinum backing from AWS, Google, Microsoft, Bloomberg, and Cloudflare. No single vendor can now steer the protocol against the ecosystem's interests.
- August 2026 — Google's A2A joins AAIF too. Agent-to-agent messaging and agent-to-tool calling now live under one governance umbrella. The analyst sequencing guidance — MCP first for sharing context, A2A second for dynamic interaction among agents — tells enterprises exactly how to stack them.
Underneath the governance story, the spec itself stabilized. The 2025-11-25 specification is the stable contract: stdio transport for local tools, Streamable HTTP for shared remote servers (the older HTTP+SSE transport is deprecated), and an OAuth 2.1 resource-server model for remote authentication, hardened further in the 2026-07-28 revision. Enterprise adoption numbers followed: roughly 78% of enterprise AI teams running MCP in production by mid-2026, first-party servers from MongoDB, Datadog, and Stripe, and client support across Cursor, Windsurf, VS Code Copilot, and Claude Code.
That is what "universal interface layer" means in practice. Not that every agent uses MCP today, but that no new agent-tool integration project in 2026 starts by inventing a wire protocol. The integration work — 10,000 servers of it — doesn't need rebuilding.
Where the lock-in actually moved: three concentrating layers
Open protocol, concentrating ecosystem. Nobody owns MCP, but three layers above the wire format are consolidating fast, and each one asks you to hand over something you used to control:
1. Registries — who decides what your agents can find. The community registry crossed 10,000 published servers, but enterprise attention is shifting to private, curated registries with approval workflows: which servers are blessed, which versions are pinned, who approved them. The commercial gateway wave of 2025–26 converges on exactly this bundle — curated registry plus SSO/SCIM, per-tool audit logging, and role-based access down to the tool level. Convenient, and a chokepoint: whoever curates your registry shapes which tools your agents ever see.
2. Managed gateways — who holds the credentials and the policy engine. A gateway between agents and MCP servers is genuinely good architecture — one inventory instead of a spreadsheet, per-tool authorization, prompt-injection inspection on every request. The catch is tenancy: per-user OAuth for third-party SaaS servers (GitHub, Slack, Atlassian) means the gateway vaults the tokens and injects them per call. Self-host that gateway and the vault is yours. Rent it and every credential your agents use transits vendor infrastructure, metered per seat or per token, under a policy model the vendor defines. Note the gap this monetizes: the MCP spec itself provides no standard for per-tool authorization, so every connected agent otherwise sees every tool — the "permission vacuum" that gateways exist to fill.
3. Model-vendor tooling — who sets the defaults. Built-in MCP connectors in the Messages API, managed "data stores" that only speak Streamable HTTP with vendor-registered OAuth clients, IDE-bundled server catalogs. Each default is reasonable in isolation; together they route discovery, identity, and billing through the model vendor's console. The protocol stays open while the path of least resistance narrows to one storefront.
None of this is a conspiracy — it's the standard lifecycle of a successful open protocol. HTTP is open; Cloudflare and AWS still capture enormous value above it. The question for a platform team is the same one it was for HTTP: which layers do you operate, and which do you rent?
What a self-hosted deploy-authority MCP endpoint actually looks like
A deploy-authority endpoint is an MCP server whose tools can change production: deploy a service, roll back a release, rotate a secret, scale a fleet. The enterprise controls that matured around MCP in 2026 give a concrete shape for running one on your own machines:
- Streamable HTTP remote server, OAuth 2.1 resource server. The moment the server is remote, you own authentication: RFC 9728 protected-resource metadata advertising your authorization server, tokens bound to your server's identity (RFC 8707 resource indicators) so a token can't be replayed elsewhere.
- Tool allowlist per agent, kept small. Published 2026 guidance converges on a least-privilege tool selection — on the order of eight or fewer tools per agent — with trust dialogs enforced and write-path servers gated behind human-in-the-loop confirmation for destructive or irreversible actions.
- Per-tool authorization at a gateway you operate. Since the spec doesn't define per-tool ACLs, the gateway enforces them:
default_tool_aclsfor the baseline, per-tool exceptions, identity binding so agents inherit scoped user permissions instead of standing credentials. - Per-tool-call audit logging, SIEM-exportable. Every invocation — who, which tool, which arguments, allow or deny — lands in an append-only log you control, not a vendor dashboard with retention tiers.
- Prompt-injection inspection on tool responses. Indirect prompt injection via tool output is the attack class MCP deployments actually face in 2026; the gateway inspects payloads for injection and policy violations before they reach the agent transcript.
The self-hostable building blocks exist today, with licenses that keep the perimeter yours: MCPJungle (self-hosted registry plus gateway), IBM's mcp-context-forge (gateway, proxy, and registry on FastAPI), Kuadrant's mcp-gateway and Kong's AI Gateway for teams already on those policy models, and Obot's MIT-licensed control plane bundling gateway, registry, and catalog. This is not a build-everything-yourself pitch — it's a compose-open-components-behind-your-identity-provider pitch.
Start the way the 2026 adoption playbooks recommend: two or three read-only servers behind the gateway, tight allowlists, trust dialogs on. Promote a server to the write path only once the confirmation UX for destructive actions is in place. The failure mode to avoid is the one the NSA's 2026 documentation flagged — connection-level consent silently granting repository-wide access because nobody scoped the tools.
The honest bill for owning the endpoint
Self-hosting is not free, and the managed layer is not a scam. Here's the tradeoff stated plainly:
What owning takes on: an authorization server to operate (or your existing IdP to integrate), a secrets vault for per-user SaaS tokens, prompt-guard inspection to tune, audit-log retention and SIEM export to maintain, and gateway upgrades to track against spec revisions. For a team already operating identity infrastructure and a Kubernetes fleet, this is incremental work on systems they own. For a team with no platform surface at all, it is a real project — weeks, not days.
What renting costs: per-seat gateway pricing plus per-token margins on proxied traffic, credentials for your production systems vaulted outside your perimeter, an approval and confirmation UX you can configure but not redesign, and a migration bill the day pricing or policy changes. The meter runs hardest exactly when agents succeed — more tool calls, more tokens, more seats.
The decision rule that falls out of the 2026 enterprise pattern:
- Read-only tools, conveniences, evaluation sandboxes → rent. The blast radius is a leaked API response, and the managed gateway's defaults (scoped OAuth, allowlists, logging) are better than what most teams would hand-roll for a side project.
- Write-path tools with production authority → own. The blast radius is a bad deploy at 3 AM with the audit trail in someone else's retention tier. Own the endpoint, the credential scope, and the log.
- In between → own the gateway, rent the servers. Run a self-hosted gateway in front of third-party SaaS MCP servers: you keep identity binding, per-tool ACLs, and the audit log while someone else operates the integrations.
One more consideration that cuts toward owning: protocol persistence. MCP under neutral foundation governance with 97M monthly downloads is not getting deprecated out from under you. A self-hosted endpoint is a durable asset that compounds — every new MCP server in the ecosystem is a tool your gateway can front — not a fork you'll have to rebase every eighteen months.
Speak the standard, own the perimeter
The September 2026 commentary got the frame right: MCP's persistence is assured, and the concentration is happening one layer up. That is not a reason to avoid MCP — it is a reason to meet it where the leverage is. Run your deploy-authority tools as a standard Streamable HTTP server, register it in a catalog you control, front it with a gateway that enforces your identity model, and keep the audit log on infrastructure you own. You get the 10,000-server ecosystem and the standard client support without handing the credential scope to whoever prices the managed layer most aggressively.
The open protocol won. Make sure the perimeter is yours.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with a Render-compatible API that AI agents can operate as first-class users. Star the repo on GitHub or deploy your first app today.
