An MCP server entry is a small piece of JSON with an unforgiving failure mode: get a key wrong and there is no error, the server simply never appears. Each transport wants a different shape — a local one needs a command and its arguments, a remote one needs a URL and usually a header — and mixing them produces a file that looks complete and does nothing. This builder asks only for the fields the chosen transport actually uses, warns when a field from the other one is filled in, and flags what is probably the most common real-world mistake: a live credential written into a file that ends up in a repository. It emits both the config file and the equivalent one-line command.
Features
Only the fields the chosen transport uses
Warns when a field belonging to the other transport is set
Flags a real-looking secret written into the file, but not a placeholder
Warns about plaintext HTTP to a remote host, quiet for localhost
Catches arguments baked into the command field
Environment variables and headers as editable pairs
Emits both the project file and the desktop app's config
The equivalent command-line invocation, correctly quoted
How to use the MCP Server Config Builder
Name the server — that is how its tools are namespaced
Pick the transport it uses
Fill in the command and arguments, or the URL and headers
Copy the JSON into your config, or run the command instead
Example
Input
"command": "npx -y some-server"
Output
Warning: looked up as a single executable with that name
The first word is the command; everything else is an argument.
Common errors & troubleshooting
The server never shows up. — Usually a shape mismatch: a stdio entry with a url, or a remote entry with a command. Both are flagged here, because neither produces an error on its own.
The command is not found. — Arguments have to be separate. Put npx in the command and the rest in the arguments list — a command containing spaces is looked up as one executable with that name.
It works locally and fails for everyone else. — Usually an absolute path from your machine in the arguments, or a credential in your environment that nobody else has.
I have a token in the config file. — Reference an environment variable instead. A real-looking secret is flagged here, because config files get committed.
Frequently asked questions
Which transport should I use?
stdio for anything you run locally — the client starts it as a process and talks over its standard input and output. HTTP for a remote server. SSE exists mostly for servers written before HTTP became the usual choice.
Where does the config file go?
A project file lives in the repository so the whole team gets the same servers; the desktop app has its own config for servers you want everywhere. Both shapes are emitted, and the path is shown.
How do I keep a token out of the file?
Write it as an environment variable reference rather than the value. The check here looks at whether the value looks like a real credential or a placeholder, and only complains about the former.
Should I use the config file or the command?
They do the same thing. The file is better when it should be committed with the project; the command is faster for something you are trying out. Both are produced from the same fields.
Why does the server name matter?
It is the key the entry is stored under and the namespace its tools appear under, so two servers cannot share one, and renaming it changes how its tools are referred to everywhere else.