MCP gateway · updated October 8, 2026

The MCP gateway for agents that write to real systems.

Obol is an MCP gateway: one MCP URL and one key for Claude Code, Cursor, Codex or your own agent. Tools a key cannot call never appear, destructive tools in production wait for approval unless your policy grants them, and every tool call gets a receipt.

Your vendor credentials stay in Obol’s vault and never reach the agent. The same key also reaches your models through an OpenAI-compatible LLM gateway, under the same policy.

/mcp: Streamable HTTP
tools/list: filtered per key
Free: no card

What is an MCP gateway?

An MCP gateway sits between AI agents and the MCP servers and APIs they call. Agents connect to one gateway URL instead of holding their own tool configs and vendor keys. The gateway authenticates each agent, decides per call which tools it may see and run, keeps the credentials, and records what happened.

An MCP server exposes tools. A gateway decides who may use them, with which arguments, and keeps the record. Obol is an MCP gateway with policy, approvals and receipts built in.

MCP server vs MCP gateway. One exposes tools; the other governs them.

How an MCP server and an MCP gateway divide the work
	MCP server	MCP gateway (Obol)
What it is	A program that exposes one system’s tools over the Model Context Protocol	One endpoint in front of many servers and APIs that every agent connects to
How many	One per vendor or system	One for the whole organization
What it decides	Which tools exist and how each one runs	Which agent may see and call which tool, with which arguments, in which environment
Vendor credentials	Usually in each agent’s config or environment	In Obol’s vault, decrypted only inside the gateway on the outbound hop
What it records	Whatever the server chooses to log	A receipt for every tool call, with the policy decision and an evidence class

How Obol’s MCP gateway handles a tool call. Six steps, in this order, every time.

The order matters: the agent never sees a tool it cannot call, and nothing reaches a vendor before policy and approval have run.

01
The agent authenticates once
Every client connects to https://gateway.tryobol.dev/mcp over Streamable HTTP with its Obol key as a bearer token. The key is Obol’s, not a vendor’s: you can scope it, cap it and revoke it.
02
It sees only what it may call
A visibility filter runs first, so tools/list shows only the tools that key may call. Tools from every connected server are namespaced as connector.tool.
03
Each call meets policy, default-deny
Cedar evaluates the call in-process before anything is dispatched, with argument conditions: amount, environment, whether the tool is destructive, which repository. No matching permit means no call.
04
Risky calls wait for a person
A destructive tool in production returns approval_required unless your policy explicitly grants it. One or two approvers decide in the inbox, and an approved call runs once, bound to its idempotency key.
05
The credential is added on the way out
Obol decrypts the vendor credential inside the gateway and injects it on the outbound request. The agent, the logs and the dashboard never see it.
06
The call gets a receipt
Every tool call gets an idempotency key and a receipt naming the policy decision, the upstream id, the vendor status and the evidence class.

Details: the MCP surface, approvals and the credential vault.

Policy on arguments, not just tool names.

Allowing or blocking a whole tool is too coarse for writes. The example on the right is a rule from Obol’s own Cedar policies: an agent may call the Stripe refund tool only when the refund amount is at or under the cap on that agent’s record.

At or under the cap: the permit matches and the call may proceed.
Over the cap: nothing permits it, so the default-deny refuses it before Stripe is ever contacted.
In production: a destructive tool such as a refund also waits for approval unless your policy explicitly grants it.

Read how Cedar policy works in Obol.

agent-passport.cedar

example

@id("passport-refund-cap")
permit(
  principal is Obol::Agent,
  action == Obol::Action::"call",
  resource == Obol::Tool::"stripe.create_refund"
) when {
  context has amount_usd && principal has max_refund_usd &&
  context.amount_usd.lessThanOrEqual(principal.max_refund_usd)
};

What the receipt can prove, by route.

Policy and approvals apply before the call on every route. What Obol can prove after the call depends on who made the vendor request, and the receipt always names its evidence class.

Evidence class by connector route
Route	Who makes the vendor request	Evidence class	Can it reach verified?
Native: a reviewed connector pack Obol custodies	Obol, with your vaulted credential, reading the response on its own connection	`gateway_observed`	Yes, through an admitted readback or the vendor’s own signed webhook
Federated: your own broker account (Nango or Composio) or a remote MCP server	Your broker or the remote server	`untrusted` or `broker_attested`	Not on its own; only the vendor’s signed webhook, checked at Obol’s edge, can raise it

See evidence classes and connector tiers, or browse the connector catalog.

Works with Claude Code, Cursor, VS Code and Codex. A config file, not an SDK.

Claude CodeTerminal setup, key in OBOL_API_KEY
Cursor.cursor/mcp.json
VS Code.vscode/mcp.json
Codex.codex/config.toml
MCP InspectorStreamable HTTP + Authorization header
Your own appAny MCP client; models through the OpenAI SDK

