Topic: mcp server security review

MCP server security review — what one looks like, who does them, how to get one

If you've published an MCP server and you're trying to figure out what a "security review" actually means in 2026 — what gets checked, who does the checking, what the deliverable looks like, and how long it takes — this is a buyer's-side map of the territory, drawn from SkillAudit's review of 101 of the most-installed servers.

TL;DR

An MCP server security review in 2026 is a structured pass over six axes — security findings, permissions hygiene, credential exposure, maintenance signal, client compatibility, documentation completeness — that produces an A–F grade plus a per-axis findings list with file paths and line numbers. Three actors do them: Anthropic's Skills Directory team as a listing prerequisite (criteria not public, queue measured in weeks), large security vendors as a custom services engagement (CodeQL/Semgrep customizations; counted in days and thousands of dollars), and MCP-aware scanners like SkillAudit that produce the report automatically from a GitHub URL in around 60 seconds. Run an audit on a real repo if you want to see the deliverable directly.

What people actually mean by "MCP server security review"

The phrase resolves to one of three intents in our inbound, and the right answer is different for each:

Author preparing for the Anthropic Skills Directory. The 2026 listing process now requires a security review before public listing. The criteria are not published. The author needs a pre-flight signal that gives them confidence the submission won't bounce.
Buyer evaluating a community MCP server before install. A team lead is about to claude plugin install a community-maintained server into a production agent and wants a third-party signal — "is this safe to adopt?" — that doesn't depend on whoever happened to star the repo.
Internal review process. A security team at a 50–500 person organization is writing the policy that decides which MCP servers are allowed in. They want a reproducible review template they can apply themselves, with criteria they can defend.

All three lead to the same six-axis surface, but the deliverable shapes differ. Authors want a public badge. Buyers want a deep report with remediation hints. Internal-policy teams want a control framework they can map to. We cover what a good review delivers for each below.

The six axes a real review covers

This is the surface SkillAudit has converged on through 101 audits and three engine revisions. It is what we mean by "complete review"; named external reviewers tend to cover a strict subset.

1. Security findings

Static analysis plus LLM-assisted probing for the threat classes that show up in MCP-shaped code: SSRF (the most common: 50% of our corpus had at least one finding), command-exec from tool input (10%), path-traversal in file-read tool handlers, SQL injection in DB-shaped servers, SSRF-via-redirect. The hard part isn't the obvious cases (fetch(url) with no allow-list); it's the dynamic-base patterns (fetch(`${baseUrl}/${path}`)) that default SAST rule sets miss. Output: per-finding file:line, severity, and remediation hint.

2. Permissions hygiene

What permissions does the server ask for, and are they all used? An MCP server that registers a read_secrets tool but only ever calls kubectl get pods in its handlers is over-privileged. We trace declared tool surface against actual handler implementations and flag the gap. Useful signal for buyers because over-broad permissions correlate with audit fatigue and future incidents.

3. Credential exposure

Are environment variables or secrets read into tool responses? Are tokens echoed in error messages? Is the auth header logged? 38% of our corpus had at least one credential-handling finding. The deepest example is in the anatomy-of-a-credential-leak post — a dynamic-base fetch with a static Authorization header that, redirected to an attacker-controlled server, leaks the token. Static rules alone underflag this; an LLM-assisted pass closes it.

4. Maintenance signal

Last commit date, open-issue ratio, advisory-feed status, archived flag. Not a security vulnerability per se, but a strong predictor — an MCP server that hasn't shipped in 14 months and ignores 12 issues is unlikely to fix the SSRF you just found in it. Nine archived MCP servers in our corpus tells the story; archived status alone is enough to fail the maintenance axis.

5. Client compatibility

Does the server work on the major MCP clients — Claude Code, Cursor, Windsurf, Codex, JetBrains, the VS Code extension — and which protocol versions does it pin to? Compatibility drift is silent and breaks installs in the field. A complete review flags pinned-version risk and notes any client where the server has been observed to fail.

6. Documentation completeness

Runnable example, semver-versioned releases, an explicit security-contact channel, env-var documentation. A server that fails this axis isn't necessarily insecure, but it is harder to operate safely — buyers and incident responders both depend on documentation that reflects the actual surface. Combined with the other five axes this anchors the A–F overall grade.

The methodology and scoring rubric are public on the methodology page. We list known limits there too — what static catches, what only LLM-assist catches, what nothing catches yet.

Who performs MCP server security reviews in 2026

Anthropic Skills Directory team

The official directory listing process now includes a security review step before public listing. The published criteria are short; the actual gate is opaque to authors. Lead time has been measured by listed authors in weeks. There is no third-party way to pre-flight a submission, which is a major reason indie authors are publishing badges before applying — a signal they can put on their README to argue the case to the reviewer.

Large security vendors (custom-services route)

Snyk, Veracode, GitHub Advanced Security, and a handful of boutique pentest firms will perform a security review of an MCP server as a custom services engagement — typically by writing CodeQL or Semgrep custom queries against it, or by spinning up a manual code review. The output is a finding list, often a CSV. Lead time: days. Cost: low four figures, sometimes high five if the engagement scopes the surrounding stack. This is the right path for a 100-server installation in a regulated environment; it is over-procured for a single-author indie skill.

