@jetpippo said something this week that's been rattling around my head: the real rug vector in 2026 isn't a token, it's your toolchain. Everyone's racing to bolt five more MCP servers onto their agent setup. Almost nobody's asking what those servers can actually reach, or whether the "weather-mcp" they npm-installed at 2am is quietly reading their .env file.
MCP servers are code you run with your credentials, your file system, and your API keys in scope. Most people install them the way they'd install a VS Code theme — click, trust, move on. That's the gap this week's picks are built to close.
1. Bumblebee (Perplexity)
This is the tool that kicked off the conversation, and it deserves the top spot. Bumblebee is Perplexity's scanner for MCP servers and their dependency trees, purpose-built to flag supply chain attacks — typosquatted packages, servers requesting scope way beyond their stated function, and dependency chains with recently transferred ownership (a classic pre-attack signal).
What makes it worth your time isn't novelty — dependency scanning has existed for a decade — it's that Bumblebee treats the MCP layer as a first-class attack surface instead of bolting MCP awareness onto a generic scanner after the fact. It understands what an MCP server's manifest is claiming to do and cross-checks that against what the code actually touches. That mismatch — "says it fetches weather data, actually opens outbound sockets to an unrelated host" — is exactly the kind of thing a human skimming a README will miss and a scanner won't.
It's new enough that community rule coverage is thinner than mature scanners like Semgrep. Treat it as one signal, not a verdict.
2. mcp-scan (Invariant Labs)
The other purpose-built MCP security tool worth knowing, and it's been around slightly longer than Bumblebee, so it has more real-world coverage of prompt injection and tool-poisoning patterns specific to MCP. Where Bumblebee leans supply chain, mcp-scan leans runtime behavior — it inspects tool descriptions and server responses for injection attempts aimed at the model, not just the host machine.
That distinction matters. A malicious MCP server doesn't need to steal your files if it can just convince Claude or GPT to do something harmful through a poisoned tool description. mcp-scan catches that class of attack that a pure dependency scanner walks right past.
Run both if you can. They're cheap, they overlap less than you'd expect, and MCP security is young enough that no single tool has full coverage yet.
3. MCP Inspector (Anthropic / modelcontextprotocol org)
The official debugging tool for the protocol, and it's underrated as a security tool specifically because nobody markets it that way. Inspector lets you connect to any MCP server and see, live, exactly which tools it exposes, what parameters each one accepts, and what it returns — before you wire it into an actual agent with real credentials.
The security use case: run a new server through Inspector first, in isolation, and actually read what it's exposing. Half the "surprising" MCP server behavior people report later was visible in the tool list the whole time — it's just that nobody looked before hooking it up to production.
4. Socket
Socket has been doing AI-assisted supply chain risk detection for npm and PyPI packages for a while now, and it's relevant here because most MCP servers ship as npm or PyPI packages under the hood. Socket flags install scripts, obfuscated code, and behavioral changes between package versions — the stuff that traditional vulnerability databases (which only catch known CVEs) miss entirely.
The GitHub App integration means it can block a PR that introduces a risky dependency before it ever merges, which is the right place to catch this — not after the server's already running in someone's agent.
5. Semgrep
The old reliable on this list, and it earns its spot for maturity, not novelty. Semgrep's static analysis rules can catch a lot of what MCP-specific scanners miss: hardcoded secrets, unsafe deserialization, command injection in the server's own code. It's not MCP-aware out of the box, but its OSS ruleset is large enough that pointing it at any MCP server's source before you run it is still worth the five minutes.
Mid take: don't reach for Semgrep first for MCP vetting specifically. It's a generalist. Use it as your fourth pass, not your first.
Worked example: vetting an MCP server before you install it
Say a teammate shares a GitHub link to a new "notion-mcp" server and wants to wire it into your agent stack today. Here's the actual sequence, five minutes, no hand-waving:
1. Clone it, don't install it globally.
git clone https://github.com/example/notion-mcp
cd notion-mcp
2. Run mcp-scan against the local checkout.
npx mcp-scan@latest scan ./notion-mcp
Look specifically for flagged tool descriptions — mcp-scan will call out language patterns known to be injection attempts.
3. Point Bumblebee at the same directory.
npx @perplexity/bumblebee scan ./notion-mcp --deps
This checks the dependency tree for typosquats and recently-transferred packages. If it flags a transitive dependency you don't recognize, stop and check npm view <package> maintainers before going further.
4. Fire up MCP Inspector and connect to it locally.
npx @modelcontextprotocol/inspector node ./notion-mcp/index.js
Read every tool it exposes. If it claims to be a "notes" integration but lists a tool called execute_shell, that's your answer.
5. Only after all three come back clean, install it with scoped credentials — not your main Notion token, a workspace-limited one if the API supports it.
Total time: under ten minutes. Compare that to the time you'll spend on incident response if step 3 gets skipped and a poisoned dependency exfiltrates your API keys.
Comparison: which scanner for which job
| Tool | Best for | Skip it if | |---|---|---| | Bumblebee | Dependency-tree supply chain risk | You need runtime/prompt-injection coverage — it's not built for that | | mcp-scan | Tool-poisoning and prompt injection in MCP responses | You want general code vulnerabilities — narrow scope by design | | MCP Inspector | Manual, human-reviewed inspection of what a server actually exposes | You need automated, CI-gate-able scanning | | Socket | Blocking risky deps at the PR stage across your whole repo | You only care about one-off MCP server vetting, not ongoing repo hygiene | | Semgrep | Deep static analysis of a server's own source code | You're time-constrained and just need a quick go/no-go |
None of these replace reading the code yourself if the server touches anything sensitive. They cut down how much code you need to read carefully, they don't eliminate the need entirely.
Common mistakes
Trusting star count as a security signal. A popular MCP server with 3,000 stars can still ship a compromised update next Tuesday. Stars measure adoption, not safety, and adoption is exactly what makes a project an attractive supply chain target.
Scanning once, at install, and never again. MCP servers get updated. A clean scan today says nothing about the version you'll be running after npm update next month. If you're not pinning versions, you're re-trusting the maintainer every single update.
Giving MCP servers broader credentials "to be safe" against future needs. The instinct is to grant a wide-scope API token so you don't have to reconfigure later. Do the opposite — scope credentials to exactly what the server's stated function requires, so a compromised server has a small blast radius instead of full account access.
Treating a clean scan as a guarantee. Every tool on this list has false negatives. Scanners catch known patterns; a genuinely novel attack can slip through all five. Layer tools, don't rely on one.
FAQ
How do I know if an MCP server is safe to install?
No single check gives you certainty. Run it through a dependency scanner (Bumblebee or Socket), a protocol-specific scanner (mcp-scan), and manually inspect its exposed tools with MCP Inspector before granting it real credentials. Treat all three as reducing risk, not eliminating it.
What's actually different about MCP security versus normal npm package security?
Traditional package scanners check what code does on disk — file access, network calls, install scripts. MCP servers add a second attack surface: the tool descriptions and responses the model reads and acts on. A server can be dependency-clean and still manipulate the model through a poisoned tool description, which is why MCP-specific tools like mcp-scan exist separately from general scanners.
Is Bumblebee free to use?
It's available as an open scanning tool you can run against local checkouts via npx, similar to how you'd run a linter — check Perplexity's repo for current licensing terms before running it in a CI pipeline, since usage limits and terms shift as these tools mature.
→ Ask the index what to build your mcp security stack
→ Free credits for these tools
Written by McKlaud AI. Want to know which AI tools actually fit your business? Get a free AI audit.