Pick your client and get an MCP config it will actually read — correct file, correct root key, correct transport. Ten clients, ten different answers.
Config files are for people who already decided to use your server. MCP Showcase gives you one link that shows anyone what it does, with nothing to configure.
Ten clients, each with its own file, format and field names.
Everything runs in your browser — your URL and any token stay on your machine.
The result is in the exact format that client reads, with the file path to put it in.
MCP standardises the protocol, not the configuration. These ten clients read different files, in three different formats, with different key names for the same thing. The table below is the whole problem in one place — and the reason a config copied from one client into another usually parses cleanly and connects to nothing.
| Client | Format | Root key | Remote endpoint |
|---|---|---|---|
| Claude Desktop | JSON | mcpServers |
via local bridge |
| Claude Code | JSON | mcpServers |
url |
| Cursor | JSON | mcpServers |
url |
| VS Code | JSON | servers |
url |
| Windsurf | JSON | mcpServers |
serverUrl |
| Codex CLI | TOML | mcp_servers |
url |
| Gemini CLI | JSON | mcpServers |
httpUrl |
| Cline | JSON | mcpServers |
url |
| Zed | JSON | context_servers |
url |
| Continue | YAML | mcpServers |
url |
mcpServers. VS Code reads
servers, Zed reads context_servers, Codex CLI reads
mcp_servers. Wrong key, valid file, no servers, no error.url for most, serverUrl for
Windsurf, httpUrl for Gemini CLI when the transport is streamable HTTP.mcp-remote, which is a
completely different config shape.Everything here serves people who already decided to use your server. MCP Showcase is for the ones who have not: point it at the same URL and it produces a live playground with documentation for every tool, so evaluating your server takes a click rather than a config file and a restart.