What is an MCP gateway?

An MCP gateway sits between an AI agent and the many MCP tool servers it might call: instead of connecting directly to dozens of unverified, unmetered servers, the agent connects once to the gateway, which resolves the tool view, checks balance and spend caps, verifies each server’s trust tier, and meters every call.

How it works

The agent opens a single MCP connection to the gateway and sees a unified tool catalog. When it invokes a tool, the gateway does the work in the middle: it resolves which upstream server serves that tool, checks that the organization has balance and stays under its spend caps, confirms the server’s trust tier, forwards the call to the real server, and returns the result while metering usage. That single entry point turns a constellation of disparate servers into one coherent surface, with one credential and one spend policy.

Gateway vs connecting directly

Connecting directly to each MCP server means trusting each one blindly, keeping separate credentials, and having no unified billing or caps. A gateway centralizes four things that are hard on their own: trust (it verifies each server before exposing it), billing (one account pays per call), spend control (caps an individual server cannot enforce), and network security — for example, SSRF blocking so a tool cannot force the backend to hit internal addresses. In short: the agent delegates to the gateway the boring and dangerous part of talking to many upstreams. How Obolo blocks SSRF and detects drift.

MCP gateway vs MCP client vs MCP server

MCP has two base roles: the MCP client (the agent, which invokes tools) and the MCP server (which exposes them). A gateway is a proxy that lives in the middle and plays both roles at once: it is an MCP server to the agent — it presents the tools — and an MCP client to the upstreams — it calls the real servers on the agent’s behalf. It does not replace the client or the server; it intermediates them, adding trust, billing, and control without either end having to change how it speaks MCP.

What Obolo adds

Obolo is an MCP gateway and marketplace, and acts as merchant of record for the agent economy. On top of the base gateway function it adds: a marketplace to discover and compare servers; the merchant-of-record role, so your agent pays per call from a prepaid balance and Obolo settles with the providers; two verification tiers (crawled/verified) to distinguish what was merely indexed from what was validated; and manifest-hash drift detection, which alerts if a server’s tools change from what was verified. You pay over any of three rails: Stripe, prepaid USDC balance, or x402. Learn about the x402 rail.

Frequently asked questions

Is an MCP gateway the same as an MCP client?

No. The MCP client is the agent that invokes tools. The gateway is a proxy that sits in the middle: it acts as an MCP server to the agent and as an MCP client to the upstream servers. It plays both roles at once, but it does not replace the agent’s own client.

Why not connect directly to an MCP server?

You can, but each direct server means trusting it blindly, managing its credential, and having no unified billing or caps. The gateway centralizes trust, metering, spend control, and network protection (such as SSRF blocking) in a single entry point.

Does a gateway add latency?

Yes, it adds a network hop compared to a direct connection. In exchange, it centralizes trust verification, billing, and spend caps; the cost is one extra hop and the gain is that the agent does not have to solve that complexity itself.