The Gateway Thesis

1 Start with an audit

Open your MCP config and count two numbers: servers installed, and servers your agent actually used this past week.

When we ran this on our own team, the answer was 11 installed, 3 used weekly — and only 6 of the 11 still worked at all. The other five had drifted: an expired token here, a renamed model there, a server whose maintainer moved on. (Figure 4. Run the audit yourself before dismissing it; most engineers we've asked land within a couple of integers of the same shape.)

Every one of those 11 servers cost the same ritual: find it in a registry, evaluate it against four look-alikes, run it, create an account upstream, mint a credential, edit config, restart the client, debug the first auth failure. Call it fifteen minutes when everything goes right. The five dead servers cost that ritual again as silent maintenance debt — except nobody paid it, which is why they're dead.

This is not a discipline problem. It is the predictable equilibrium of a topology.

2 What MCP solved — and what it didn't

Before MCP, connecting N clients to M tools meant N×M bespoke integrations. MCP collapsed the protocol dimension: one wire format, one handshake, any client speaks to any server. That worked, and the result was an explosion of servers.

But protocols don't deploy themselves. At the deployment layer, each user still pairs with each server individually: one credential (a pasted key or one more OAuth grant), one config entry, one schema payload per pairing. The integration matrix MCP killed at the protocol layer reappeared at the operations layer — N users × M servers, with every cell paying setup, upkeep, and context costs.

The industry's answer to "my agent needs to do more things" has been "install more servers." The thesis of this paper is that this answer is architecturally wrong for the long tail of capabilities, and that the correct unit of connection is a routing gateway: the client makes exactly one MCP connection; the gateway makes all the others, once, centrally, professionally maintained.

3 The five taxes of the mesh

3.1 Context

Every connected server ships its tool schemas into the model's context before the conversation begins. Published servers commonly carry between ~3k and 50k+ tokens of schemas; GitHub's official server alone exposes 90+ tools by default. At a plausible midline of ~12k tokens per server, twenty connected capabilities cost ~240k tokens — more than a full 200k context window spent on JSON before the model reads the user's first word.

The deeper cost is attention, not tokens. Tool-selection reliability degrades as the tool count grows: every irrelevant schema is a distractor the model must rule out on every turn. The clearest evidence that this problem is real is that client vendors are now shipping mitigations — deferred tool loading, tool search, schema lazy-loading. Those mitigations shave the token bill (we return to them in §7); they do not touch the other four taxes.

3.2 Discovery

Which of the five community Postgres servers is good? Which scraper survives the site's next anti-bot update? Which image model is best this month for photoreal product shots — and which is cheapest at acceptable quality? In the mesh, this evaluation runs at config time, per user, against stale information, and its output is frozen into a config file. The ecosystem's velocity — the very thing that makes agents more capable every month — is what makes config-time decisions rot.

3.3 Credentials

One credential per service per user. Keys pasted into JSON files that get committed, synced, and leaked; OAuth grants that multiply per server; token refresh flows that each server implements slightly differently. The blast radius of "my laptop was compromised" is every upstream account you ever wired in.

3.4 Upkeep

Servers version, break, get abandoned, get replaced. In the mesh, every upstream change fans out to every user as an individual maintenance task — which, as our audit shows, mostly doesn't get done. The mesh's real steady state is not "N working integrations"; it is "3 working, 3 zombied, 5 dead, all still taxing context."

3.5 Payments

The mesh has no payment story at all. Every paid capability means another vendor account, another card on file, another subscription sized for peak usage, another free-tier ceiling hit mid-task. This is the tax that quietly caps what agents are allowed to do: the set of things your agent can pay for is the set of things you pre-subscribed to.

4 A cost model

Let N = capabilities a user's agent can reach, s̄ = mean schema tokens per dedicated server, k = setup steps per server, U = upstream changes per server per year.

Cost	Mesh (N dedicated servers)	Gateway
Context per conversation	~N·s̄ (linear)	c (constant, ~8k)
Setup actions	N·k, paid by each user	k, paid once
Credentials held client-side	N	1
Annual maintenance events per user	O(N·U)	0 (absorbed server-side)
Payment relationships	one per paid vendor	1 ledger
Marginal cost of the N+1th capability	k steps + s̄ tokens forever	0

The last row is the compounding one. In the mesh, capability growth has a per-user marginal cost, so users rationally stop adding capabilities — the 11/3 equilibrium. Behind a gateway, the N+1th capability appears in the catalog with zero client-side cost, so the useful surface of the agent grows without the user doing anything. The two topologies don't just differ in overhead; they differ in which direction the system drifts over time.

5 The gateway architecture

Vaaya implements the gateway as one remote MCP server (vaaya.ai/mcp, OAuth 2.1, or npx -y @vaaya/mcp install for local clients) exposing a fixed surface of 27 tools (~8k tokens) regardless of how many upstream services exist behind it. The capability interface is two verbs:

consult — the agent describes a goal in plain English ("make a 5:2 hero image with room for a headline," "find the CTO's verified email," "scrape these 40 product pages"). The gateway's router — which holds the live catalog with prices, quality notes, parameter schemas, and current availability — returns either a clarifying question, or an ordered list of exact calls to run, each with a price ceiling and a one-line why. The routing knowledge lives server-side and is updated continuously; the client model never reads a catalog.

use — execute one returned call. The gateway validates parameters against the registered schema, injects credentials (the agent never sees a key), executes across the appropriate rail, and bills only on success. Long-running work returns a job handle; results are polled, not re-purchased.

Three properties fall out of this design:

Routing is a service, not a prayer. Model-side orchestration means discovery at config time and failure handling by blind retry. Gateway-side routing means the catalog is always current, price/quality comparisons run on live data, and a failing provider is rerouted — to another provider, or another settlement rail — rather than retried into the ground.

The context tax becomes a constant. 27 tools whether the catalog holds ten services or ten thousand. Schema payloads for individual upstream services never enter the client context at all.

Payments collapse into one ledger. Per-call billing with a hard per-call ceiling (max_cost_cents), spend caps, an auditable transaction log, and zero charges for failed calls. Under the hood, settlement runs on whichever rail the merchant speaks: x402 (USDC on Base, agent-native pay-per-call), Stripe's machine-payment path, or conventional API/card arrangements held by the gateway. The agent — and the user — see none of this plumbing; they see one balance and one audit trail.

The user's standing objection to agentic payments — "I am not giving an LLM my credit card" — is answered structurally: the agent can only spend through capped, logged, schema-validated calls, and a failed call is a free call.

6 Where the mesh still wins

A thesis that explains everything explains nothing, so here is the honest boundary of ours.

Deep, high-frequency, single-vendor workflows. If your agent lives inside GitHub all day — branch, review, merge, CI — the dedicated GitHub server's full tool surface, used constantly, earns its context cost. The gateway's economics favor the long tail; the short head of your top one or two daily tools can rationally stay point-to-point. The topologies compose: one gateway plus one or two head servers is a strictly better mesh than eleven.

Local and air-gapped resources. Filesystem access, local databases, anything that must not transit a third party. A remote gateway cannot and should not mediate these.

Hard-latency inner loops. A gateway hop is milliseconds and a consult is an LLM round-trip; a robotics control loop or a high-frequency trading signal shouldn't pay either. (Neither should it run through a general-purpose agent, frankly.)

Regulated data paths. When compliance requires a direct, contracted relationship with the upstream processor, the gateway's convenience is beside the point — though gateways can and should grow compliance-scoped deployment modes.

None of these break the thesis; they scope it. The claim is not "never run a dedicated server." It is: the default answer to a new capability should be routing, not installation — because the mesh's costs compound with N and the gateway's don't.

7 Related approaches

Client-side tool search / lazy schema loading. Real, useful, and shipping in major clients. It addresses the context tax only — discovery, credentials, upkeep, and payments are untouched. It also only helps in clients that implement it. We view lazy loading as complementary: a gateway benefits from it like any other server.

Registries (the official MCP registry, Smithery, marketplaces). Registries improve finding servers; they don't change who bears setup, upkeep, or context costs after the find. A registry is an index of the mesh; a gateway is a replacement for wiring it yourself.

Aggregator MCPs (Composio, Zapier, Pipedream and kin). These consolidate auth and hosting for many SaaS actions behind one connection — genuine progress on credentials and upkeep, and the closest relatives to the gateway model. The differences are the routing layer and the payment layer: aggregation without an intent router still hands the model a large tool surface to navigate, and none of them can pay for arbitrary metered capabilities on the agent's behalf. A gateway without routing is a bigger toolbox; a gateway with routing is a procurement engine.

Agent-payment rails (x402, L402, Stripe's machine payments). These are settlement primitives, not topologies — necessary but not sufficient. Vaaya consumes them as rails behind the ledger; the thesis is about where routing and trust live, and rails alone don't answer that.

8 Adoption dynamics: why architecture is the distribution

Developer infrastructure is a pull product. Nobody mandates what engineers wire into their terminals; adoption travels bottom-up through exactly one gate — does the skeptical senior engineer nod? The CEO asks the CTO, the CTO asks the person who tried it at midnight. Marketing does not pass that gate; arguments do.

This shapes the gateway market in a specific way: the winning gateway must be credible before it is convenient. Hence transparent per-call pricing with hard caps, billed-on-success semantics, an auditable ledger, standard MCP end-to-end (swapping gateways is one config line — the exact pressure that keeps a gateway honest), and publishing our reasoning where it can be attacked. This paper is that: the ask at the end is not a demo booking. It is a refutation.

9 Objections

"A gateway is a single point of failure." So is your model provider, and so is the mesh — eleven times over, maintained by no one. The gateway centralizes failure into a system with rerouting, monitoring, and someone on call.

"An extra hop of latency." The use hop is proxy overhead: milliseconds. consult is an LLM round-trip — real, and honestly disclosed — but it replaces the model re-reading tens of thousands of schema tokens on every turn, forever. One routing call amortizes; a bloated context never does. Repeat calls skip consult entirely.

"The gateway sees my traffic." The same trust shape as any proxy, cloud provider, or model API — with narrower scope (schema-validated calls, not raw browsing) and better instrumentation (per-call ledger, caps, revocable OAuth) than eleven scattered vendor dashboards.

"A middleman will rent-seek." The countervailing force is the one config line in §8. A gateway holds its position only while routing quality and pricing beat the cost of leaving — which is precisely the discipline a mesh never imposes on itself.

"Tool search will make this unnecessary." See §7: it addresses one tax of five, in some clients. The catalog problem — what's alive, good, and cheapest today — is not a context problem. It's a routing problem, and it has to live server-side to stay current.

10 Conclusion

MCP gave agents a universal port. The mesh then asked every user to be their own systems integrator, and users answered the only way an equilibrium allows: eleven installed, three used.

Agents don't scale by adding connections. They scale by one connection that routes — a constant-context, single-auth, per-call-billed gateway whose catalog grows while the client's surface doesn't. Two verbs against the whole internet.

The implementation is live. Wire it in one command — npx -y @vaaya/mcp install — or read the source and file the counterexample. We mean the last part: the thesis is falsifiable, and the issues tab is open.