MCP-aware scanners (automated, software-services route)

SkillAudit is the most-developed of these in 2026. Paste a GitHub URL or upload a ZIP; the engine runs the six axes; you get the A–F card and per-axis finding list in around 60 seconds. Free tier: 3 audits/month on public repos, public badge, basic report. Pro ($19/mo): unlimited public + private, full report, history, GitHub Action. Team ($99/mo): Pro for 10 seats, SSO, policy export, SBOM, audit log. The right path when the scope is this one server rather than our whole estate; complementary to a vendor engagement, not a replacement for it in regulated contexts.

Self-review

A security-aware developer can do the first five axes manually with about a day of effort: SSRF and command-exec by reading every tool handler against the input-trust model; permissions hygiene by diffing declared vs. used tools; credential exposure by greping for process.env reads in response paths; maintenance signal by reading the issue tracker; client compatibility by running the server against each named client. The trade is consistency — manual reviews vary by reviewer; automated reviews are reproducible across releases. We publish the rule set partly so self-reviewers can use the same checklist.

What a SkillAudit review looks like — sample shape

Examples in the public audit corpus. The deliverable for any single audit is:

An overall grade: A, B, C, D, or F. The grade distribution across our corpus runs roughly 19% A, 22% B, 11% C, 6% D, 42% F — heavy at the tails because most servers either get this right (clean, narrow surface) or get it visibly wrong (SSRF + credential echo combined).
A per-axis sub-grade. A server can earn an A on documentation and an F on credential exposure; the overall grade is bounded by the worst axis. This forces the report to be honest about what it failed at, not just the headline.
A findings list. File path, line number, severity, finding class, remediation hint. Linkable. Embeddable in a PR comment.
A public badge. A small SVG that authors can drop in their README. Links back to the full report. Updates automatically when the server is re-scanned. Same idea as Snyk's vulnerability badge or Coverage's shields.io badges, scoped to MCP.
A re-audit endpoint. Hit it on every release and the badge stays current; also exposed as a GitHub Action that fails PRs below grade B.

For Pro tier additions: full per-finding remediation prose (not just the hint), the LLM-probe transcript so the prompt-injection axis is auditable, and the CI webhook with policy export.

How to get one — three paths

If you're an author preparing for an Anthropic listing: run a SkillAudit on the GitHub URL of your server. Embed the badge in the README before submitting. The listing reviewer is unlikely to publicly endorse the badge but the data behind it is exactly what they're looking at, and the act of publishing it tells them you have run the review yourself. We publish the methodology so the score is defensible — you can point at the rule set if asked.
If you're a team buyer evaluating a community server: run the audit on its public GitHub URL (free tier covers public repos). If it's grade B or higher and you're past the conviction threshold, install. If it's C or below, decide whether the missing axes matter to your use — for example, a B+ install gate is a defensible default for production, with explicit waivers for known-good D-grade utilities.
If you're standardizing internal policy: use the six-axis surface as your control framework. Map each axis to a control-objective ID. Use the Team plan's policy export to enforce the gate in CI. Subscribe to the methodology-changes RSS so your policy reflects the latest engine revision. The framework runs in CI; humans review the deltas, not every audit.

Run an audit

Common red flags in MCP server security reviews

The patterns that earn an immediate F across the corpus we've reviewed:

Unbounded fetch from tool input — fetch(args.url) with no allow-list, no IP-block check, no protocol restriction. This is the one finding type that is both the most common (50% rate) and the easiest to fix (10 lines of allow-list code).
Credential echo into tool response — return { content: [{ type: 'text', text: `Token: ${process.env.X}` }] } in any path, even an error path. The worst variant is the dynamic-base fetch with a static Authorization header, which leaks the token via redirect.
Shell exec from string concatenation of tool input — exec(`git log --format='%H' -- ${args.path}`). Even with sanitization that handles spaces and quotes, this class fails the review by default; execFile with array arguments is the fix.
Tools registered but never implemented — declared surface that doesn't match the handler set. Frequently a permissions-hygiene fail and a documentation fail simultaneously.
Archived repository — automatic maintenance F. Combined with any other finding, this triggers an overall F because there's no remediation channel.

Every one of these has a corpus example called out by name in the vendor-official MCP F-grades post or the credential-leak post. The deep dive on the A-grade pattern set is in the anatomy of an A-grade MCP server.

How long does a review take, and what does it cost?

Three reference points:

Self-review: 4–8 hours for a small server, full day for a moderately complex one. Cost: time. Quality: variable.
Vendor engagement: 3–10 business days, $1,500–$15,000 depending on scope. Quality: depends on whether the vendor has MCP-shaped rules, which today most do not by default.
SkillAudit: ~60 seconds for a public repo, basic report free, full report on the $19/mo Pro plan. Quality: bounded by what static + LLM-assist can prove; that bound is documented and the calibration set is published.

The right answer for most authors and most adoption decisions is the automated one. Vendor engagements remain the right answer when the surface includes more than the MCP server itself (a whole agent platform, a supply chain, a regulated estate) or when a regulator asks for a named-firm signature.