For the last year, much of the agent infrastructure conversation has focused on a straightforward question: does a business have an MCP server?
Uber's experience is a useful reminder that this question becomes less interesting as an agent ecosystem matures.
On October 1, Uber published the architecture behind its internal MCP Gateway. The platform centralizes agent access to existing back-end services and native MCP servers, translating protocols, enforcing security controls, and giving teams a shared registry for agent-facing capabilities.
The scale is notable: Uber says the gateway now hosts more than 800 MCP servers and more than 5,000 tools. But the most interesting part of the post is not the number of servers. It is what broke once there were enough of them.
MCP solved the interface problem. It did not solve distribution.
Uber describes three challenges that emerge when MCP grows beyond small deployments: discovery, token cost, and installation.
The discovery problem is especially important. MCP allows a client to ask a server which tools it exposes. It does not provide a native way to search across hundreds of servers. An agent therefore needs some way to determine which server is relevant before it can discover the tools inside that server.
A capability can be perfectly MCP-compatible and still be effectively invisible to the agent that needs it.
Uber addressed this with an incremental discovery layer. Its Omni MCP interface lets agents search for a relevant server, discover tools within that server, retrieve a tool schema, and only then invoke the tool. In other words, the system separates having tools from finding the right tools.
MCP compatibility answers whether an agent can communicate with an interface. Distribution answers whether the right agent can find, select, access, and successfully use the right capability at the right time.
The capability existed before the MCP server.
There is another detail in Uber's architecture that matters. Uber did not ask every internal team to rebuild its APIs as hand-authored MCP servers. Its AutoCrawler continuously discovers existing APIs from internal service definitions, generates agent-oriented tool descriptions and schemas, and registers them in the MCP Registry.
That suggests a useful architectural principle: the business capability is the durable asset. MCP is one interface through which that capability can be exposed.
This matters outside Uber too. A company may already have everything an agent needs to search inventory, create a support ticket, schedule an appointment, update a customer record, or execute a purchase. The missing piece may not be the underlying capability. It may be the interface, discovery path, access policy, or distribution layer around it.
Discovery does not imply exposure.
Uber makes another distinction that deserves attention: automatically discovering a capability does not automatically make that capability available to agents. Newly generated servers and tools begin disabled and require review and enablement by the owning team.
That is a governance decision, not a technical limitation. A business may want agents to know that a capability exists without granting every agent permission to invoke it. Different callers may need different authorization policies, scopes, rate limits, approvals, or data-redaction rules.
Uber's gateway applies authorization at server and tool level and distinguishes between human, service, and agent callers. This is a useful counterweight to the idea that agent readiness simply means making more things accessible.
The goal is not maximum agent accessibility. The goal is intentional agent access.
This is the problem Arachne is increasingly interested in.
Arachne began with a public-facing question: can AI systems discover and understand a business, and can agents continue from recommendation into action?
Uber's architecture shows the same problem appearing internally at enterprise scale. Organizations can own thousands of useful capabilities while agents still struggle to discover the correct interface, select the correct tool, obtain authorization, control context cost, and execute reliably.
That creates a broader measurement problem. An agent-facing capability should not be treated as a binary state.
It can exist without an interface. An interface can exist without being published. Published infrastructure can remain undiscoverable. A discoverable tool can be unauthorized. An authorized tool can fail during invocation. A successful invocation can still fail to complete the underlying business objective.
Arachne models these as separate states because collapsing them into a single "agent ready" label hides the exact gaps businesses eventually need to fix.
What happens next
The next generation of agent infrastructure will likely spend less time asking whether organizations have MCP servers and more time asking how capabilities move through the entire distribution chain.
Which capabilities exist? Which should be exposed to agents? Through which interfaces? Where are those interfaces published? Can agents discover them dynamically? Which agents are allowed to invoke them? Can the resulting action be independently verified? And can the organization observe and govern what happened afterward?
Uber encountered those questions after reaching hundreds of servers and thousands of tools. Most businesses will encounter them at a smaller scale.
The underlying lesson is the same: the hard part is no longer simply making something callable. It is making the right capability discoverable, usable, and governable.