What Uber's MCP Gateway Confirms About the TCVelik Architecture

Uber just published the design of their MCP Gateway: a single service that fronts 800+ MCP servers and 5000+ tools, auto-generates MCP tools from existing IDLs, keeps everything disabled-by-default under owner approval, and layers in authorization, redaction, and observability. If you squint, it is a bigger, more polished version of what we have been building at Eveliko for the last 18 months, with TCVelik as the control plane and Power Automate as our equivalent of Muttley.

This is less a coincidence than a convergence. Once you try to run AI agents against a real company's systems, a small number of problems force a small number of shapes. Uber hit them at hyperscale. We hit them at SMB and enterprise-consulting scale. The answers rhyme.

1. Existing APIs are the fastest way to give an agent tools

Uber's core insight: do not rewrite services for an agentic world. Translate HTTP, gRPC, and TChannel calls into MCP transparently, through the service mesh, with zero changes downstream. AutoCrawler scans the IDL registry, derives MCP server shells, uses an LLM to enrich schemas into agent-friendly descriptions, and parks them disabled-by-default until the owning team enables them.

Our equivalent is the Power Automate flow family inside every TCVelik instance. Each exposed flow is a business process that already existed, now surfaced as an MCP tool. Our Flow Discovery routine is literally our AutoCrawler: it walks the client's Power Automate solution, finds flows tagged for MCP, and surfaces them. We did not rewrite Power Automate. We wrapped it.

The difference is one of scale and sophistication, not kind. Uber crawls Thrift and Protobuf IDLs. We crawl Power Automate solutions and Umbraco/Sitefinity content models. The pattern is identical: discovery, auto-generation, owner approval, enablement.

2. Tenant-scoped virtual servers behind one gateway

Uber materialises virtual MCP servers per internal service, each at /<service-name>/mcp. We materialise a virtual MCP server per client tenant. Our own Eveliko TCVelik instance (we call it Themis) sits alongside instances for an accounting firm, a consulting group, a legacy-equipment manufacturer, a civic-content platform, a Sitefinity knowledge base, and a marketing-content operation. Every one of them exposes a nearly identical surface - CRM, SOP management, forms, signals - because they are all the same TCVelik tool catalog, scoped and parameterized per tenant.

This is exactly the "scoping existing tools by adding predefined non-changeable params" pattern. A consultant on one tenant calling an intent search is calling the same backend as a user on another tenant, but the tenant, the data boundary, and the available intent taxonomy are pre-bound by the gateway, not by the client. The AI agent cannot escape its tenant by crafting a different request. The gateway owns the scope.

Uber's charter policies at the server level with optional tool-level overrides are the mature version of what we do today with per-tenant MCP endpoints and TCVelik's RBAC.

3. Signals as the universal input, SOPs as the universal response

Where Uber stops at "tool call", we go one step further. In TCVelik, every event, inbound or outbound, is a signal: a webhook from a build pipeline, a form submission, a Power Automate run, a tool invocation log, a deployment notice from a client system. Signals route through filters to processes (correlated by pkey), which spawn or extend SOPs, which are completed by humans or by AI.

This is the piece Uber's blog does not address and probably does not need to at their scale: the human-in-the-loop governance layer sitting on top of the gateway. Their Access Control System approves whether a call can happen. Our SOP layer approves whether the business process the call is part of should proceed, and keeps proof of execution.

Our architectural statement for this is simple: tools can be subclassed, versioned, and require central confirmation regardless of AI client, so an employee's "always allow" inside their personal AI tool does not bypass company tool governance. Uber's gateway stops a tool call. TCVelik stops a business decision. The gateway is necessary; the SOP wall is what makes it trustworthy.

4. The three problems Uber hit at scale, and where we stand

Uber calls out three scaling problems and their solutions. Worth mapping ours honestly.

Runtime discovery (Omni MCP). They built a single proxy with discover_server, discover_tools, get_tool_schema, invoke_tool, so an agent does not need all 5000 tools preloaded. We have intent search and intent lookup as the seed of this, plus the host client's own tool-search layer. We do not yet have a cross-tenant Omni MCP, and we probably should not want one; cross-tenant discovery is a leak, not a feature. But a per-tenant Omni with incremental discovery is on the critical path once a single TCVelik instance holds more than ~30 tools.

Response projection (GraphQL-like trimming). We do not do this at all. Our Power Automate flows return whatever shape the flow returns, and the agent pays for every field. For our larger enterprise tenants this will bite within the year. It is a one-week feature we should steal.

Code Mode (CLI-level tool invocation). Uber routes coding agents through a CLI (aifx mcp call) so output goes to files, not model context. We do not have an aifx equivalent yet. For Claude Code adoption inside Eveliko, this becomes relevant the moment our developers start piping TCVelik queries through terminal sessions. Low-cost to build; high-leverage for internal use.

5. The future architecture of MCP, from where we sit

Pulling the two architectures together, the shape of a mature MCP platform looks like this:

1. A gateway, not a server. Single ingress for AI agents, fanning out to many virtual servers. We have this. Uber has this.
2. Discovery over authoring. Tools are auto-generated from existing APIs, flows, or content models, with owner approval before exposure. We have this for Power Automate. Uber has it for IDLs.
3. Tenant-scoped virtual servers with pre-bound parameters. The gateway, not the client, owns scope. We have this. Uber has it per service rather than per tenant.
4. Observability and redaction at the gateway. PII stripped before it ever reaches the model. We have tool call logs; redaction is partial. Uber has out-of-the-box response redaction.
5. Human-in-the-loop governance above the tool layer. This is where TCVelik's SOP engine, signals, and process correlation sit, and where generic MCP gateways stop. We think this is the layer that will decide which agent platforms survive contact with regulated industries.
6. Incremental discovery and response projection to keep context cheap. Uber's lesson, not yet ours.
7. A CLI/Code-Mode path for coding agents. Uber's lesson, not yet ours.

Items 1-5 are our thesis. Items 6-7 are our next three features.

6. Why this matters commercially

The Uber blog is a validation document for every conversation we are about to have with large-enterprise and vCISO prospects. "Here is how one of the most sophisticated engineering organizations in the world solved the problem you are about to have. We built the same thing, shaped for your scale, with the governance layer they did not need and you cannot do without."

For a university-scale client where we already have TCVelik tools in place, the pitch stops being "trust us, this will work" and starts being "the pattern is proven; we are just the ones who built it with your governance requirements baked in from day one."

The pitch gets shorter. The architecture diagram gets simpler. The buyer stops asking whether MCP is real and starts asking who they should build their gateway with.