10,000 MCP Servers and 97M Downloads Later, the Bottleneck Is Discovery

In November 2024, MCP was an Anthropic side project. By early 2026, it was infrastructure: more than 10,000 active public MCP servers in production, 97 million monthly SDK downloads, and first-class client support in Claude, ChatGPT, Cursor, Gemini, Copilot, and VS Code. The protocol won so completely that Anthropic donated it to the Linux Foundation's Agentic AI Foundation in December 2025, and a cross-vendor spec release followed in July 2026.

That victory created a new problem. When 10,000 servers all speak the same protocol, speaking the protocol is no longer the differentiator — being found is. Discovery, not interop, is now the bottleneck: an agent can only call a tool it knows exists, can afford to keep in context, and is authorized to invoke. For an MCP server that actually deploys apps — deploy, rollback, logs, the production verbs — that bottleneck splits into two distinct product problems: getting discovered, and getting trusted with production. This post works through both, with the verdict up front: ship a Server Card plus registry listing so agents can find you, scoped short-lived OAuth so no agent can self-escalate, least-privilege per-tool permissions, a read/write tool split with progressive disclosure of the dangerous verbs, and an audit log of every call. The sections below justify each item with the two case studies that define the state of the art.

How agents actually find tools today​

Start with the honest inventory of how a tool reaches an agent's context in 2026:

• Static configuration: host config files (mcp.json, claude.json) where a human pastes a server entry by hand.
• Registries: the official MCP registry lists roughly 6,400 servers, with community registries such as Glama and mcpmarket indexing tens of thousands more.
• Programmatic discovery: gateway products and model routers exposing semantic discovery endpoints that rank tools against a prompt by embedding similarity and return only the top-K matches.

All three paths share one hard constraint: context economics. Anthropic's progressive-discovery work brought the marginal cost of a known tool down to roughly 20–50 tokens — similar to Agent Skills — but "cheap per tool" still caps out. Ten thousand servers times dozens of tools each cannot all live in one context window, so discovery is a ranking problem before it is a wiring problem. The server that wins is the one that surfaces the right three tools at the right moment, not the one that exposes the most tools overall. That is the lens for the two case studies that follow: one solves discovery by collapsing thousands of integrations into a single brokered surface, the other proves that infrastructure-control servers are already useful enough that agents go looking for them.

Arcade: 7,000 integrations behind one OAuth-brokered surface​

Arcade is the clearest worked example of solving discovery at the integration layer rather than the protocol layer. The Arcade Engine — available hosted or self-hosted — handles OAuth user authorization, stores and refreshes user tokens, and exposes more than 7,000 pre-built integrations as MCP tools callable from LangChain, the OpenAI Agents SDK, CrewAI, AG2, Google ADK, Vercel AI, Mastra, and TanStack AI. The agent sees one MCP surface; the sprawl lives behind it.

The design choice that matters for our story is where the credentials sit. Arcade injects user tokens server-side at call time as part of its authorized-tool-calling flow, so the agent never holds a long-lived secret it could leak, log, or reuse out of scope. Scope-based permissioning applies per tool, and the open-source arcade-mcp framework plus arcade deploy gives teams the same pattern for their own custom servers, including OAuth on MCP servers and generally available MCP gateways. In other words, Arcade treats "which tools exist" and "which tools this agent may call, as this user" as one product — discovery and authority solved together at the broker.

That is exactly the right instinct, and it sets the bar: any deploy-app MCP server that is not behind a broker like Arcade has to answer both questions itself. The next case study shows what the self-hosted end of that spectrum looks like today.

The bridge that proves agents already operate infrastructure​

While Arcade works top-down from the integration catalog, the self-hosting world is growing the same pattern bottom-up. The coolify-anythingllm-mcp bridge is a small open-source MCP server that connects AnythingLLM — acting as the intelligent agent and UI — to the Coolify API, which executes the infrastructure tasks on a home lab or VPS. It is a purpose-built infra-control server: natural language in, deployment and management operations on real machines out.

