MCP Config Risk Check vs. reading the config by hand
Reading a short config with one obviously broad command catches that command. It reliably misses a secret-shaped literal sitting under an unrelated key name, a missing version pin buried inside one of four different package-manager syntaxes, and a tool name that collides across two servers loaded together — which is what this free, no-upload checker computes exactly, in one pass.
Where reading it yourself stops being enough
Anyone approving a new MCP server already does this: open the config, read the
command/args/env block, and decide whether it looks right.
For a single server with a bare shell command or an obviously root filesystem path, that read
catches it. The problem is the other checks below are not the kind of thing a skim of the
rendered keys and values reliably surfaces, especially once a config carries more than a
couple of servers.
| What you're trying to confirm | Reading the config yourself | This checker |
|---|---|---|
A server's command is a shell interpreter, or an argument is exactly a root path like /, ~, or C:\. | Works. This is the one case a plain read reliably catches. | Also catches it, in the same pass as everything below. |
An env value matches a real secret's shape (an sk- key, a ghp_/gho_ token, a Slack xox- token, an AWS AKIA key, a bearer token) sitting under a key not named token, key, or secret. | Easy to skim past — a reviewer's eye is drawn to keys that look suspicious by name, not to every value's shape regardless of its key. | Matched against every value against every known token shape, independent of the key name. |
A package or image launched with no version pin, across npx, uvx, pipx run, and docker run — four different pin syntaxes in the same config. | Requires remembering which syntax applies to which command while scanning every args array; easy to miss the one entry with no pin at all. | Checked against each command's own pin syntax, the same way every time. |
Whether a key named like a secret actually holds a live literal, versus a proper environment-variable reference such as "${MY_API_KEY}". | The two read as visually similar strings in a JSON value; misreading one for the other is easy at a glance. | Checked against the exact reference syntax, not just whether the value looks token-shaped. |
| A tool name exposed by more than one connected server, once the pasted data includes each server's own tool list. | Requires holding every server's full tool list in mind at once and comparing them pairwise — manageable with two servers, unreliable past a handful. | Compared exactly, name by name, across every server in the pasted data. |
| Re-checking an entire config again after adding or updating one server. | One server at a time, remembered by hand, every time something changes. | One paste, the whole config, every time. |
A quick read is still the fastest way to catch an obviously broad command in a small config, and
this checker is not doing anything a careful line-by-line audit couldn't — it is reading the
same command/args/env blocks a careful audit would, just
checking every value's shape and every pin syntax automatically instead of leaving the comparison
to be remembered by hand.
This tool needs no account and no sign-in: the browser page parses JSON you paste entirely in your own browser. It never sends your config anywhere.
Common questions
Can't I just read the config myself?
For a config with one or two servers and an obviously broad command like a bare shell launch, yes -- that case is visible on a single read. What reading does not reliably catch is a secret-shaped literal sitting under a key not named token or secret, a missing version pin buried inside one of four different package-manager argument syntaxes, or a tool name that collides between two servers loaded together. Those need every server's command, args, and env checked the same mechanical way, not remembered while skimming.
Why is spotting a hardcoded secret harder than it looks?
Because a reviewer scanning by eye naturally looks at keys named token, key, secret, or password and skims past the rest. A literal that matches a real secret's shape -- an sk- style key, a gh_-prefixed GitHub token, a Slack xox- token, an AWS AKIA access key, a bearer token -- can sit under any key name at all, including one that gives no hint. Confirming every value's shape against every known secret pattern, regardless of what its key happens to be called, is a pattern match across the whole config, not a read of the keys that look suspicious.
Why is a missing version pin easy to miss on a read-through?
Because npx, uvx, pipx run, and docker run each pin a version in a different place and syntax -- an @version suffix on a package name, a bare docker image without a :tag, or an argument list with no pin at all -- and a config with a dozen servers mixes all four. Holding four different pin syntaxes in mind while scanning a dozen args arrays, and noticing the one that has none, is exactly the kind of check that is reliable when it is the same mechanical comparison every time and unreliable when it depends on remembering which syntax applies to which command.
What about a tool name that collides across two servers?
That needs comparing every tool name a connected server exposes against every tool name every other connected server exposes -- not reading one server's config in isolation, but holding all of them in mind at once and checking for an exact match. With two servers and a handful of tools each this is manageable by eye; past a handful of servers it is the same kind of pairwise comparison a person does slowly and inconsistently and a check does exactly the same way every time.
Is this page making a live comparison against a tool or company?
No. This page describes a manual habit anyone approving an MCP server config already has -- reading the command, args, and env blocks by eye before trusting it. It names no competing product or company. The checker itself makes no network request of any kind: the browser page parses pasted JSON in your own browser, and nothing you paste is ever uploaded.
Want to know what a zero-finding scan actually means? Read why a clean scan isn't a safety guarantee.