If you've set up MCP servers across Claude Desktop, Claude Code, and Cursor, you've hit this: each client wants the same servers in a different file, in a slightly different place, and you end up copy-pasting JSON three times and getting the paths wrong.
The MCP roadmap itself lists config portability as an open problem — "setting up an MCP server in one client means starting from scratch in another."
The three places nobody remembers
-
Claude Desktop:
claude_desktop_config.json(Settings -> Developer -> Edit Config) -
Claude Code:
.mcp.jsonin your project root (orclaude mcp add) -
Cursor:
.cursor/mcp.json(project) or~/.cursor/mcp.json(global)
Same mcpServers shape, three locations, and it's easy to fat-finger a path or forget to restart the client.
A tiny tool for it
I made a free browser tool: list your MCP servers once (name + command), and it gives you the correct config JSON and the exact file location for each client. Presets for common servers, edit anything, copy.
https://hann2626-soru.github.io/mcp-config-helper/
No signup, client-side, MIT. EN / 日本語.
One caution while you're at it: AI assistants love to suggest MCP server packages that don't exist. Before you npx/uvx something an AI told you to, it's worth checking it's real (pkg-guard does this automatically as a Claude Code hook).
Top comments (1)
A generator is a good bridge, especially if it treats configuration as a compiled artifact rather than the source of truth. I'd make the source manifest hold server identity, package/image version or digest, transport, arguments, project/global scope, and capability expectations, then have client-specific exporters render the three formats.
The important exception is secrets: the browser tool should generate secret references or placeholders, never encourage copying plaintext tokens into three JSON files. Each client may also inherit a different environment and trust boundary, so validation should check executable resolution, file permissions, variable availability, and whether a project-scoped config can be committed safely.
Portability also needs a compatibility report, not only syntactically valid JSON. Clients differ in transport support, OAuth handling, roots, prompts/resources behavior, and extension fields. Flag unsupported or dropped settings during export, and add a doctor command that launches the configured server, performs the MCP handshake, checks protocol/capabilities, and reports the exact config file used. That would catch the common “valid config, wrong scope, stale client process” failure class.