architecture guide

MCP gateway: how to govern every tool your AI can call

How an MCP gateway works: a reverse proxy in front of your MCP servers and APIs that enforces tool allow lists, rate limits, spend caps and a full audit log.

What an MCP gateway is

An MCP gateway sits between an AI client (agent, IDE, chat app) and the MCP servers or REST APIs it calls. Instead of pointing the client at each upstream directly, you point it at one gateway URL. The gateway speaks the Model Context Protocol on the front, forwards the call to the real upstream on the back, and applies policy in between. It is the same pattern as an API gateway — authentication, authorization, quotas, observability — adapted to tool calls rather than routes.

AI client ──▶ MCP gateway ──▶ MCP server / REST API
                 │
                 ├─ authenticate the caller (scoped key or x402 payment)
                 ├─ resolve the tool name from tools/call
                 ├─ evaluate allow / deny rules
                 ├─ check rate limit, daily quota, spend cap
                 └─ log decision, latency, status, cost

Why direct MCP connections are risky

A single MCP server usually exposes every tool it has. An agent that only needs list_issues also gets delete_repo.
Upstream credentials end up copied into every client that connects.
There is no shared record of which agent called what, when, or at what cost.
A prompt-injected agent can loop on an expensive tool with nothing to stop it.

The four control layers

1. Identity. Every caller presents a scoped gateway key (or a per-call x402 payment). Upstream secrets never leave the gateway, so revoking a key instantly cuts off one client without rotating anything upstream.

2. Tool allow lists. Rules match tool names with wildcards and are evaluated against a default action. Default-deny plus allow: read_* exposes a safe read-only surface; default-allow plus deny: delete_* blocks the destructive tail. Blocked calls never reach the upstream — the gateway answers with a policy error.

3. Rate limits and spend caps. Per-minute rate limits stop runaway loops, daily quotas bound total volume, and a daily USD spend cap stops billing surprises on metered upstreams. Limits belong on the key, so each consumer gets its own budget.

4. Audit log. Every request is recorded with the tool name, the decision, latency, HTTP status and estimated cost. That log is what makes agent behaviour reviewable after the fact.

Turning a REST API into MCP tools

Most upstreams are not MCP servers yet — they are ordinary REST APIs with an OpenAPI document. A gateway can read that spec and derive one MCP tool per operation: the operation ID becomes the tool name, the summary becomes the description, and path, query and body parameters become the JSON Schema input. Method semantics map to tool hints, so a GET is advertised as read-only and a DELETE as destructive. The generated tools are served over Streamable HTTP for MCP clients and as a WebMCP snippet for browser-based clients — and both paths run through the same policy engine.

How Bouncer implements this

Bouncer is an MCP gateway built on exactly this architecture. You register an agent or paste an OpenAPI URL, and get back a single proxy endpoint. Allow and deny rules, per-key rate limits, daily quotas and spend caps are configured per agent, x402 payments can be enabled for keyless paid access, and every proxied call shows up in a live log.

Create your gateway URL