MCP Server Config Generator
Fill in the server and get the entry for claude_desktop_config.json, .mcp.json or VS Code. The output carries the settings that stop a server starting, and any credential you type is replaced with a reference rather than written into the file.
claude_desktop_config.json
updates as you typeCommon mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Using a relative path because it works in your shell
The client spawns the process from the application directory or your home folder, never from where the config file lives. `./build/index.js` resolves against a directory you have never looked at.
Instead:Absolute paths, or a PATH command such as `npx` with an absolute script argument.
Relying on PATH additions from .zshrc or .bashrc
Those apply to interactive shells. An app launched from a dock or start menu is not one, so nvm's node, pyenv's python and every exported variable are simply absent.
Instead:Name each variable in the `env` block, and point at an interpreter by absolute path rather than trusting a version-manager shim.
Pasting a real token into `env`
A project `.mcp.json` is committed by definition, a desktop config is picked up by settings sync, and both get pasted into issue reports. The token is disclosed by all three routes.
Instead:Reference it: `${VAR}` from the environment, or `${input:name}` with an inputs entry in VS Code. Rotate anything already committed.
Why an MCP server that runs in your terminal does not run in the client
Almost every first-time failure is one of four things, and none of them produce a useful error message.
The working directory is not where the config is
A client spawns the server process from wherever the application happens to be running: the app bundle on macOS, the install directory on Windows, sometimes the user's home. It is never the folder holding the config file. So ./build/index.js, which is correct in your shell, resolves against a directory you have never looked at. Use an absolute path, or set the working directory field.
A GUI application does not read your shell profile
PATH additions, nvm, pyenv, asdf and every variable exported from .zshrc apply to interactive shells. An app launched from the dock or the start menu is not one. That is why `node` can be missing from a config that works when you run the same command by hand, and why an API key you exported is simply absent. Name every variable in the environment field, and point at an interpreter by absolute path rather than trusting a shim.
npx asks a question nobody can answer
When the package is not already cached, npx prompts before installing. The client attached pipes, not a terminal, so the prompt is written into the void and the process sits there. It works on your machine because you ran it once already. Put -y first in the arguments.
stdout is the transport, not a log
On stdio the two processes talk in newline-delimited JSON over stdout. A banner, a progress bar, a console.log left in, or a dependency that prints on import all land in the middle of a message. The client fails to parse and, in most implementations, stays desynchronised for everything after. Every log line goes to stderr.
Secrets in this file are secrets in your git history
A project .mcp.json is committed by definition, a desktop config is picked up by settings sync, and both get pasted into issue reports when a server will not start. Reference a credential rather than writing it: ${VAR} from the environment, or ${input:name} with an inputs entry if the target is VS Code. If you type a real token into the environment field, this tool substitutes the reference form into the output rather than handing it back to you.
What this cannot see
Whether the command exists, whether the package name is real, whether the URL answers, and whether the server implements MCP at all. This builds the file from the fields above and nothing else: it runs entirely in your browser and contacts no registry. It also cannot know your client's version, and the config shapes differ between them, so treat the generated file as a starting point and check it against your client's own documentation. A config that passes every check here can still fail because the server itself crashes on startup, which is what the stdio session debugger is for.