We built mcp-customs, a free, offline CLI that checks an MCP server for
common security risks before you install it — think npm audit, but
for the servers your AI agent connects to. Before asking anyone to use
it, we pointed it at 12 real, popular MCP servers and read every single
finding by hand. Here's what actually held up.

The setup

We pulled the current top MCP-related repos on GitHub by star count and
scanned each one as-is, no cherry-picking:

*see below — these two scores don't mean what they look like they mean.

Finding #1: almost nobody declares permissions

Eleven of twelve servers had zero permission or scope declaration in
their manifest. Not "weak" declarations — none at all. This isn't a
ranking judgment on any one project; right now there's no real convention
for it. If you're building an MCP server, declaring what it actually
needs (filesystem? network? shell?) is the single easiest thing you can
do to make a client's "do you want to allow this?" prompt mean something.

Finding #2: our own scanner was the bigger story

Before publishing anything, we split every finding into "runtime code"
vs. "test/dev/script code" — because a subprocess.run(shell=True) in a
test fixture is a very different thing from the same line in a request
handler. Once we did that:

• pal-mcp-server scored 0/100 with 13 findings. Every single one was in tests/ or simulator_tests/ — fake API keys used to test a PII sanitizer, and a shell=True call in a test for a security-audit feature. Runtime-code findings: zero.
• shadcn-ui-mcp-server also scored 0/100. Two of its three findings were execSync() calls in a release-versioning script (scripts/bump-version.js) — not reachable by an agent, just a maintainer running npm version.
• We also caught our own bug mid-process: the scanner initially flagged a commented-out eval() call in notion-mcp-server as critical. It was inside a // comment. We fixed comment-stripping before re-running anything in this post — an earlier draft of this table would have been wrong.

A heuristic scanner that can't tell test code from runtime code, or a
comment from a statement, isn't very useful. We'd rather show you where
it broke than publish the inflated numbers.

Finding #3: the two things actually worth a second look

After filtering out test/dev noise, two real-code patterns remained that
we think are legitimately worth the maintainers' attention — not
confirmed vulnerabilities, just the exact shape of thing this category
of tool exists to surface:

• cloudflare/mcp-server-cloudflare, sandbox.container.app.ts: a file read and a file write both take a variable named reqPath directly into fs.readFile / fs.writeFile. We didn't trace the full call path to confirm whether it's constrained upstream — that's a five-minute check for someone who knows the codebase, which is exactly the point of flagging it rather than asserting it.
• notion-mcp-server, src/init-server.ts: reads a spec file from a path resolved at startup. Lower stakes — looks like a local config path, not something an agent's tool call controls — but same category.

Everything else that scored a CLEARED or a high number had, at most, the
missing-permissions finding from #1.

What this means if you're picking an MCP server today

Don't read the scores in the table above as a safety ranking — read
finding #2 first. A FLAGGED stamp from a heuristic tool like this means
"go look," not "don't install." Several of today's FLAGGED results
would be CLEARED if the tool only understood that a test directory isn't
a runtime path, which is a limitation of the tool, not the project.

Try it

npx mcp-customs scan ./path-to-some-mcp-server

Fully offline, zero telemetry, free, Apache-2.0. The rules and the
scanner itself are about 250 lines — read all of them in five minutes,
which is more than you can say for most security tools.

If you maintain one of the servers above and want help interpreting (or
arguing with) a finding, open an issue. If you maintain a different MCP
server and want to run this yourself before we do, that's the whole
point — we'd rather you find your own false positives than us find
them for you in public.