What is an MCP gateway, and why do agents need one?

An MCP gateway is one remote MCP server that fronts many tools and app accounts behind one sign-in. What that changes for config, credentials, spend and audit.

Illustration: A small friendly robot with a round camera-eye head walks through one open doorway in a long wall.

An MCP gateway is one remote MCP server that fronts many tools and app accounts behind a single sign-in. An agent connects to one URL, authenticates once, and receives the tools its caller is allowed to use. The gateway keeps the credentials, applies the organization's spend caps, and records every call in an audit trail.

Nine entries, or one URL per client
Three clients and three apps, before and after a gateway.
Without a gateway: 3 × 3 = 9 entries
Claude Code
notion server, its own token
slack server, its own token
github server, its own token
Codex
notion server, its own token
slack server, its own token
github server, its own token
Cursor
notion server, its own token
slack server, its own token
github server, its own token
With a gateway: 3 + 3
Claude Code
one entry
Codex
one entry
Cursor
one entry
api.corespeed.io/mcp
one URL, one sign-in
Holds the tokensCaps spendRecords every call
Notion
connected once
Slack
connected once
GitHub
connected once
Each client registers one server. Each app is connected once, by whoever owns the account.

What problem does an MCP gateway solve?

Without a gateway, every agent client needs its own entry for every app. Claude Code gets a Notion server, a Slack server and a GitHub server. Codex gets the same three again. Cursor gets them a third time. Each entry carries its own token, its own refresh logic and its own failure mode. Five people on three clients with ten apps is 150 entries to keep correct, before anyone leaves or rotates a key.

This is the N times M problem: N clients multiplied by M apps. A gateway collapses it to N plus M. Each client registers one server. Each app is connected once, in the gateway, by whoever owns the account. The agent then sees every connected app through one URL.

CoreSpeed's gateway is https://api.corespeed.io/mcp. It speaks Streamable HTTP, and any client with an mcpServers map registers it with one entry:

{ "mcpServers": { "corespeed": { "type": "http", "url": "https://api.corespeed.io/mcp" } } }

Claude Code takes the same server with claude mcp add corespeed https://api.corespeed.io/mcp --transport http --scope user. User scope matters: the entry applies to every project, so you add it once per client. The MCP server docs give the equivalent step for Codex, Cursor, Copilot in VS Code, OpenClaw, Hermes, claude.ai and ChatGPT.

How does a gateway decide which tools to list?

A gateway's tools/list is caller-specific. It returns exactly what this sign-in can call: the tools of the apps connected for this caller, the built-in capabilities this caller has enabled, and the manage__* account tools. Two members of the same organization can get different lists from the same URL, and that is the intended behavior.

Names follow the pattern <capability>__<operation>: notion__create_page, slack__post_message, memory__search_memory, web__search. Your organization's own MCP servers appear as org__<slug>__<tool>.

Read the list with three caveats. Absence is a decision: the capability is off, or the app is not connected. Presence is not health: an account in needs_reauth still lists its tools, and calls fail until a member reauthorizes it in Dashboard → Connectors. Presence is not permission: session-gated manage__* tools are listed for an API key but answer jwt_session_required. Never hard-code an inventory in application code. Run tools/list after authentication and use the names and input schemas it returns.

Where do the credentials live?

In the gateway. When a member connects Notion through CoreSpeed, the OAuth token goes into the platform's custody, is refreshed when the provider allows, and is exposed as namespaced tools. The agent calls notion__create_page; the platform performs the action with the right account. The agent never receives the token.

That changes what a leak costs. A prompt that talks the agent into printing its secrets finds no app token to print. Rotation happens in one place. A connection that goes stale shows as needs_reauth, and the member fixes it in the dashboard without touching any client config. Every connection is private, reachable only by the member who made it, or shared with the whole organization. An agent principal with an sk-csa- key reaches shared connections only. The connectors docs describe the three ways to connect: OAuth, a pasted API key, or your own OAuth app.

How do spend caps and an audit trail attach?

Because every call passes through one server, every call can be priced and recorded in one place. CoreSpeed prices each metered action in credits, and each charge lands itemized in the organization ledger. Two boundaries apply. The organization wallet: past the billing threshold, later metered calls are refused before the tool runs, as a 200 response with isError: true and the code payment_required. The API key: a monthly spend cap answers key_spend_limit_exceeded until the month rolls over or the cap is raised. Discovery, account reads and key management keep working through both.

The activity trail records each call with its action, actor, organization, outcome (ok, error, held or denied), surface and time. Members see their own actions; org admins see the organization. API-key activity is attributed through the key's owning identity. Prompts are never copied into the trail. See Activity and audit.

ConcernA local server per app, per clientOne gateway
ConfigurationN clients times M appsN clients plus M apps
CredentialsIn each client's config or processIn platform custody; the agent gets tools
Tool listWhatever the server exposesWhat this caller may call
SpendPer provider account, per clientOne ledger, caps per org and per key
AuditPer client, if anyOne trail across every client

What does a gateway not see?

A gateway judges, meters and records only the calls routed through it. A local stdio server the agent also has installed, a shell command, or a direct HTTP call from the agent's own code never reach it. Keep that in mind when you read the trail, and keep the client's own confirmation on for writes when other MCP servers are connected alongside.

The same limit applies to policy. Smart Approval, the gate CoreSpeed puts in front of writes, covers every agent and client on the team with one rulebook, for calls made through CoreSpeed. Introducing CoreSpeed explains why the organization, rather than any one agent, is the unit that owns connections, memory, budgets and the trail.

FAQ

Is an MCP gateway the same as an MCP server?

A gateway is an MCP server. What differs is what sits behind it: many apps and accounts, with sign-in, custody, caps and audit attached.

Do I still need local MCP servers?

Sometimes. A single-tool local server is fine for one person on one machine. A gateway earns its place when several people, clients or apps are involved.

Does the gateway see my agent's conversation?

No. It sees the tool call: the tool name, the arguments and the caller's identity.

A tool I expect is missing from tools/list. Why?

The app is not connected, or the capability is off in Dashboard → Tools. An agent key also reaches shared connections only, so a private connection never appears to it.