One gateway for every agent

Register your MCP servers once, connect Claude Code, Cursor, Codex and the rest to one URL, and give each agent its own profile.

The problem it solves

Every coding agent keeps its own MCP config: ~/.claude.json, ~/.cursor/mcp.json, ~/.codex/config.toml, .vscode/mcp.json. Add a server and you add it four times, along with its token. Rotate a token and you rotate it four times.

Each of those clients also loads every tool from every server into every turn. Ten servers with twenty tools each is two hundred tool definitions, often tens of thousands of tokens, spent before you type anything.

With the gateway you register servers once on mcpi.app. Each client gets one entry pointing at https://mcpi.app/mcp and sees three tools: find_tools, call_tool, and call_tool_approval. The agent asks for what it needs, gets back the few tools that fit, and calls them.

1. Register your servers once

Dashboard → Gateway → Add endpoint for each remote MCP server: a name, a URL, and how it authenticates (bearer token, custom header, or OAuth). Upstream credentials are stored once, on the gateway. Clients never see them.

2. Create one key per agent

Settings → API keys → Create key for each client: claude-code, cursor, ci-bot. Separate keys let you:

  • give each agent a different profile (step 4)
  • revoke one agent without touching the others
  • see on the Gateway page which agent made a call, or tried one that was refused

Clients that support OAuth (Claude Desktop, claude.ai) can skip the key. The consent screen asks which profile the client gets.

3. Connect each client

The same URL everywhere. Swap in that client's key.

Claude Code

sh
claude mcp add --transport http mcpi https://mcpi.app/mcp \
  --header "Authorization: Bearer oat_…"

Cursor: ~/.cursor/mcp.json (or .cursor/mcp.json in a project)

json
{
  "mcpServers": {
    "mcpi": {
      "url": "https://mcpi.app/mcp",
      "headers": { "Authorization": "Bearer oat_…" }
    }
  }
}

VS Code: .vscode/mcp.json

json
{
  "servers": {
    "mcpi": {
      "type": "http",
      "url": "https://mcpi.app/mcp",
      "headers": { "Authorization": "Bearer oat_…" }
    }
  }
}

Codex: ~/.codex/config.toml, with the key in MCPI_API_KEY

toml
[mcp_servers.mcpi]
url = "https://mcpi.app/mcp"
bearer_token_env_var = "MCPI_API_KEY"

Windsurf: ~/.codeium/windsurf/mcp_config.json

json
{
  "mcpServers": {
    "mcpi": {
      "serverUrl": "https://mcpi.app/mcp",
      "headers": { "Authorization": "Bearer oat_…" }
    }
  }
}

Gemini CLI: ~/.gemini/settings.json

json
{
  "mcpServers": {
    "mcpi": {
      "httpUrl": "https://mcpi.app/mcp",
      "headers": { "Authorization": "Bearer oat_…" }
    }
  }
}

OpenClaw

sh
openclaw mcp set mcpi '{"url":"https://mcpi.app/mcp","transport":"streamable-http","headers":{"Authorization":"Bearer oat_…"}}'

Hermes: under mcp_servers in ~/.hermes/config.yaml, then /reload-mcp

yaml
mcp_servers:
  mcpi:
    url: "https://mcpi.app/mcp"
    headers:
      Authorization: "Bearer oat_…"

Grok Bot and Muse add servers from chat. Send:

text
Add a custom MCP server called mcpi at https://mcpi.app/mcp with the header Authorization: Bearer oat_…

Claude Desktop / claude.ai: Settings → Connectors → Add custom connector, URL https://mcpi.app/mcp. Sign in with OAuth and pick a profile on the consent screen.

Config formats move between client releases. If one of these is refused, check the client's MCP docs for its remote-server (Streamable HTTP) syntax. The URL and header stay the same.

From then on, a server you add on the Gateway page reaches every client on its next find_tools, with no config edits.

4. Give each agent a profile

A profile is its own set of tool permissions over the same endpoints. It is bound to the key, so an agent cannot ask for a different one.

A setup that works for most people:

Profile Default For Typical rules
Default Allows Your own interactive client Destructive tools set to Needs approval
read-only Blocks CI jobs, background agents, review bots Allow only the read-only tools
project-x Blocks An agent working on one codebase Allow only that project's tracker, docs and deploy tools

To build read-only: Profiles card → add a profile that blocks tools by default. Then open each endpoint's Tool permissions, pick the profile at the top, and allow the tools under Read-only tools. A tool an upstream adds later stays out of a blocking profile until you allow it.

For approval prompts in your interactive client, leave call_tool auto-approved and set call_tool_approval to ask. Only the tools you marked will prompt.

5. Check what you saved

The Gateway page estimates the context kept out of your clients over the last 7 days: the tool definitions find_tools did not return, summed over every call. Next to it are the hit rate (how often the agent called a tool that find_tools had just returned), your most-called tools, and every call a profile refused, with the key that made it.

A low hit rate usually means requests are too vague. Agents do best when they say what they want to do ("create an issue in the tracker"), not which tool they think exists.

What you also get

  • Changed tools are held. When an upstream rewrites a tool's description or schema, every client keeps seeing the version you reviewed until you accept the change. See Changed tools are held.
  • Contract notes. find_tools flags tools from an endpoint whose contract moved, with breaking / compatible / cosmetic counts, so the agent knows before it calls.

Limits

Remote (Streamable HTTP) servers only. Local stdio servers have no URL the gateway can reach, so keep those in the client's own config, or run mcpi serve for them. Plan limits are in What it costs.

Navigation