The 10,000-Server Problem: Vetting an MCP Server Before You Self-Host It

The official MCP registry is closing in on 10,000 servers, and most of them are unaudited code from people you've never met. Before you run one next to your AI, check five things: who maintains it, what permissions and secrets it wants, how it talks to the model, how often it's updated, and what happens if it goes rogue. Then contain it — least privilege, no Docker socket, locked-down network — so one bad server can't take the whole lab down with it.

Adding a new tool to Claude is almost too easy. You paste a line of JSON, run a quick npx or docker run, and suddenly your AI can read your calendar, poke your containers, or query your network gear.

Here's the part nobody puts on the sales page: that one line just handed a stranger's code a foothold right next to everything your AI can reach.

And there's a lot of that code out there now. The official registry is closing in on 10,000 servers, with roughly a thousand new ones showing up every month. Almost none of them have been security-reviewed by anyone. So the real question isn't "which MCP server looks cool this week" — it's "do I actually trust this one enough to run it in my lab?"

Quick note before we start: this is the companion to my earlier post on locking down your own self-hosted AI stack. That one is about securing the boxes you run. This one is about the harder problem — trusting other people's code before you let it in the door.

First, what can an MCP server actually touch?

Quick jargon check, because we'll lean on it the whole way down. MCP stands for Model Context Protocol — the open standard that lets an AI like Claude call external tools instead of just talking. If you want the full tour, I wrote a definitive guide to the Model Context Protocol. For today, the one-sentence version is enough: an MCP server is a little program that exposes "tools" the AI can call.

The catch is what those tools sit next to. To do anything useful, an MCP server usually holds real power: API keys and tokens, filesystem paths, sometimes the Docker socket, and network access to your LAN. That's not a bug — a GitHub server needs a GitHub token, a Docker server needs the socket. But it means the blast radius is large by default.

Think about the worst case. A server wired to your infrastructure could, in principle, restart containers, flip a firewall rule, or delete a volume. When a tool has that much reach, "is this safe to run" stops being a philosophical question and becomes a Saturday-night-outage one.

The sneaky part is that the AI can't tell a legitimate tool description from a malicious instruction hidden inside one. To the model, it's all just text. That's the gap attackers aim for.

The vetting checklist (before you run it)

You don't need a security team to do a decent gut check. You need about ten minutes and this list. Run through it before the server ever starts.

1. Source and maintainer

Open the repo. Is there a real commit history, a named maintainer, issues that actually get answered? Or is it a three-day-old fork with a suspiciously polished README? Prefer official servers (published by the vendor whose API they wrap) over random re-uploads. And watch the name carefully. The first known malicious MCP package, back in September 2025, was a fake postmark-mcp that reused the exact name of a trusted package to trade on the Postmark email service's reputation. It behaved normally for 15 versions, then one update quietly added a hidden BCC that copied every email it handled off to the attacker. Exact-name copycats and one-letter typosquats are both classic supply-chain moves — the repo's history and publisher are your first line of defense.

2. Permissions and scopes

Ask what the server actually wants access to, then ask if that makes sense. A weather server that needs your Docker socket is a giant red flag. Give every server the narrowest scope that still works — a read-only token instead of admin, one repo instead of the whole org.

3. Transport

MCP servers connect in one of two main ways. stdio means the server runs as a local process on your machine — the code executes on your hardware. Remote (HTTP/SSE) means you're talking to a server someone else hosts, which can see the prompts and data you send it. Neither is automatically bad, but a remote server you don't control deserves extra scrutiny: who runs it, and is the connection actually authenticated?

4. Secrets handling

Find out where your API keys land. Are they read from environment variables at runtime, or does the setup ask you to paste them into a config file that gets committed somewhere? Skim the code (or at least search it) for anything that looks like it phones home with your credentials.

5. Update cadence and pinning

An abandoned server with a two-year-old dependency tree is its own risk. But active updates cut both ways — a server can turn malicious in a version you didn't read. Researchers logged more than 40 CVEs against MCP implementations in just the first four months of 2026, and one analysis found command-injection flaws in roughly 43% of the servers it examined. The defense is boring and effective: pin versions. Don't auto-pull @latest.

Shadow MCP and the trust gap

Here's a threat that only shows up once you're running more than one server, and it catches people off guard.

Say you've got a trusted Gmail server loaded alongside a sketchy third-party one. The sketchy server's tool descriptions are just text that goes to the model — and that text can carry hidden instructions telling the AI to misuse the trusted Gmail tool. One poisoned server hijacking the behavior of a clean one is often called "shadowing," or Shadow MCP. You vetted the Gmail server just fine; the attack rode in on its neighbor.

Two cousins to watch for: a rug pull, where a server behaves perfectly until an update quietly changes what its tools do after you approved it, and schema or output poisoning, where the malicious payload hides in a parameter or a tool's return value instead of the description you actually read. The theme is the same — the danger sits exactly where you're not looking. With about a thousand new servers landing every month, plenty of sketchy ones ride in on the general hype.

Containment: assume one will go rogue

Vetting lowers the odds. It doesn't get you to zero. So run every third-party server as if it might turn on you, and make sure that when one does, the damage stops at its own four walls.

Least privilege first. Before any container tricks, give the server the smallest token and scope that lets it do its job. Most "MCP server did something awful" stories start with a credential that was way too powerful.

Contain the process. If a server ships as a container, don't run it wide open. The single most important rule: never mount the Docker socket, your SSH agent, cloud CLI credentials, or your home directory into it. Those mounts are how a contained problem becomes a whole-machine problem. A reasonable hardened baseline for an untrusted server looks like this:

# Run an untrusted MCP server with the guard rails up
docker run --rm -i \
  --user 1000:1000 \
  --cap-drop ALL \
  --read-only \
  --network none \
  ghcr.io/example/some-mcp-server:1.4.2

# What each flag buys you:
#   --user 1000:1000  -> run as non-root, not the default root user
#   --cap-drop ALL    -> strip every Linux capability
#   --read-only       -> no writable filesystem inside the container
#   --network none    -> no network at all (loosen only if it truly needs it)
#   :1.4.2            -> a pinned version tag, never :latest (rug-pull defense)

Lock down the network. If the server does need to reach out, default to denying all egress and allow only the specific hostnames it genuinely requires. That's what stops a compromised server from quietly shipping your data somewhere.

Put a gateway in front. Instead of pasting the same server configs into every client, route them through one place that enforces auth and access control — something like Cloudflare's zero-trust MCP portals or a self-hosted gateway. One choke point is far easier to reason about than a dozen scattered configs.

And start read-only. When I've written about using AI to help manage my home lab, the rule I keep coming back to is that write access is something you add on purpose, one capability at a time — never the default you back into.

Final thoughts

I lean on a local AI stack — Ollama, LiteLLM, and Open WebUI — and I use Claude constantly, so a shiny new MCP server tempts me just about every week. What keeps me out of trouble isn't paranoia. It's a bit of boring friction: read the repo, pin the version, hand it the least access that works, and box it in.

None of this is fearmongering. Most MCP servers are perfectly fine, built by people who just wanted to scratch an itch. The problem is that you cannot tell the fine ones from the dangerous ones by looking at a registry listing — and that registry is only going to keep growing.

So let it grow. Just don't let your trust be automatic.