One MCP config for every coding agent

If you use more than one agent, you keep more than one MCP config. Claude Code reads ~/.claude.json, Cursor reads ~/.cursor/mcp.json, Codex reads ~/.codex/config.toml, and Hermes and OpenClaw have their own files. Add a server and you add it to each. Rotate a token and you rotate it in each.

Each client also sends every tool definition from every server with every turn. That is how MCP works: the model has to see a tool to call it.

What that costs

Tool definitions are not small. A name, a description written for a model, and a JSON Schema for the arguments add up to a few hundred tokens each, and more for the tools you most want an agent to use. Ten servers with twenty tools each is two hundred definitions, loaded before you type anything, and loaded again on every turn after that.

My own setup is nine servers: an issue tracker, error tracking, analytics, SEO, a blog, a feedback tool and a few more. Between them they expose 215 tools.

Most of them are irrelevant to any one request. An agent fixing a failing test does not need the tools for your billing provider.

One URL, three tools

The mcpi gateway turns that around. You register your remote MCP servers once, on mcpi.app. Every client gets one entry pointing at https://mcpi.app/mcp, and sees three tools:

• find_tools: describe what you want in words, get back the few tools that fit, with their schemas
• call_tool: run one of them
• call_tool_approval: the same call, for tools you want a prompt on

The agent asks for what it needs when it needs it. The rest of the catalog stays out of its context: in my case, three tool definitions instead of 215.

Adding a server becomes one change on one page. Every client sees it on its next find_tools, with no config edits.

Different agents, different permissions

The catch with one URL is that every agent would reach every tool. Behind a gateway, a client's own per-tool switches collapse into one call_tool. So the gateway keeps the permissions instead, per tool, and groups them into profiles:

• Your interactive client gets everything, with destructive tools set to need approval.
• A CI job or background agent gets a profile that blocks by default and allows only read-only tools. A tool an upstream adds later stays out until you allow it.
• An agent working on one project reaches that project's tracker and docs, and nothing else.

A profile is bound to the API key or OAuth grant, so an agent cannot ask for a different one. The Gateway page shows what each client called, how often it found the right tool the first time, and every call a profile refused.

Changed tools are held

A server can rewrite a tool after you approved it. A new description is also how a server slips new instructions to a model. When a tool's definition changes, the gateway keeps serving the version you reviewed until you accept the change, and tells you whether it was breaking, compatible or cosmetic. That classification is the same engine mcpi uses to track contract changes across the directory.

Try it

Setup for each client is in One gateway for every agent. The free tier covers three endpoints and 100 find_tools calls a day.