I scanned 50 MCP servers to see what they can actually do — here's what I found

One of the 50 MCP servers I scanned gives the LLM a full Python shell
on your machine. The tool is called execute_blender_code. The exec()
call has no builtin restriction. I verified it — imports, file reads,
subprocess execution all work.

That's what I built reachscan to find.

The problem

MCP servers aren't plugins in a sandboxed browser extension model. They
run as normal OS processes with your user permissions. If a server calls
subprocess.run(), the LLM can trigger shell commands. If it calls
exec() without restricting builtins, the LLM gets Python execution on
your machine.

Most people don't know which of the servers they're running fall into
which category.

What reachscan does

It's a static analysis CLI for Python and TypeScript/JavaScript agent
codebases. It maps seven capability categories:

The key distinction from a linter: reachscan tracks reachability.
A subprocess.run() buried in dead code is a different risk than one
called directly from a registered MCP tool.

Install it:

pipx install reachscan
reachscan https://github.com/any-org/any-mcp-server

False positive rate: 0.47% across a labeled corpus of ~3,900 findings.

The headline finding: blender-mcp

blender-mcp has a registered
MCP tool called execute_blender_code:

@mcp.tool()
def execute_blender_code(ctx: Context, code: str) -> str:
    """Execute arbitrary Python code in Blender."""
    blender = get_blender_connection()
    result = blender.send_command("execute_code", {"code": code})

That string travels over a local TCP socket to the Blender addon:

def execute_code(self, code):
    namespace = {"bpy": bpy}
    exec(code, namespace)  # ← line 431

Why namespace = {"bpy": bpy} doesn't protect you

This looks like a sandbox. It isn't.

When you call exec(code, namespace) without setting
namespace["__builtins__"], Python automatically injects the full
builtins module. I verified this:

namespace = {"bpy": object()}

exec('import os; print(os.getcwd())', namespace)
# → /home/user/...  ✓

exec('print(open("/etc/hostname").read())', namespace)
# → my-machine  ✓

exec('import subprocess; r = subprocess.run(["id"], \
capture_output=True, text=True); print(r.stdout)', namespace)
# → uid=1000(user) gid=1000(user)  ✓

The LLM doesn't just get Blender API access. It gets full Python
execution on the host.

The same primitive, done right

Finding exec() in a scan result doesn't automatically mean critical.
Two projects in this dataset handle it correctly:

awslabs/mcp — strips builtins before exec():

namespace['__builtins__'] = _SAFE_BUILTINS
# Removes: __import__, exec, eval, compile, open, getattr...

StarRocks MCP — validates the AST before eval():

validate_plotly_expr(plotly_expr)  # must be exactly px.<method>(...)
fig = eval(plotly_expr, {"px": px}, local_vars)

Same pattern. Very different trust boundary.

Results across 50 repos

• 1,139 findings across 18 repos with non-zero activity
• 1 in 3 repos has shell execution capability
• 1 in 4 accesses credentials from environment variables
• 10 of 50 had 4+ capabilities active simultaneously

The TypeScript gap

22 repos showed 0 capability findings — many are TypeScript-only.
reachscan detects TypeScript entry points (452 found) but doesn't yet
analyze TypeScript function bodies. "Clean" for a TS-heavy repo means
"no Python capability findings" — not verified safe.

TypeScript capability analysis is next.

Main takeaway

Adoption is moving faster than visibility. Treat MCP servers like
privileged code, not plugins. Audit tool boundaries before you deploy.

Try it on any MCP server or agent repo:

pipx install reachscan
reachscan https://github.com/any-org/any-mcp-server

GitHub: github.com/vinmay/reachscan

Full writeup with all 50 results and methodology:
Medium article