Do I need to do all five checks for every MCP server I install?

The depth should scale with what the tool can actually do — a tool with real filesystem, network, or shell access deserves the full checklist; a narrowly-scoped tool with no dangerous capability surface is lower stakes. The checklist is there to help you decide how much scrutiny a given tool actually needs, not to demand maximum effort on everything uniformly.

Is running an automated scanner enough on its own?

No — see point 5. An automated scan is a real, useful signal, but the ~78% false-positive rate measured in independent testing means a scanner's output needs a human reading the actual evidence behind a finding, not a bare pass/fail treated as final.

MCP server security checklist

The specific things to actually check before you let a model call an MCP server's tools.

Last updated 2026-08-10

A real MCP server security check covers five things: the full raw tool definitions (not the client's shortened summary), what network/file/shell access each tool actually has versus what it claims, whether the package carries a real provenance attestation, how recently the project was actually touched, and whether the maintainer is a verified namespace or an anonymous one.

1. Read the full tool definitions, not the summary your client renders

Your MCP client shows you a shortened, human-friendly summary of each tool. The model reads the entire raw definition — name, description, and parameter schema, verbatim. Anything you're checking for tool poisoning has to be checked against the raw definition, since that's the only version that actually reaches the model.

2. Match declared capability against actual capability

A tool described as 'reads a config file' that actually has unrestricted filesystem write access, or a tool described as 'fetches a URL' with no host restriction at all, is a real mismatch worth stopping on — not because the description is necessarily malicious, but because permission scope that exceeds stated purpose is exactly the shape both tool poisoning and a badly-scoped legitimate tool share.

3. Check for a real provenance attestation, not just a namespace

A verified reverse-DNS namespace (the registry's own GitHub/DNS/HTTP challenge) proves the publisher controls that namespace — it doesn't prove the specific package version you're installing is what the publisher actually built. A Sigstore-backed npm/PyPI provenance attestation ties a specific published artifact to a specific repo, commit, and build workflow, which is the stronger claim: this exact package was built from this exact source, not substituted afterward.

4. Check freshness signals before trusting an old grade or review

See the companion piece on abandoned servers for the full signal set — commit recency, release recency, live endpoint status, contributor count. A security review or grade is only as current as the code it was performed against; check that the code hasn't materially changed since.

5. Treat scanner output as evidence, not a verdict

Pattern-matching security scanners for MCP servers carry a measured false-positive rate around 78% in independent testing — a flagged finding is a real thing to look at, not proof of a real problem. Read the actual finding and its evidence rather than trusting a pass/fail label alone, from any scanner, including aimcplist's own.

Related finding

~78%

measured false-positive rate from existing YARA-based MCP scanners.

Independent audit — see the full research roundup.