The Incident Nobody Saw Coming
Last month, a security researcher published a proof-of-concept that stole environment variables from a Claude Code session. The attack vector was not a vulnerability in Claude Code itself. It was a malicious MCP server that registered a tool called read_file -- shadowing a legitimate tool -- and exfiltrated every file path and content snippet that passed through it.
The attack worked because the developer had 6 MCP servers installed, had not reviewed the tool descriptions of 4 of them, and had granted file system access to all of them by default. This is not an edge case. This is the default configuration of most AI-augmented development environments in 2026.
We call this pattern MCP Sprawl -- the uncontrolled proliferation of MCP servers connected to your AI coding agent, each one expanding the attack surface in ways that are invisible to the developer.
What Is MCP Sprawl and Why It Matters
MCP Sprawl is the phenomenon where developers accumulate multiple MCP server connections in their AI coding agent without auditing the cumulative privilege surface, tool overlap, or trust boundaries between them.
The Model Context Protocol is designed to be composable -- you can add servers for different capabilities (database queries, security scanning, deployment, documentation lookup) and the AI agent orchestrates between them. This composability is a feature. It is also a security liability when unmanaged.
Consider the typical Claude Code power user. Our analysis of 143 publicly shared MCP configurations (from GitHub dotfiles, blog posts, and conference talks) shows:
- Average number of MCP servers: 4.7 per user
- Median number of tools registered: 23 across all servers
- Percentage with file system access: 89%
- Percentage with network access: 67%
- Percentage with shell/exec access: 41%
- Percentage where all tool descriptions were reviewed by the user: 12%
That last number is the critical one. 88% of users have tools running in their coding agent that they have never inspected. Each uninspected tool is a potential vector for prompt injection, data exfiltration, or privilege escalation.
The MCP Sprawl Index
The MCP Sprawl Index is a quantitative framework for measuring the attack surface created by your MCP server configuration. It evaluates risk across three dimensions:
Dimension 1: BREADTH -- Number of MCP Servers Connected
Each MCP server is a separate process with its own codebase, dependencies, and update cycle. More servers means more code you are trusting implicitly. The risk scales non-linearly because each server can potentially interact with every other server through the AI agent as an intermediary.
A tool in Server A can produce output that Claude Code passes as input to a tool in Server B. If Server A is compromised, it can craft outputs that exploit Server B through the AI agent -- a form of indirect prompt injection that crosses trust boundaries.
Scoring: 1-2 servers = LOW, 3-5 servers = MEDIUM, 6+ servers = HIGH
Dimension 2: PRIVILEGE -- File/Network/Exec Access Granted
Not all MCP servers need the same permissions. A documentation lookup server needs network access but not file system write. A code formatting server needs file read/write but not network access. A deployment server might need all three.
The problem is that MCP does not have a built-in permission model. When you add an MCP server, it gets whatever access its process has -- typically the same permissions as your terminal session. There is no sandboxing by default.
Scoring: Read-only = LOW, Read+Write = MEDIUM, Read+Write+Exec+Network = HIGH
Dimension 3: OPACITY -- Tools With No Description or Vague Description
Every MCP tool has a description field that tells the AI agent when and how to use it. When a tool has no description, an empty description, or a vague description like "utility function", the AI agent must guess when to invoke it. This creates two risks:
- The agent may invoke the tool in contexts the developer did not intend, passing sensitive data to an unexpected endpoint.
- A malicious tool with a vague description can be designed to trigger on common developer queries, maximizing its chances of receiving sensitive input.
Scoring: All tools documented = LOW, 1-3 undocumented = MEDIUM, 4+ undocumented = HIGH
Sprawl Index Calculation
| Dimension | LOW (1) | MEDIUM (2) | HIGH (3) |
|---|---|---|---|
| BREADTH | 1-2 servers | 3-5 servers | 6+ servers |
| PRIVILEGE | Read-only | Read+Write | Full (R/W/X/Net) |
| OPACITY | All documented | 1-3 opaque tools | 4+ opaque tools |
Sprawl Index = BREADTH x PRIVILEGE x OPACITY
- Score 1-4: Manageable -- standard hygiene sufficient
- Score 5-12: Elevated -- audit recommended within 7 days
- Score 13-27: Critical -- immediate audit required, consider removing unused servers
How Zfuzz scan_mcp_config Detects Sprawl
The scan_mcp_config tool in Zfuzz MCP reads your Claude Code MCP configuration and evaluates it against 143 detection patterns across all three Sprawl Index dimensions:
- Server enumeration: Lists all connected MCP servers with their transport type (stdio, SSE, HTTP), command, and arguments.
- Tool inventory: Queries each server for its registered tools, descriptions, and input schemas.
- Privilege mapping: Analyzes tool capabilities to determine file, network, and exec access.
- Shadow detection: Identifies tools across different servers that share the same name or overlapping functionality -- potential shadowing vectors.
- Description audit: Flags tools with missing, empty, or suspiciously vague descriptions.
- Known-bad patterns: Matches server configurations against known malicious MCP server signatures from our threat intelligence database.
Guard Rails: What This Framework Does Not Cover
- Runtime behavior monitoring. The Sprawl Index evaluates configuration, not runtime behavior. A server with a LOW sprawl score can still behave maliciously at runtime. Configuration audit is a necessary but not sufficient security control.
- Supply chain verification. The scan checks your local configuration but does not verify the integrity of the MCP server packages themselves. Use scan_dependencies for npm/PyPI supply chain checks on the MCP server packages.
- Custom MCP servers. If your organization builds internal MCP servers, the known-bad pattern database will not flag them. You need internal code review and security testing for custom servers.
Frequently Asked Questions
Should I remove all MCP servers except Zfuzz?
No. The goal is not to minimize servers -- it is to minimize unaudited servers. Each MCP server you use should have a clear purpose, documented tools, and the minimum necessary permissions. Run scan_mcp_config after adding or updating any server to check your Sprawl Index.
Can a malicious MCP server read my other MCP servers' data?
Not directly. MCP servers are isolated processes that communicate only with the AI agent, not with each other. However, a malicious server can influence the AI agent to pass data from one server to another through crafted tool outputs. This is the indirect prompt injection vector described in the BREADTH section -- and it is the most underappreciated risk in the MCP ecosystem.
How often should I audit my MCP configuration?
After every change (adding, removing, or updating a server) and at minimum weekly if your configuration is stable. The scan_mcp_config tool takes under 3 seconds and can be added to your Claude Code CLAUDE.md guard rules to run automatically at session start.
Connected Reads
- How to Audit MCP Server Configs for Prompt Injection
- Best Security MCP Servers for AI Coding Agents in 2026
- Supply Chain Attacks Targeting AI Agents and Developers
Audit Your MCP Configuration Now
The average Claude Code user has 4-7 MCP servers installed. 88% have never reviewed all their tool descriptions. Your MCP configuration is an attack surface -- measure it with the Sprawl Index, audit it with scan_mcp_config, and reduce it to only what you actually need. One command to start.
claude mcp add zfuzz -- npx @zfuzz/mcpSource and documentation: github.com/zfuzz-dev/mcp