It is not alone. Coolify itself now ships a built-in MCP server — enable it in Settings, point a client at https://your-coolify/mcp, and there is nothing to install, with the notable security property that it runs inside the instance, so no third-party code ever holds your API token. The community has gone further: StuMason's coolify-mcp exposes 42 token-optimized tools spanning infrastructure overview, app diagnostics, server management, and deployment. And the endpoint of this trajectory already has a Show HN: Ink, launched March 31, 2026, is a full-stack deployment platform whose primary users are AI agents rather than humans, exposing compute, databases, DNS, and custom domains through a CLI, an MCP server, and Claude/Cursor-compatible Skills so an agent can deploy a full-stack service with one call and get a live URL back in under a minute.

Take these together and the premise of this post stops being hypothetical: agents operating infrastructure over MCP is not a roadmap item, it is a deployed pattern with multiple independent implementations. Which makes the two problems urgent rather than theoretical. The bridge proves agents will find and use infra tools. The question is what the tools owe them in return: discoverability without manual config-pasting, and authority narrow enough that a compromised or confused agent cannot take production down with it.

Finding the tool is problem one. Trusting it with production is problem two.​

Discovery has a standards-track answer converging. MCP Server Cards (SEP-1649, a 2026 roadmap priority owned by the Server Card working group) propose a structured metadata document served from a .well-known endpoint so clients, crawlers, and registries can learn a server's capabilities, transports, and — critically — auth requirements before establishing a live connection. Early implementations vary on the exact path, but the direction is settled: advertise what you are and what you demand up front, machine-readably, instead of requiring a human to read your README and hand-write config. For a deploy-app server, that means the card is where you declare the production verbs and their authorization model, not just the tool names.

Trust is the harder half, and discovery alone does not close it. "The agent found my deploy tool" must never imply "the agent may deploy to production." The patterns that production MCP deployments have converged on are consistent across vendors: OAuth 2.1 bearer credentials instead of long-lived static tokens; scoped, short-lived tokens tied to a workflow, project, or tenant; per-user permissions inherited from the human who authorized the agent, so the agent can only touch what its user could touch; a read/write split that keeps logs, status, and list widely available while deploy, rollback, and destroy sit behind narrower scopes and, ideally, human approval; and a full audit log of every tool call for governance and attribution. Microsoft's Entra-scoped agent permissions, Scalekit's scoped-OAuth MCP stack, and Stack Overflow's role-based MCP permissions all rhyme on this shape. The deploy server that skips it is one prompt-injection away from an incident.

Note the asymmetry: discovery failures are silent (your tool never gets called) while authority failures are loud (the wrong call succeeds). Teams naturally over-invest in the loud one after an incident and under-invest in the silent one forever. The checklist below treats them as equals.

What a self-hosted PaaS deploy MCP server must ship​

Pulling the thread together, here is the concrete ship-list for a self-hosted platform exposing deploy, rollback, and logs over MCP — the expanded version of the verdict this post opened with:

1. A Server Card and a registry listing. Serve structured metadata from the .well-known discovery endpoint and list the server in the official registry. If an agent cannot discover the tool without a human pasting JSON into a config file, the tool does not exist for autonomous workflows.
2. Scoped, short-lived OAuth — no static tokens. Per-user authorization with tokens bound to a project or tenant and a short lifetime, injected server-side at call time. The agent holds a lease, not a master key.
3. Least-privilege tools the agent cannot self-escalate. One scope per verb family; a token minted for logs:read must be structurally incapable of becoming deploy:write. Scope upgrades require re-authorization by the human, never by the agent asking nicely.
4. A read/write split with progressive disclosure. Diagnostics and status tools are cheap to expose; production-mutating verbs stay undiscovered until the workflow needs them, and the most destructive ones gate on explicit human approval. Discovery ranking should treat dangerous tools as expensive to surface.
5. An audit log of every call. Who authorized which agent to call what, with which scopes, and what happened. This is the artifact that turns "the agent did it" from an excuse into a debuggable, attributable event.

None of these is exotic. Each is already standard practice somewhere in the ecosystem surveyed above. The gap is that no single self-hosted deploy server ships all five today — the bridges prove the demand, Arcade proves the brokered shape, and the Server Card spec proves the discovery half is standardizing. The platform that assembles the full set first owns the most defensible position in agent-operated infrastructure: the tool agents can both find and be trusted with.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with AI agents as first-class operators. Star the repo on GitHub or deploy your first app today.