10,000 MCP Servers Later, the Hard Part Isn't Building One — It's Being Found and Trusted

MCP crossed 10,000 active public servers and 97 million monthly SDK downloads in 2026. On December 9, 2025, Anthropic donated the protocol itself to a newly formed Agentic AI Foundation under the Linux Foundation, co-founded alongside Block and OpenAI, with Google, Microsoft, AWS, Cloudflare, and Bloomberg backing it. By any growth metric, MCP won the race to become the default way an AI agent talks to a tool.

Here's the number that matters more if you're about to ship the 10,001st server: independent audits of the public registry found that 52% of listed MCP servers are abandoned, and only 17% meet a reasonable production bar. Scale didn't fix discoverability or trust — it made both worse. bex has an MCP server on its roadmap, the natural interface for an agent that deploys and operates apps directly instead of clicking through a dashboard. Shipping into an ecosystem this size, this fast-moving, and this uneven in quality means the interesting design questions aren't about wiring up tool handlers. They're about what to adopt from a protocol still mid-rewrite, what a security research year already ruled out, and what actually makes a new server visible and trusted in a pile of 10,000.

How big MCP actually got in 2026​

The scale numbers, gathered from the protocol's own governance announcements and independent registry audits:

The governance move is worth pausing on. MCP is no longer an Anthropic-controlled spec — it's a founding project of a vendor-neutral foundation alongside Block's goose agent framework and OpenAI's AGENTS.md, with every major model vendor now a stated supporter. That matters for anyone building against it: the protocol's roadmap is set by a standards body with multi-vendor buy-in, not a single company's product priorities, which is exactly the kind of foundation a platform wants under an interface it plans to depend on long-term.

Why launching a new server is a trust problem, not a technical one​

Building an MCP server that correctly exposes deploy, rollback, scale, and logs as callable tools is a solved problem — the SDKs handle the wire protocol, and bex already has a Render-compatible REST/GraphQL API to wrap. The 52%-abandoned, 17%-production-grade split is the actual obstacle: it means an agent or a registry crawler encountering a new, unfamiliar MCP server has statistically more reason to distrust it than not. A server with no track record, no registry presence, and no verifiable maintenance signal looks exactly like the 83% of servers that don't meet a production bar, until it proves otherwise.

That reframes what "ship an MCP server" needs to include from day one:

• Registry presence, not just a working endpoint. A server nobody's crawler or directory indexes is invisible to the agents that would use it. Publishing to the official MCP Registry (and staying current there — the same audits that found 52% abandonment are watching for updates, not just initial listings) is part of shipping, not a follow-up task.
• A maintenance signal an agent can check before it trusts the tool list. Version pinning, changelog presence, and response to the registry's own liveness checks are the difference between looking like the 17% and looking like the 52%.
• Restraint on tool surface. A server exposing twelve tools it barely maintains is a worse trust signal than one exposing four it keeps correct. bex's roadmap MCP server should ship the deploy/rollback/scale/logs core completely before it grows the surface.

The protocol is mid-rewrite — build against where it's going​

The MCP spec's next major cycle, targeted for June 2026, drops the initialize/initialized handshake and the Mcp-Session-Id header that current servers rely on to pin a client to one server instance. Protocol metadata moves into _meta on every request instead of being negotiated once at connection start, and a new server/discover method lets a client fetch a server's capabilities without opening a live connection at all. The practical effect: any request can land on any server instance, because there's no session state a specific instance is required to hold.

Alongside stateless transport, MCP Server Cards — structured server metadata published at a .well-known URL — let registries, crawlers, and orchestrating agents evaluate what a server can do before they ever open an MCP connection to it. That's the discoverability half of the trust problem above: a Server Card is a machine-readable answer to "should an agent even bother connecting here," published before any handshake happens.

Both changes favor a platform running its MCP server behind a horizontally-scaled control plane rather than a single long-lived process, which is exactly bex's deployment shape on Cluster API–managed nodes:

