Configure MCP Once, Use It in Claude, Cursor, and Codex

Count how many AI clients you have open right now: Claude Desktop, Cursor, Claude Code, Codex, maybe Gemini CLI. Now count how many MCP servers you use: filesystem, GitHub, Postgres...

Multiply those two numbers. That product is how many times you have to configure the same MCP servers. Four clients × three servers = twelve config entries, scattered across four files that live in different places and don't even share a format. Every new client, every new server, every rotated key — the multiplication runs again.

It doesn't have to: you can configure MCP exactly once. With MCP2Skill, you maintain a single server inventory in one place, and every client — Claude, Cursor, or Codex — just gets a gateway URL. This article tallies the real cost of duplicate configuration, then walks through the once-and-done setup.

Where the Same MCP Config Gets Duplicated

MCP itself never specified where configuration lives — it standardized how clients and servers talk, and each client decided for itself where to store the server list and in what format. So the same filesystem server looks like this across clients:

Three consequences follow directly from this table:

1. The N × M problem. New MCP server means editing M config files — and hoping you didn't typo one of them.
2. Incompatible formats. Claude-family clients use JSON, Codex uses TOML. You can't even copy-paste; every migration is a manual rewrite.
3. Secrets everywhere. Your GITHUB_PERSONAL_ACCESS_TOKEN is stored once per config file. When it expires you re-paste it M times; miss one spot and that client fails silently.

And a fourth, less visible but just as real: every client launches its own copy of each MCP server process. Three clients using the same filesystem server means three independent processes in memory.

(For the architectural view of this problem, see A Centralized MCP Gateway; this post focuses tightly on configuration duplication.)

Why You Keep Configuring It Again and Again

Because every client acts as its own configuration administrator.

The MCP protocol solved "how clients and servers talk," not "where the config lives and who maintains it." So each client made its own choice: Claude Desktop buried a JSON file deep in the system directories, Codex picked TOML, Cursor offers both global and project scopes. Each decision is defensible alone; together they mean nobody owns the shared source of truth.

The immediate cost of config drift is silent failure: the same GitHub server works in Cursor but errors in Claude Code, and the culprit is a token updated in one file but not the other. The N × M maintenance burden compounds too — as long as your client count or server count grows, this tax keeps growing with it.

The Configure-Once Approach: One Source of Truth, One URL per Client

The fix collapses multiplication into addition: keep the real configuration — commands, arguments, environment variables, secrets — in one centrally managed place, and leave each client with nothing but an address that points to it.

That is exactly what MCP2Skill does. It's a desktop app: you maintain your single MCP inventory inside it, and clients connect through the gateway. The migration is three steps.

Step 1: Import, don't retype

MCP2Skill imports existing MCP configuration from Claude Desktop, Cursor, Claude Code, Gemini CLI, and Codex, plus clipboard and local JSON files. Whatever is already configured on your machine comes over in one click — no re-typing server commands or keys.

Step 2 (optional): Draw boundaries with workspaces

You don't have to expose every tool to every client. Create a workspace, combine multiple MCP services, and filter which tools survive — a capability boundary scoped to a specific scenario. Day-to-day file access in one workspace, analytics tools in another. Any client that connects sees only the slice you intended.

Step 3: Hand each client a URL

From a service or workspace detail page, you can:

• Copy the endpoint address — a gateway URL to register as a remote server in the target client's MCP config. Even TOML-based clients like Codex only need this one URL.
• Copy the JSON config — a ready-made block with the service name, connection type, gateway URL, and required headers already filled in. Paste it straight into Claude Code–compatible clients. If you've enabled an API Key, the auth header is included too.

From then on, "adding MCP to a new client" is equivalent to pasting a URL. For clients on another machine, enable remote access in settings and turn on API Key authentication at the same time — same URL, one extra layer of auth.

(For the full client-side walkthrough, see the docs: Connect External AI Clients.)

What Changes After You Consolidate

Two more gains come along for the ride. Processes stop duplicating: servers are launched by MCP2Skill, so you no longer run M copies of the same process doing the same job. Everything becomes observable: since all calls pass through one entry point, the dashboard shows volume, failure rate, and trends per service — MCP goes from "works but invisible" to diagnosable.

And if your agent supports Skills (Claude Code, for example), there's one more step available: convert your most-used tools into on-demand Skills to cut token cost further. The Skill path and the gateway path coexist — see How to Convert Any MCP into a Skill for that workflow.

FAQ

After configuring once, what does each client still need?

Exactly one thing: the gateway URL (plus the auth header, if you enabled an API Key). Server commands, arguments, environment variables, and secrets live only inside MCP2Skill — clients carry no server details at all.

Can clients on another machine share this configuration?

Yes. Enable remote access in MCP2Skill's settings together with API Key authentication, and off-machine clients connect through the same URL. Remote access is a deliberate decision — turn it on only when you actually need it.

If I rotate the gateway API key, do I have to update every client again?

Distinguish two kinds of keys. Server keys (a GitHub token, say) live only in MCP2Skill — rotating them is invisible to clients. If you regenerate the gateway auth key, connected clients' old configs stop working and you'll need to re-copy the JSON once. In other words: routine server-side changes never touch your clients; only gateway auth changes require one re-paste.

I only use one AI client. Is this still worth it?

Yes, for different reasons. With a single client there's no duplication to eliminate, but you still get a unified management interface, per-workspace tool filtering, and call logs with statistics. And the day you add a second client, migration cost is zero.

Does this conflict with the Skills path?

No — they complement each other. The gateway solves multi-client reuse and compatibility; Skills solve on-demand loading and token cost. MCP2Skill's default recommendation: agents that support Skills should take the Skill path for their most-used tools, and leave the rest to the gateway.

Getting Started

1. Install MCP2Skill and import your existing MCP config (Claude Desktop, Cursor, Claude Code, Codex, and more are supported).
2. (Optional) Use workspaces to draw capability boundaries per scenario.
3. Copy the JSON config or endpoint URL and paste it into every client you use.
4. Open the dashboard and confirm calls are flowing through the gateway.

Back to the title's question: how many times do you have to configure the same MCP servers? Per-client, the answer is N × M. Configure once, and the answer is 1. Run the numbers for your own client and server count — then start consolidating from the client you use most.