MCP Config Generator

What the MCP config generator does

An MCP server gives an AI client tools: a database, a browser, a ticket system. Each client lists its servers in its own file and format, so a server's README rarely matches yours. Describe the server once, and the generator writes it for Claude Desktop, Claude Code, Cursor, VS Code, Devin (formerly Windsurf) and OpenAI Codex: the file to edit on your system, the JSON or TOML to add to it, and the command that adds it, where the client has one.

Already set up servers in one client? Paste its config under Convert a config to get the same servers for every other client. Under Add to your existing file, paste the file you have, and you get it back with the servers added and nothing else changed.

How to add an MCP server to your AI client

Examples

{"name": "filesystem", "command": "npx", "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects"]}

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/me/projects"
      ]
    }
  }
}

{
  "mcpServers": {
    "fetch": { "command": "uvx", "args": ["mcp-server-fetch"] },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${env:GITHUB_PERSONAL_ACCESS_TOKEN}" }
    }
  }
}

[mcp_servers.fetch]
command = "uvx"
args = [ "mcp-server-fetch" ]

[mcp_servers.github]
command = "npx"
args = [ "-y", "@modelcontextprotocol/server-github" ]
env_vars = [ "GITHUB_PERSONAL_ACCESS_TOKEN" ]

{"name": "tickets", "url": "https://mcp.example.com/mcp", "headers": {"Authorization": "Bearer your-token"}}

{
  "inputs": [
    {
      "type": "promptString",
      "id": "tickets-token",
      "description": "TICKETS_TOKEN for tickets",
      "password": true
    }
  ],
  "servers": {
    "tickets": {
      "type": "http",
      "url": "https://mcp.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${input:tickets-token}"
      }
    }
  }
}

Where each client keeps its MCP servers

A file for all projects applies everywhere you use the client; a project file sits in the project's folder and can be committed, so your team gets the server too. Claude Code keeps servers for all projects in ~/.claude.json together with the rest of its state: add those with claude mcp add rather than by editing the file. Codex's config.toml holds its other settings too, so add the table to it instead of replacing the file.

How the formats differ

Four of the clients list servers under mcpServers, each server by its name. VS Code uses servers, next to an optional inputs list for secrets, and Codex uses a TOML table per server, [mcp_servers.<name>], in config.toml.

The type field differs too. VS Code needs it on every server: stdio or http. Claude Code reads a server without type as a local one, so a remote server there needs "type": "http". Cursor and Devin tell the two apart by whether the entry has a command or a url, and Codex by the table's fields.

On Windows, a path in JSON has each backslash written twice, as in "C:\\Users\\me"; the generator does that for you, and quotes TOML the same way.

Local and remote servers

A local server runs on your computer: the client starts the command with its arguments and talks to it through standard input and output (stdio). Servers you install from npm, PyPI or a container image work this way, started with npx, uvx or docker. A remote server is already running somewhere else and the client connects to its URL over HTTP, the transport MCP calls Streamable HTTP.

Claude Desktop's config file only starts local servers. Add a remote server there under Customize > Connectors as a custom connector instead; Anthropic connects to it from its cloud, so the server must be reachable from the internet.

Keeping secrets out of the config

A config file is easy to commit or share by mistake, so a token written into it can leak. With Secrets set to Placeholders, the generator writes each client's way of reading a value from elsewhere:

• Claude Code reads ${NAME} from the environment it starts in, and ${NAME:-default} falls back to a default.
• Cursor reads ${env:NAME}.
• VS Code asks for the value the first time the server starts, through an entry in inputs, and keeps it in its secret storage.
• Codex forwards variables to a local server with env_vars, and reads a token for a remote one with bearer_token_env_var or env_http_headers.
• Claude Desktop has no placeholder, and Devin recommends keeping keys in .devin/mcp_config.local.json, which stays out of version control. The generator writes the value as entered and warns you.

Converting a config to another client

Under Convert a config, the generator reads a pasted config as JSON, JSON with comments (VS Code's files have them) or TOML, and tells the client from the format and the key the servers are under: servers is VS Code, [mcp_servers.<name>] tables are Codex, and mcpServers is one of the other four, which share a format. Choose the client under From if the guess is wrong. Each server is then written for every client the same way as one from the form.

Placeholders change with the client: ${GITHUB_TOKEN} in Claude Code becomes ${env:GITHUB_TOKEN} for Cursor and VS Code and env_vars in Codex, and a VS Code input becomes an environment variable named after it. Claude Desktop and Devin replace none, and editor variables such as ${workspaceFolder} only work in Cursor and VS Code; the generator warns where a client would pass the text as it is. A default such as ${API_URL:-https://api.example.com} exists only in Claude Code.

The conversion carries what every client understands: the command, arguments, environment variables, working directory, URL and headers. Settings of one client, such as Codex's startup_timeout_sec, an enabled_tools list or Devin's disabled, are listed in the problems instead of being dropped silently. A server on the older SSE transport is written as a remote one, with a reminder to check its Streamable HTTP endpoint, often /mcp rather than /sse.

Adding a server to an existing config

Add a new server next to the others, under the same mcpServers, servers or mcp_servers, rather than replacing the file. Paste the file under Add to your existing file in your client's tab and the generator does that for you: the server goes after the last one, indented the way your file is, and other servers, comments and settings stay exactly as they were. Codex gets a new table at the end of config.toml, and VS Code gets the input prompts its secrets need.

Names must be unique within a file, as a second entry with the same name replaces or clashes with the first, depending on the client. When a name is taken, choose under If a name is taken whether to rename the new server, replace the old one or keep it. Check the result with the MCP Config & Schema Validator before you restart the client, and the JSON Formatter shows where a comma or brace went missing in a file the generator can't read.

Options

Common errors and fixes