• Building session affinity into the server now is building something the June 2026 spec deletes. A server designed to pin clients to one instance via Mcp-Session-Id needs that logic ripped out in six months. Designing for stateless, any-instance-can-answer requests from the start avoids the retrofit.
• A Server Card costs almost nothing to publish and pays off immediately. Static JSON at a well-known path, describing bex's deploy/rollback/scale/logs surface, is worth shipping alongside the server itself — it's the cheapest discoverability move on this list, and it doesn't wait for the spec to finalize since crawlers can start reading it today.

The security bar the growth numbers don't mention​

The most cited MCP vulnerability class in 2026 is tool poisoning: a server's tool description or response contains instructions hidden from the human but visible to the model, which the agent treats as trusted input the moment it lands in context. OWASP classifies it MCP03:2025 with a DREAD score of 46.5 out of 50 — critical — and research testing 20 different LLM agents against poisoned tool descriptions found attack success rates up to 72.8%. A concrete instance landed as CVE-2026-13341, an indirect prompt injection against the Kong Konnect MCP server that caused it to execute unintended API requests on the caller's behalf. Separately, client-side testing found 5 of 7 evaluated MCP clients implement no static validation of the tool metadata a server hands them at all — the trust is close to unconditional by default.

None of this is exotic; it follows directly from what an MCP tool call actually is: a server-controlled string landing in the model's context, treated the same as any other trusted instruction. A platform whose MCP server can trigger deploy, rollback, and scale on production infrastructure is a higher-value target for exactly this class of attack than a read-only weather API, which sets a floor for what bex's server needs before it ships:

• Scoped, action-tiered tokens instead of one flat API key. A token minted for logs shouldn't double as a token that can call deploy. If a poisoned response or a compromised client ever does get an agent to call a tool it shouldn't, the blast radius is the token's scope, not the account's.
• No tool description ever becomes an instruction. Tool metadata bex's server returns is data the agent reads, never a channel the server uses to steer what the agent does next. That's a design discipline on the server side, not something a client's validation gap should be relied on to catch — especially given 5 of 7 clients currently don't validate at all.
• Confirmation gating by action severity. logs and status are safe to expose as autonomous tool calls; deploy and scale on a production service are exactly the actions worth gating behind an explicit confirmation step, mirroring the human-in-the-loop pattern the platform already needs for its own dashboard.

Having an MCP server isn't the differentiator anymore​

It's worth being honest about the competitive picture before treating "ship an MCP server" as a unique move: Render already shipped one covering services, deploys, env vars, and a subset of database operations. Railway exposes MCP through its CLI. Heroku has one covering a subset of CLI commands — apps, dynos, config vars, releases, basic add-ons. Every major git-push PaaS a self-hosted alternative gets compared against already has an agent-facing surface in production.

That means the differentiation bex is actually building toward isn't "has an MCP server" — it's what that server can do and how honestly it's scoped:

• Full parity with the deploy/rollback/scale workflow, not a CLI subset. Render and Heroku's MCP surfaces cover the day-to-day loop but stop short of full operational control. A server backed by bex's existing Render-compatible API can expose the complete lifecycle an agent needs to operate a service unattended, not just the common-case actions.
• Owned infrastructure underneath the tool calls. When an agent calls deploy through bex's MCP server, the action lands on a Cluster API–managed machine the operator owns — not a metered call against a vendor's rented capacity. The MCP server is an interface; the economics underneath it are still the actual pitch.
• The security posture above as a stated design property, not an afterthought. None of the Render/Heroku/Railway MCP announcements foreground action-tiered scoping or tool-poisoning defenses as a feature. Making that explicit is a differentiator precisely because it's currently absent from how competitors describe their own MCP surfaces.

What ships first​

Put together, the concrete build order for bex's MCP server looks less like "wrap the API in tool handlers" and more like a short, ordered list: stateless request handling designed for the June 2026 spec from day one (no session-pinning logic to rip out later), a published Server Card so registries and agents can evaluate the server before connecting, action-tiered scoped tokens with confirmation gating on anything that touches production, and a registry listing kept current enough to read as maintained rather than abandoned. None of that is exotic engineering. It's the checklist a server needs to clear to land in the 17% instead of the 52% — which, at 10,000 servers and counting, is the actual competition.

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 an agent can drive directly. Star the repo on GitHub or deploy your first app today.