Skip to content
mcp/skillhub

Security hub · 2026-10-27

MCP security hub: how to audit a server, and the tools that help

An MCP server runs with your permissions, and its tool descriptions go straight into your model's context. Here is the checklist we use before installing one, what our checks found across 34,569 servers, and the security tools worth knowing, with what each one actually does.

By Ramachandra Vikas Chamarthi · Tool facts checked 2026-10-27 · Independent; not affiliated with Backslash, AWS or any third-party tool listed · Numbers update with each measurement run

Servers with security checks

34,569

Tool lists screened

10,781

Flagged for prompt injection

1

Repo doesn't match publisher

100

How to audit an MCP server before you install it

Most of it is reading. Steps 1, 2 and 8 come with what we've measured across the catalogue.

What you need: the server's package name or URL, a terminal with npm or uv, and for step 6, Docker running in a VM with no shared folders.

  1. 01 Check who published it
  2. 02 Read every tool description
  3. 03 Look for install scripts
  4. 04 Pin the version
  5. 05 Give it the narrowest credentials
  6. 06 Run it in a sandbox first
  7. 07 For hosted servers, check the host
  8. 08 Check it's maintained

1. Check who published it

In the official MCP registry, a name like io.github.alice/weather proves the publisher signed in as the alice GitHub account (or a member of that org), and com.example/* names are verified through the domain. The registry also checks the publisher owns the npm or PyPI package. It never checks the repository link: anyone can point at a popular repo. 100 registry listings link a repository that doesn't match their publisher; some are honest repackages, but we hide their stars either way. Compare the publisher, the package's maintainers and the repo owner. On PyPI, the project page shows the maintainers and whether a release came from a verified (Trusted Publishing) workflow.

npm view <package> scripts repository.url maintainers

2. Read every tool description

Tool names, descriptions and parameter schemas are usually sent to the model on every turn, and the model treats them as instructions. Read them before the server runs on your machine: on its MCPSkillHub page if we've measured it, or in the MCP Inspector pointed at the sandboxed command from step 6. Read them as the model would. Stop at anything that asks it to read files unrelated to the job, hide what it's doing, or change how other servers' tools are used. These are what our screening flagged:

What the tool text didServers
Tells the model to move or delete user data without asking1

That's 1 of 10,781 screened servers (0.01%). When we reviewed every flag by hand in October 2026, most were false positives: Persian text that uses zero-width joiners in ordinary spelling, an SSH tool mentioning ~/.ssh, a scanner describing the .env leaks it looks for. We tightened the rules and the table shows what's left. The real one asked the model to zip your project and upload it to a public file host without asking you. Rare, but one is enough, and tool text can change in any later version. Treat any scanner's flag, ours included, as a pointer to text you should read. The full review is in our tool-poisoning flags study.

3. Look for install scripts

npm runs preinstall, install, postinstall and prepare hooks before you ever start the server, and a Python source build runs setup.py. The command in step 1 prints the package's scripts. If there's an install hook, read what it does, or install with --ignore-scripts (with npx, set npm_config_ignore_scripts=true).

4. Pin the version

An unpinned npx -y package or uvx package can pick up a new version on a later start, so a server you reviewed can change under you, tool text included. Pin the version you read, and review again before you bump it:

claude mcp add files -- npx -y @modelcontextprotocol/server-filesystem@2.0.1 ~/projects
# PyPI: uvx mcp-server-fetch@2026.10.24

5. Give it the narrowest credentials

Read which environment variables it asks for. Use a token scoped to the job (read-only where you can, one repo or project rather than all), a database role that can't drop tables, and never your personal admin token. Assume anything the server can read, the model can be talked into sending somewhere.

6. Run it in a sandbox first

Start it with no network, placeholder secrets and no access to your files, and watch what it does. Our sandbox guide walks through it with Colima, or does it in one command.

7. For hosted servers, check the host

A remote server's code runs on someone else's machine, so there's nothing to sandbox. Check that the URL belongs to the vendor, read the OAuth scopes it requests, and read its tool list like any other. The MCP specification's security best practices cover what a well-built remote server should do, such as never passing your token through to other APIs.

8. Check it's maintained

Of the 34,569 servers with security checks, 390 have archived repositories, 1,031 have had no commits in over a year, 5,543 have no license, and 19,626 have no SECURITY.md telling you how to report a problem. None of these is a vulnerability, but an unmaintained server won't get a fix when one is found.

The best MCP security tools, by job

No single tool covers everything. Facts below were checked against each project's repository or docs on 2026-10-27. Tools marked ours are made by NavyaAI, the company that runs this site. Pin the scanners you run in CI too: they change like any other dependency.

Where each tool fits in an audit
  1. 01 · Before you install

    Look it up, read what the model will read

    • Backslash MCP Server Security Hub
    • MCPSkillHub server pages (ours)
    • MCP Inspector
    • OWASP MCP Top 10
  2. 02 · Before you trust it

    Scan tool text, configs and packages

    • Snyk Agent Scan (formerly MCP-Scan)
    • Cisco MCP Scanner
    • mcpskillhub CLI (ours)
  3. 03 · While it runs

    Limit what it can reach

    • ToolHive (Stacklok)
    • Docker MCP Gateway
    • vectra-guard (ours)

Scanners

Read a server's tools, prompts and config and flag what looks wrong. Run one before you install, and again when a server updates.

  • Snyk Agent Scan (formerly MCP-Scan). Finds the agents, MCP servers and skills configured on your machine and scans them for prompt injection and other issues. Invariant Labs' mcp-scan package now installs it. It sends tool names and descriptions, server configs and skill content to its API for analysis (its README says secrets are redacted first), and it starts stdio servers from your configs, so the README suggests a sandbox for untrusted ones. Needs: A Snyk account (SNYK_TOKEN). License: Apache-2.0.
    uvx snyk-agent-scan@latest
  • Cisco MCP Scanner. Scans stdio and remote servers (tools, prompts, resources, instructions), client config files, source and packages. YARA rules work offline; the LLM and Cisco AI Defense engines are optional. Needs: Nothing for YARA; API keys for the optional engines. License: Apache-2.0.
    uv tool install --python 3.13 cisco-ai-mcp-scanner
  • MCP Inspector. The official debugging UI. Not a scanner: it shows you exactly what the model will read (tools, prompts, resources), which is the part of an audit no tool can do for you. Run it against the sandboxed command, and keep it current: versions before 0.14.1 had a remote-code-execution bug (CVE-2025-49596). Needs: Nothing. License: MIT, moving to Apache-2.0. Its MCPSkillHub page.
    npx @modelcontextprotocol/inspector <command>
  • mcpskillhub CLI (ours). Installs a server with scripts off, starts it with no network in a VM that can't see your files, then reports its tools, the tokens they add per turn and any prompt-injection patterns. Needs: A Docker VM with no shared folders. License: MIT.
    npx mcpskillhub test <package>

Sandboxes and gateways

Limit what a server can reach once it runs. A scanner tells you what a server says; isolation limits what it can do.

  • ToolHive (Stacklok). Runs each MCP server in its own container with a permission profile, network isolation and encrypted secrets. A registry server lets a team curate approved servers. Desktop app and CLI. Needs: Docker or Podman (or Kubernetes). License: Apache-2.0. Its MCPSkillHub page.
  • Docker MCP Gateway. One endpoint for many servers, each started in a container. Keeps credentials in Docker's secret store instead of env vars, allowlists tools per profile, and logs calls. Ships with Docker Desktop's MCP Toolkit. Needs: Docker Desktop 4.59+ with MCP Toolkit, or Docker CE with profiles enabled. License: MIT.
    docker mcp gateway run
  • vectra-guard (ours). Guards the coding agent rather than the server: gates the shell commands it runs, scans dependencies for known CVEs before installs, and screens untrusted text with a prompt firewall. Needs: Nothing. License: Apache-2.0.

Ratings and references

Look a server up before you try it, and check your setup against a shared list of risks.

  • Backslash MCP Server Security Hub. A free, searchable database that rates MCP servers' security posture from vulnerabilities, exposure to attack vectors and provenance. Launched June 2025. Needs: Nothing; no login. License: Free web service.
  • MCPSkillHub server pages (ours). Every server we list shows its security checks with the evidence: tool-text screening on servers we could reach, plus repo hygiene, publisher and maintenance signals. Needs: Nothing. License: Free web service.
  • OWASP MCP Top 10. Ten MCP risks, from token mismanagement and tool poisoning to shadow MCP servers and context over-sharing. In beta, so treat it as a checklist rather than a standard. Needs: Nothing. License: Creative Commons (see the project page).

How we check every server

Each server's page shows its security score and every deduction behind it. Today the score covers tool-text screening on the 10,781 servers we could start or reach, and repository hygiene; the publisher-versus-repo check hides stars a listing hasn't earned. 34,046 servers score 85 or more (“no known issues found”), 518 score 70 to 84 (“minor findings”) and 5 score below 70 (“review before use”). A score is never a promise. Methodology has the weights, and the security ranking lists the top-scoring servers.

Looking for MCP servers that do security work, such as scanners, threat intelligence and pentest tools? They're in the security category.

Questions

How do I audit an MCP server?

Check who published it, read every tool description the model will see, look for install scripts, pin the version, give it the narrowest credentials it needs, and run it in a sandbox before your real machine. A scanner such as Snyk Agent Scan or Cisco MCP Scanner speeds up the reading, but doesn't replace it.

What are the best MCP security tools?

They do different jobs. Scanners (Snyk Agent Scan, Cisco MCP Scanner) read tool text and configs for injection and malware. Sandboxes and gateways (ToolHive, Docker MCP Gateway) limit what a server can reach. Ratings sites (Backslash's MCP Server Security Hub, and the checks on this site) help you choose before you install. Combine a scanner with isolation.

What is the MCP Security Hub?

Several projects use the name. Backslash Security runs the MCP Server Security Hub (mcp.backslash.security), a free database of server risk ratings. AWS has a Security Hub MCP app, a local server that lets an agent query AWS Security Hub findings. FuzzingLabs published mcp-security-hub, Dockerized MCP servers for offensive security tools, but its GitHub repository returned 404 when we checked on 2026-10-27. This page is an independent hub from MCPSkillHub and isn't affiliated with any of them.

How common is prompt injection in MCP tool descriptions?

Rare in what we've screened, but not zero. Our rules first flagged 14 of the 10,781 servers whose tool lists we could read; reading each by hand, 1 was a real concern (an instruction to upload the user's code to a public file host without asking) and the rest were false positives. One is enough, and tool text can change in a later version.

Is a server with a high security score safe?

No score can say that. A high score means our automated checks found little: at most minor repo-hygiene gaps. It doesn't prove what the code does with real credentials. That's why the checklist ends with a sandbox and least-privilege tokens.