Feature Request: Allow subagents (Agent tool) to access MCP server tools

Summary

When Claude Code subagents are invoked via the Agent tool, they do not have access to MCP server tools. Only the built-in tools (Read, Write, Edit, Bash, Grep, Glob, WebSearch, WebFetch) are available to subagents. All MCP tools — browser automation, cloud office suite integrations, custom MCP servers — are silently unavailable inside the subagent context.

Our Use Case

We run a multi-agent architecture with a team of specialized digital workers, each assigned a distinct domain (infrastructure, finance, legal, events, marketing, sales, etc.).

Each worker is invoked as a subagent via the Agent tool and assigned tasks from a central project management layer. The architecture depends on workers being able to interact with external services via MCP. For example:

• Browser automation MCP — form submissions, scraping, and UI testing
• Cloud office suite MCP — reading/writing documents, spreadsheets, calendar events
• Custom MCP servers — internal business process automation and data management

Current Limitation

When any worker is invoked as a subagent, they cannot call any MCP tool. The tools simply do not appear in the subagent's tool context. This means:

1. All MCP tool usage must be routed back through the top-level Claude Code session
2. The top-level session becomes a bottleneck — it must execute all external service calls on behalf of every worker rather than delegating
3. The delegation model breaks down: workers cannot independently complete tasks that require external service access
4. Orchestration code becomes complex — the PM layer must intercept every MCP call, context-switch back to the top-level, execute, and pass results back to the worker

Proposed Solution

Allow MCP tools to be passed through to subagents, with optional configuration to control which MCP tools each subagent can access.

Option A — Full passthrough (simplest): All MCP tools available in the parent session are automatically available to child subagents.

Option B — Scoped passthrough (preferred): Agent definitions can declare which MCP servers the worker is permitted to use:

# In agent frontmatter
mcp_servers:
  - browser-automation
  - office-suite

This would allow fine-grained control — each worker gets only the MCP tools relevant to their role. This maps naturally to the principle of least privilege and makes the worker permissions auditable.

Option C — Inherited with deny list: All MCP tools pass through by default, with an optional deny list per agent to restrict access.

Any of these options would significantly improve the viability of multi-agent architectures for real-world enterprise workflows.

Impact

Without MCP access in subagents, multi-agent Claude Code architectures are constrained to tasks that only require filesystem and shell access. External service integration — which is where MCP delivers the most value — can only happen at the top level, which defeats the purpose of having specialized workers.

This is particularly limiting for document-heavy workflows where every meaningful task involves reading from or writing to an external system via MCP.