Introducing MCP Inspector: Know an MCP Server’s Risks Before You Install It

We found the risks. Now we’re giving you a way to inspect them yourself.

Over the past few weeks, We’ve been running Operation: MCP, our deep dive into the risks hiding inside MCP server adoption. We’ve found widespread use, limited visibility, and serious vulnerabilities in popular servers used by millions of users.

Below, we’ll explain what pushed us to build it, what the scanner checks, how it works, and how the same research extends from one MCP package to an entire enterprise environment.

Why We Built It

Operation: MCP started with an article covering adoption data from our customers’ environments in which we’ve showed how the ecosystem is more widely deployed than most teams assume.

Then we started taking the popular servers apart, and published what we found –

• CircleCI’s MCP server142,000+ npm downloads a monthA fileName parameter went unquoted into shell commands that CircleCI then executed, and the HTTP endpoint validated neither Host nor Origin, so any site a developer visited could drive it. Together that means arbitrary commands running inside the victim’s CI pipelines, with access to build secrets and the ability to tamper with what ships. This allows attackers to ship code on your behalf.
• jupyter-mcp-server400K+ PyPI downloads · 14K Docker pullsUnauthenticated /api/connect and /api/stop routes let anyone repoint it at a backend of their choosing, and the same missing validation left it reachable from a web page through DNS rebinding. A page in a browser tab was enough to move a developer’s notebook session onto attacker infrastructure, where the code they thought was running locally ran instead, and the output came back trusted. The results on your screen may never have come from your machine.
• Apify’s official MCP serverPast 100,000 monthly users in July 2026A page the agent had simply been asked to read could make it issue a second, authenticated request to a destination its user never named. That turns reading a web page into an authenticated action on the victim’s account: wasted paid compute, interference with live automations, and a route out for whatever sensitive data is already in the conversation. Your agent ends up working for the page it just read.

Different servers, different bugs, one outcome. Each of these puts a user’s endpoint within reach of an attacker who never had to steal anything, because the server already holds the credential and will use it for whoever asks.

And the problem was never one bad package. It is the aggregate. Someone installs a server to speed up a task, it works, and it stays. No ticket gets filed, nobody owns it, and it never appears in any of the inventories the organization owns. Repeat that a few hundred times per environment and the result is unvetted code, running on endpoints, holding credentials, wired into systems that matter, that nobody inside the company has ever read or approved.

What the MCP Inspector Tells You

The MCP Inspector gives you a verdict on an MCP server before you run it. That tells you what you are about to install, while you can still change your mind.

For every server you submit, you get the risks we found, the evidence behind them, and where in the package each of them lives. Not a score with nothing behind it but the actual code path, so you can judge it yourself or hand it to whoever owns the decision.

How It Works and What It Checks

Submit an MCP server’s npm package id. The scanner pulls the published package and runs the same analysis engines we use internally: a deep read of the code, the paths through it, and the exposure it creates for anyone who installs it.

Those engines are built on the research above. Every vulnerability we confirm becomes a detection, and every scan across our customers’ environments turns up more of them. The scanner reports on three categories, each one a vulnerability class we found and disclosed in the wild:

We are glad to be able to put this in the hands of the people actually running these servers.

From One Package to Your Whole Environment

The MCP Inspector answers one question about one package. Pluto runs those same engines across everything at once, and the full analysis reaches further into the code:

• Command injection
• Path traversal
• SSRF
• Credential exposure
• Tool metadata integrity
• Data exfiltration paths
• And more

It also runs continuously across the organization: every MCP server your people are running, which endpoints are running it, what each one is connected to, and what changed this week. That includes the servers your own developers stood up and moved on from, still listening, still holding a credential, waiting for someone to knock.

If your team is running MCP servers, self-hosted or otherwise, and wants someone to verify everything’s under control, book time with us and we’ll show you what we’d find in yours.