MCP Config Risk Check
Paste an mcp.json, claude_desktop_config.json, or any MCP server config and get every risky pattern flagged in seconds -- broad filesystem/shell access, secrets hardcoded instead of referenced from the environment, missing version pins, and duplicate tool names across servers.
Mechanical checks, not a security audit. This tool never contacts a server, a registry, or a vulnerability database -- it only looks at the text you paste and flags structural patterns in it. A finding is something worth a human look, not a verdict, and a clean result is not a safety guarantee.
1. Paste your config
Accepts the Claude Desktop / Claude Code {"mcpServers": {...}} shape, VS Code's {"servers": {...}} shape, a bare name-to-config object, or an array of server entries. Nothing here is uploaded -- everything runs in this page.
Findings
Paste a config above, or load the example, to see findings.
Usage is optional, stays in this browser, and counts only that an audit ran or a summary was copied. Nothing you paste -- no config contents, server names, or findings -- is ever recorded, uploaded, or sent to an analytics service. Uncheck to turn it off. Do Not Track and Global Privacy Control disable counting automatically.
Common questions
What config formats does this tool accept?
The Claude Desktop / Claude Code shape ({"mcpServers": {...}}), the VS Code shape ({"servers": {...}}), a bare object of server name to config with no wrapper key, and a plain array of server entries. If an entry also carries a "tools" list (as a captured manifest export would), the duplicate-tool-name check runs against it too.
Does this tool contact my MCP servers, a registry, or a vulnerability database?
No. It never makes a network request of its own. It only looks at the text you paste, entirely in your browser, and flags structural patterns in it — it does not verify a package's actual published version, scan its code, or know whether a server is currently compromised.
Is a flagged finding proof that a server is unsafe?
No. Every finding is a structural pattern worth a human look, not a verdict. A shell-launching server or an unpinned package can be entirely intentional and fine for your setup; a config with zero findings is not a guarantee of safety either — it only means none of this tool's mechanical checks fired.
How is this different from a tool that diffs two MCP manifests over time?
This tool looks at a single, current config — the file your client reads to launch each server — and flags risk patterns in it right now. MCP Supply-Chain Watch instead compares two captured tool manifests to show what changed between them (a tool added, removed, or given a description with model-directed instruction language). Both are useful and answer different questions: this one asks "is today's launch config risky?"; that one asks "what changed since I last approved this server?"