MCP.directory
All tools

Cline MCP Config Validator

Paste your cline_mcp_settings.json to validate the mcpServers shape and Cline-specific fields (disabled, alwaysAllow).

Your config never leaves your browser. No upload. No login.
Paste your cline_mcp_settings.json
Your config never leaves your browser
0 chars

Paste your cline_mcp_settings.json above to run deterministic checks.

Or click to see how it works.

What this validator checks

  • •JSON syntax + line/column on errors
  • •UTF-8 BOM, smart quotes, trailing commas
  • •Top-level mcpServers object shape
  • •Per-server command / url shape
  • •disabled must be a boolean
  • •alwaysAllow must be string array
  • •Env-var values must be strings
  • •Windows backslash escapes
  • •Insecure HTTP for non-local URLs
  • •API key / token leak detection
  • •Duplicate / case-conflict server names
  • •Both transports set (command + url collision)

Why this exists

Cline's MCP support follows the standard mcpServers schema with two extension fields: disabled (skip server at startup) and alwaysAllow (allow specific tools to run without per-call approval).

Most pasted-from-tutorial issues come from copy-pasting Claude Desktop snippets that don't include these Cline-specific fields — that's fine, both are optional. The actual silent failure pattern is type errors: "disabled": "true" (string instead of boolean), or "alwaysAllow" with non-string entries. The validator catches these.

Frequently asked

Where is Cline's cline_mcp_settings.json?▼
The file is named cline_mcp_settings.json. Cline's official docs (docs.cline.bot/mcp/configuring-mcp-servers) do NOT publish the OS-specific paths in the audited version of the page. Easiest way to find yours: open Cline in VS Code/Cursor, go to the MCP Servers panel, and click the gear/settings icon — it opens the file in your editor.
What are the "disabled" and "alwaysAllow" fields for?▼
`"disabled": true` skips the server during startup without removing the config. Useful for temporarily turning off a misbehaving MCP. `"alwaysAllow": ["tool-name", ...]` lets that server's tools run without per-tool approval prompts. Use alwaysAllow sparingly — tool calls won't ask before executing, which can be risky for tools that mutate state. The validator confirms types: disabled must be boolean, alwaysAllow must be a string array.
Can I share my Claude Desktop config with Cline?▼
Mostly yes. The top-level `mcpServers` key and command/args/env/url shape are identical. Cline-specific extras (`disabled`, `alwaysAllow`) won't break anything if absent. The biggest practical difference is the filename — Cline uses cline_mcp_settings.json, not claude_desktop_config.json. Copy your servers, optionally add `"disabled": false` and `"alwaysAllow": []` per server.
How do I configure tool-level network timeouts in Cline?▼
Per Cline's docs, network timeouts are configured in the UI (the MCP Servers panel), not in the JSON file. The validator checks structural fields only and doesn't touch UI-managed settings.
Does Cline support remote MCP servers?▼
Yes — use the `url` field with an http(s) URL for SSE transport. For authentication, embed env-var substitution ("$VAR") inside env values or query strings. The validator checks the URL shape (must be http/https) and warns on insecure HTTP for non-local servers.
What's the difference between Cline's config and Roo Code's config?▼
Roo Code is a Cline fork; the schemas are largely the same (mcpServers + command/args/env or url, plus disabled/alwaysAllow). If you're on Roo Code, this validator should still catch all structural issues — only the file path may differ. Consult Roo Code's docs for the exact location.
Is my config sent to your server?▼
No. The validator runs entirely in your browser as JavaScript. Your config — and any API keys it contains — never leaves your machine. Open DevTools → Network during validation to confirm zero outbound requests.

Spotted a check we should add?

Open an issue on the directory, or browse the 2,000+ MCP servers.

← All toolsClaude Desktop validator