MCP tool presence suppresses subagent (Task tool) usage, halving throughput

[greynewell]

Problem

In our SWE-bench-verified evaluation (500 tasks), agents with the MCP server available almost never use Claude Code's Task tool (subagent spawning), while the baseline agent uses it heavily. This is the single largest contributor to the 7.4pp performance gap (42.4% vs 49.8%).

Data

Metric	MCP	Baseline
Task tool usage	2.4% of calls	76.4% of calls
Tool calls/iteration	1.01	1.74
Effective throughput	~1 action/turn	~1.7 actions/turn

The baseline agent spawns subagents (via Task) to parallelize exploration — reading multiple files, running grep searches, etc. — achieving 1.74 tool calls per iteration. The MCP agent calls tools almost exclusively sequentially (1.01 calls/iteration), even after fixing the agent prompt suppression issue (#123).

Root Cause

When MCP tools are present, Claude appears to treat them as the "preferred" exploration path, abandoning its natural pattern of spawning subagents for parallel exploration. The MCP tools (symbol_context) return rich results but are sequential — one call per turn in practice — while a single Task subagent can make dozens of internal tool calls.

Impact

Estimated +15-25 additional resolves if throughput matched baseline (from ~212 to ~227-237).

Possible Mitigations

1. Add explicit instruction in MCP server instructions encouraging Task tool usage for parallel exploration (e.g., "Use subagents to explore multiple files in parallel — MCP tools complement but don't replace native exploration")
2. Reduce MCP tool surface area so the agent doesn't feel it must route all exploration through MCP
3. Return actionable next-step hints in tool responses that suggest spawning subagents for broader exploration
4. Benchmark A/B test: Run a trial with instructions explicitly encouraging Task tool usage alongside MCP tools

Labels

performance, swe-bench