We scanned 12 popular MCP servers. The most interesting finding was our own false positives. A developer built mcp-customs, a free offline CLI that checks MCP servers for security risks before installation. Scanning 12 popular MCP servers revealed that 11 of 12 had zero permission or scope declarations in their manifest, and the tool initially produced false positives by flagging test code and comments as runtime issues. After filtering, two real-code patterns were flagged as worth maintainer attention. 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. We pulled the current top MCP-related repos on GitHub by star count and scanned each one as-is, no cherry-picking: | Server | Stars | Score | Stamp | |---|---|---|---| | github/github-mcp-server | 30.8k | 97/100 | CLEARED | | BeehiveInnovations/pal-mcp-server | 11.6k | 0/100 | FLAGGED | | firecrawl/firecrawl-mcp-server | 6.6k | 97/100 | CLEARED | | exa-labs/exa-mcp-server | 4.6k | 97/100 | CLEARED | | makenotion/notion-mcp-server | 4.4k | 29/100 | FLAGGED | | antvis/mcp-server-chart | 4.2k | 94/100 | CLEARED | | haris-musa/excel-mcp-server | 3.9k | 97/100 | CLEARED | | cloudflare/mcp-server-cloudflare | 3.9k | 0/100 | FLAGGED | | browserbase/mcp-server-browserbase | 3.4k | 22/100 | FLAGGED | | blazickjp/arxiv-mcp-server | 2.9k | 94/100 | CLEARED | | Jpisnice/shadcn-ui-mcp-server | 2.8k | 0/100 | FLAGGED | | stickerdaniel/linkedin-mcp-server | 2.4k | 94/100 | CLEARED | see below — these two scores don't mean what they look like they mean. 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. 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: tests/ or simulator tests/ — fake API keys used to test a shell=True call in a test for a security-audit feature. Runtime-code findings: execSync calls in a release-versioning script scripts/bump-version.js — not reachable by an agent, just a maintainer running npm version . 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. 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: 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. 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. 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. 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.