Dora NodaThe Model Context Protocol won the agent-integration war faster than almost any infrastructure standard in recent memory: from an Anthropic open-source release in November 2024 to more than 10,000 active public servers and 97 million monthly SDK downloads by the time Anthropic donated the protocol to the Agentic AI Foundation in December 2025. OpenAI, Google, and Microsoft all standardized on it. Seventy-eight percent of enterprises now run at least one MCP agent in production.
And yet the thing agents are worst at in 2026 is not speaking the protocol — it is finding the right tool to speak to. Roughly 73% of MCP servers are effectively invisible to agents browsing a directory. The average trust score across thousands of analyzed servers sits at 53.9 out of 100. Around a thousand servers sit on the public internet with no authorization at all. One team watched 62 MCP tools inject roughly 10,000 tokens into every single turn and cripple their production agent.
The M×N integration problem MCP was created to solve has been replaced by a discovery problem: n agents times m servers equals n×m configuration decisions, all still made by a human hard-coding server addresses.
That is the gap Red Hat is now building the enterprise answer to. Its January 2026 "Building effective AI agents with MCP" post bakes the protocol into OpenShift AI as governed platform infrastructure — test in the Playground, publish to a verified catalog, deploy through an operator, govern through a gateway — and its roadmap adds the missing piece the raw protocol never defined: an agent registry where callers find tools by capability instead of by address. This post quantifies the discovery bottleneck, dissects Red Hat's stack piece by piece, and turns both into a concrete checklist for what a self-hosted PaaS must build into its own MCP server so agents can discover it without a human pre-wiring the connection — and trust it once they do.
The discovery bottleneck, quantified
The protocol solved "how does an agent call a tool." Nothing in the protocol answers "how does an agent learn the tool exists." The ecosystem census numbers, taken together, show where the pain concentrates:
| Signal | Number | Source |
|---|---|---|
| Active public MCP servers | 10,000+ | MCP project ecosystem update, Dec 2025 |
| Monthly SDK downloads | 97M+ (970x in 18 months) | Mar 2026 census |
| Servers registered (cross-registry) | 17,468 | May 2026 census |
| Servers invisible to browsing agents | ~73% | ToolRank scan of 4,000+ servers |
| Average trust score | 53.9 / 100 | Analysis of 4,584 servers (Jun 2026: index at 22,561, only 0.08% independently verifiable at runtime) |
| Servers exposed publicly with no auth | ~1,000 | Dec 2025 security survey |
| Enterprises with MCP in production | 78% with ≥1 agent; 41% in limited/broad production | WorkOS / Stacklok 2026 reports |
Three failure modes hide inside that table. The first is sheer findability: nearly three-quarters of servers lack the tool descriptions and metadata an agent needs to select them, so they may as well not exist. The second is trust: a 53.9 average trust score with a near-zero runtime-verifiable fraction means discovery without vetting is a supply-chain gamble — the agent found a tool, not a safe tool. The third is the token tax: every discovered tool's schema rides along in context, so naive "connect everything" discovery degrades the agent it was supposed to empower. Sixty-two tools at ~10k tokens a turn is not an edge case; it is what ungoverned discovery looks like at modest scale.
Note the shape of the problem: none of these yield to a better protocol revision alone. They yield to curation (a catalog that vets before listing), to a runtime that loads tools lazily instead of stuffing every schema into context, and to identity and audit that make a discovered tool safe to call. Which is exactly the stack Red Hat is assembling.
Red Hat's answer: MCP as governed platform infrastructure
Red Hat's January 8, 2026 "Building effective AI agents with MCP" post frames the company's bet plainly: MCP servers should be treated as first-class infrastructure on OpenShift, with the same lifecycle discipline as any other workload. The stack has five layers, each answering one row of the bottleneck table:
1. Playground validation: prove it works before it ships. The generative-AI Playground inside the OpenShift AI dashboard lets teams prototype and evaluate MCP servers against foundation models before wiring them into an application — then exports a Python template as the starting point for real integration. This is the vetting gate: a server earns its catalog listing by demonstrating behavior, not by submitting a description. For the trust-score row of the table, this is the enterprise fix — nothing unverified gets discovered because nothing unverified gets listed.
2. The MCP catalog: discovery by browsing, not by address. Red Hat OpenShift AI 3.4 (developer preview, May 2026) ships a verified-MCP-server catalog in the AI hub: a centralized, governed space to deploy checked servers. The companion MCP Registry (3.5 developer preview) draws a sharp line the raw ecosystem never drew — the catalog is the discovery surface, the registry governs what is actually in use (identity, version, lifecycle state, ownership, deployment metadata). Finding and running are separate concerns with separate controls.
3. The lifecycle operator: declarative deploy for the servers themselves. The MCP lifecycle operator (developer preview v0.1.0, upstream at kubernetes-sigs) provides an MCPServer custom resource, so deploying a tool server is oc apply like anything else — with rollout semantics, health probes, and restricted-SCC security contexts. Supported day-one servers include OpenShift, Ansible AAP, Red Hat Insights, and Satellite integrations. The point is not convenience; it is provenance. A discovered tool traces to a declared manifest, a scanned UBI-based image, and a versioned rollout — the supply-chain answer to the 53.9 trust score.
4. The gateway: auth and rate limiting at the choke point. The MCP gateway for OpenShift (technology preview) sits between agents and servers decoding traffic, enforcing authentication, and rate-limiting calls — the enterprise AgentOps layer. Roughly a thousand public servers run with no authorization; the gateway makes "no auth" structurally impossible for anything behind it, while giving platform teams the traffic visibility the protocol itself never mandated.
5. The planned agent registry: capability search for non-human callers. Red Hat's multi-agent-networks roadmap adds a service catalog for AI agents: a team needing a billing specialist searches by capability, reviews its AgentCard, and delegates instead of building from scratch. This is the furthest-reaching piece — discovery addressed to agents directly, with delegation semantics — and the one most relevant to a deploy-from-chat platform, as the next section argues.
The through-line: Red Hat treats every bottleneck row as a platform concern (validate, curate, declare, govern, delegate) rather than a protocol concern. The protocol stays thin; the platform gets thick.
Discovery without scoped authority is still an untrusted agent
There is a trap in solving discovery alone. An agent that can find any tool but carries one broadly-scoped token is not empowered — it is a confused deputy with a phone book. The two axes are independent, and only one quadrant is safe:
| Broad / standing authority | Scoped / per-task authority | |
|---|---|---|
| Manual wiring (no discovery) | Today's default: human pastes addresses, agent inherits the human's token. Works until the token leaks or the agent overreaches. | Better but brittle: least privilege per integration, yet every new tool needs human reconfiguration. The n×m tax. |
| Open discovery | The dangerous quadrant: the agent finds everything and can touch everything. A prompt-injected tool description away from incident. | The target: the agent finds tools by capability, and each call carries only the authority its task needs, with an audit trail. |
Two 2026 developments move the ecosystem toward that target quadrant from opposite ends. From the integration layer, Arcade's MCP runtime (a 7,000-plus tool catalog served through one gateway endpoint) attacks the token-sprawl half: user-bound OAuth, downstream token vaulting, structured execution logs, and managed execution mean the agent sees one connection while the runtime fans out to thousands of tools — discovery without stuffing thousands of schemas into context, authority without handing the agent raw credentials. From the protocol layer, the July 28, 2026 MCP revision — the largest since launch — makes the core stateless (no session handshake, requests routable behind a plain load balancer) and replaces server-initiated elicitation with multi-round-trip requests: a server returns "input required," the client collects the answer and re-issues the call. That is the primitive a deploy tool needs to ask a human to confirm the concrete cost, target, or consequence before acting — approval bound to the exact plan, not a standing token that implies standing permission.
Red Hat's catalog/governance model maps onto this quadrant directly: Playground validation is the vetting that makes discovery safe, published server cards are the capability metadata that makes discovery work, and the gateway plus per-agent identity is the scoped authority that makes discovery safe to act on. Any platform exposing deploy tools to agents needs all three — which is the checklist.
What a self-hosted PaaS must steal from this playbook
A self-hosted platform's own MCP server — the one that lets an agent deploy, roll back, read logs, and inspect state — faces the same bottleneck at smaller scale: it must be discoverable without a human pre-wiring the connection, and trustworthy once discovered. Six items, in dependency order:
- Be discoverable without pre-wired config. Ship machine-readable server cards (capabilities, tool descriptions, auth requirements) through a registry or well-known endpoint, not a README the human pastes into chat. If onboarding your deploy tools requires editing a client config file by hand, you have re-created the n×m tax for every agent × every project.
- Validate before listing, Playground-style. Run candidate tools against scripted scenarios on a live project — behavioral evals, not unit tests — and only publish tools that pass. An agent debugging production against an unverified tool is debugging with a liar in the loop.
- Give every agent its own identity. Per-agent service accounts with RBAC scoped to the task (this app, this environment, these verbs), never a shared platform token. Red Hat's gateway model applies at any scale: authenticate at the choke point, authorize per call.
- Bind approvals to the exact plan. Use multi-round-trip elicitation for mutating calls: the agent prepares a diff and rollout plan, a human approves that plan, execution happens once with an auditable expiry. A broadly scoped agent token must never count as standing permission to touch production.
- Load tools lazily to kill the token tax. Serve the catalog through a gateway that exposes a search-and-select surface (or per-workflow tool loadouts) instead of injecting every schema every turn. The 62-tools-crippled-our-agent incident is the budget every platform team should design against.
- Audit everything, structured. Log who (which agent identity) called what (which tool, which version) with which authority grant and what result — queryable by the next agent session, not just by a human in a dashboard. Chat history is not the source of truth; the execution log is.
Items 1–2 make the platform's tools findable; items 3–6 make them safe to find. Most self-hosted MCP servers today ship neither half — a stdio binary and a prayer.
The protocol was the easy part
MCP's eighteen-month run from release to 97 million monthly downloads proves the industry can standardize fast when the abstraction is right. But standards move bottlenecks; they rarely remove them. The bottleneck moved from "how do we connect" to "how do we find, vet, scope, and audit" — and that question is answered by platforms, not protocols. Red Hat's OpenShift AI stack is the most complete enterprise draft of that answer so far: validate in the Playground, publish to a catalog, deploy through an operator, govern through a gateway, delegate through a registry.
For self-hosted platforms the lesson is sharper, because there is no vendor to outsource governance to. The team that owns the machines owns the discovery surface, the authority model, and the audit trail. Build the six-item checklist above into the platform's MCP server now, while the tool count is small — retrofitting scoped authority and lazy loading onto a catalog agents already depend on is the kind of migration nobody schedules voluntarily.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Agents are first-class operators: a Render-compatible API plus machine-readable infrastructure state they can deploy against today. Star the repo on GitHub or deploy your first app today.
