Free tool

Cline MCP Config Validator

Paste your config and see what Cline will actually do with it. Most broken MCP configs are valid JSON — which is exactly why nothing tells you they are wrong.

Paste the JSON config. Remove any token first if you would rather — the checks do not need it.
Runs entirely in your browser. Nothing you paste is uploaded, stored or logged.

Connected at last. Now show someone what it does.

Getting the config right is the boring half. MCP Showcase takes the same server and produces a live playground your customers can try, with documentation for every tool.

How it works

link
Paste your config

Nothing is uploaded. The check runs entirely in your browser.

play_circle
We read it as Cline would

Root key, endpoint key, transport type and the client-specific fields that Cline treats differently from everyone else.

checklist
Fix what it finds

Each problem comes with what Cline expects instead, so it is a change you can make rather than a symptom to search for.

Why a valid config still does nothing

Almost every broken MCP config is valid JSON. Clients ignore keys they do not recognise, so a file with the wrong root key or the wrong endpoint field parses cleanly, Cline starts normally, and no servers appear. There is no error to search for. That silence is why these mistakes survive so long.

What this checks for Cline

  • Root key — Cline reads mcpServers. Anything else is parsed and ignored.
  • Endpoint field — remote servers must use url.
  • Entry shape — every server needs either a command to launch or an endpoint to connect to.
  • Plain HTTP — flagged, because any bearer token sent to that server travels unencrypted.
  • Cline-specific fields — see below.

disabled and autoApprove live in the config

Cline adds two fields the other clients do not have: "disabled" to turn a server off without deleting it, and "autoApprove", a list of tool names that run without asking you first. That second one is a security decision stored in a config file -- an auto-approved destructive tool will run unattended, so keep the list to read-only operations.

Your config is not uploaded

The check runs entirely in your browser and makes no network request. That is deliberate rather than incidental: MCP configs routinely contain API tokens, and "paste your config into this website" is a reasonable thing to refuse. You can confirm it in your browser's network tab.

If the config is right but the server is empty

Then the problem has moved out of the file. A client that shows the server but no tools is connecting and failing at the handshake or the transport, not misreading your config. The MCP Inspector shows which transport the server answers on and the raw request log, and the MCP Server Tester reduces the same thing to a pass/fail checklist.

Related tools

Once it connects, the hard part starts

A working config is table stakes. What it does not do is help anyone understand what your server is for — and if you publish an MCP server, that is the part that decides whether anyone configures it at all. MCP Showcase turns the same endpoint into a live playground with per-tool documentation, so evaluating it takes a click instead of a config file and a restart.

Frequently asked questions

Because clients ignore what they do not recognise. A config with the wrong root key, or a remote endpoint under the wrong field name, parses perfectly and results in a client that sees no servers and reports nothing. Silence is the normal failure mode here.

That the root key is the one Cline reads, that remote servers use the field name Cline expects, that each entry has either a command or an endpoint, that nothing is served over plain HTTP, and the client-specific quirks that apply to Cline in particular.

No. It is parsed in your browser and never leaves your machine — which matters, because MCP configs frequently contain API tokens. No network request is made at all.

It depends entirely on the client, which is why this catches so many people. Claude, Cursor, Windsurf and Cline use mcpServers; VS Code uses servers; Zed uses context_servers; Codex CLI uses mcp_servers in TOML. The result below names the one Cline needs.

Then the problem is at the server rather than in the file. Run the endpoint through the MCP Inspector to confirm it completes a handshake and to see what it advertises.

More free MCP tools