The dashboard writes the exact file for each client. See the two-line quickstart.

.cursor/mcp.json

the whole change

{
  "mcpServers": {
    "obol": {
      "url": "https://gateway.tryobol.dev/mcp",
      "headers": { "Authorization": "Bearer ${env:OBOL_API_KEY}" }
    }
  }
}

MCP gateway vs API gateway vs LLM gateway.

Three kinds of gateway govern three kinds of traffic. Obol covers two of them behind one key: tool calls on /mcp and model requests on an OpenAI-compatible /v1.

MCP gateway, API gateway and LLM gateway compared
	MCP gateway	API gateway	LLM gateway
Traffic	Agent tool calls over MCP	Requests to your own HTTP services	Requests from apps and agents to model providers
Decides	Which agent may call which tool, with which arguments	Routing, rate limits and auth in front of your APIs	Which model and provider a request reaches, and with which key
Typical risk it controls	An agent writing to production with the wrong tool or the wrong amount	Abuse of your public endpoints	Model spend and provider key sprawl
Obol	Yes, /mcp	No: Obol governs your agents’ calls, not public traffic to your services	Yes, OpenAI-compatible /v1 on the same key

Do you need an MCP gateway?

You probably do if any of these is true:

Your agents will write to production systems, such as refunds, tickets or deploys, not only read.
MCP configs and vendor keys are scattered across laptops, repositories and CI.
A security reviewer is asking who approved an agent’s action and what it actually did.
You need one spending limit across model requests and tool calls.

If your agents only read public data in a sandbox, you may not need one yet.

Run it on Obol Cloud or on your own host.

Obol plans
Plan	Price	What you get
Free	$0, no card	2,000 model requests and 2,000 tool calls a month, shared across your organization
Team	$99 a month per organization	One price for the whole team, with no automatic overage
Enterprise	Custom, annual	A signed agreement with our team
Free Self-hosted	$0 in Obol fees	The same gateway, policy, approvals and receipts on your own Docker Compose host; you operate it, with no SLA

Your model and tool providers bill you directly. Compare plans or install it on your own host.

How to choose an MCP gateway. Six questions worth asking any vendor.

Visibility: Does tools/list show each key only the tools it may call, or does it block only at call time?
Arguments: Can policy read arguments such as an amount or an environment, not just tool names?
Credentials: Where do vendor credentials live, and can an agent ever read them?
Approvals: Do destructive actions wait for a person, and does an approved call run exactly once?
Evidence: Does each receipt say what it can prove, route by route?
Deployment: Can you run it on your own host, and does the same key cover model traffic?

MCP gateway questions, answered plainly.

What is the difference between an MCP server and an MCP gateway?

An MCP server exposes one system’s tools to agents. An MCP gateway sits in front of many servers and APIs: agents connect to it once, and it decides per call which tools each agent may see and run, holds the vendor credentials, and records every call.

Do we need an MCP gateway if we only use a few MCP servers?

If agents only read, perhaps not yet. Once an agent can write to a production system, a gateway gives you one place to set rules, hold approvals, keep keys out of agent configs and see what happened, instead of repeating that work in every server and client.

Is an MCP gateway the same as a proxy?

A proxy forwards traffic. An MCP gateway also authenticates the agent, filters which tools it can list, evaluates policy on each call’s arguments, pauses risky calls for approval and writes a receipt. Obol does all of that before a request reaches a vendor.

Is an MCP gateway the same as an API gateway?

No. An API gateway sits in front of your own HTTP services. An MCP gateway sits between AI agents and the tools they call, including other companies’ APIs, and governs what each agent may do there.

How is an MCP gateway different from an LLM gateway?

An LLM gateway governs model requests; an MCP gateway governs tool calls. Obol is both behind one key: an OpenAI-compatible /v1 for your own OpenAI, Anthropic or OpenRouter connections, and /mcp for tools, under one policy and one audit log.

Does the agent ever see my vendor keys?

No. The agent holds an Obol key. Your vendor credentials are envelope-encrypted in the vault, decrypted only inside the gateway process, and added to the outbound request, never to logs or the dashboard.

How do clients authenticate to Obol’s MCP gateway?

With an Obol key sent as a bearer token in the Authorization header. Each key can be scoped to models and tools and carries its own allowlists, monthly budget, expiry and revocation.

Does Obol decide which tool the model uses?

No. Obol does not choose tools for the model. It makes sure a tool your policy does not allow cannot run, and that a tool the key may not call never appears in its list.

Can I self-host it?

Yes. Free Self-hosted runs the same gateway, policy engine, approvals and receipts on your own Docker Compose host for $0 in Obol fees. You operate it and bring your own credentials, and there is no SLA.

Put your AI to work. Keep the keys.

Free to start. No card needed.