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
| Capability (code contains…) | Servers | of 25 |
|---|---|---|
| A network-call site | 17 | 68% |
Reads a secret from process.env
|
16 | 64% |
| A hardcoded outbound host reference | 12 | 48% |
| Spawns a subprocess / shells out | 8 | 32% |
| Ships a bundled binary | 4 | 16% |
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.
Top comments (0)