I scanned the code of 25 MCP servers — the capability surface before you sandbox them

An MCP server isn't a remote API you call over HTTPS. For the stdio servers that make up most of the popular ones, npx some-mcp-server downloads code and runs it as a local process — with your shell's environment, your filesystem, and your network. Your agent then hands that process instructions.

That's a normal, useful design. It's also a capability surface nobody itemizes for you. So I measured it.

Method (static source scan — honest about its limits)#

I pulled 25 popular Model Context Protocol server packages and statically scanned the published package code (not runtime behavior) for four things:

• net-call sites — does the code make outbound network calls?
• secret-env reads — does it read credentials from process.env (e.g. process.env.API_KEY)?
• subprocess spawns — does it shell out / spawn child processes (exec_shapes)?
• bundled binaries — does the package ship a prebuilt binary?

Static scanning tells you what a package can reach for, not what it does on a given run. A process.env.API_KEY read is almost always the server loading its own credential — completely legitimate. The point isn't "these are malicious." The point is the aggregate surface you're granting, unseen, every time you add a server.

The capability surface, across 25 servers#

So a typical multi-server agent setup is running a dozen-plus local processes, most of which read your environment and make network calls, several of which can spawn subprocesses — all with the same privileges as the shell you launched them from. No install step surfaces this. No directory lists it.

Why this matters more for agents than for humans#

When you run a CLI tool, you roughly know what it does. When your agent connects a fleet of MCP servers and then acts in a loop, the blast radius is: every server's capability × the agent's autonomy × however many turns the loop runs. One over-scoped server, one compromised dependency in one of those packages, and the credential in process.env is one network call away from leaving your machine — and until recently a wildcard like *.amazonaws.com on an allowlist would have waved it straight through to an attacker-nameable S3 bucket.

You don't fix this by auditing 25 packages by hand every time you add one. You fix it by running the servers (and the agent) in a sandbox that constrains filesystem, egress, and secrets by default — so a server's capability stops being an authority.

That's exactly what enclave is: an Apache-2.0 sandboxed runtime for agents, with a default-deny egress allowlist, secret redaction, and a guard that blocks the sandboxed process from rewriting its own guardrails. Point your MCP-using agent at it and the capability surface above becomes something you grant explicitly instead of something you inherit silently.

And if you want the other half of the bill — the token context-tax those same servers add to every request (I measured a 544× spread, from 35 to 19,054 tokens/request) — that's tokenscope: npx @wartzar-bee/tokenscope.

Numbers are from a static source scan of 25 published MCP server packages; every count is reproducible from the package code. It's a lower bound on capability, not an accusation about any specific server's behavior.