Sub-agents spawned via Agent tool don't reliably inherit MCP tools (inconsistent with docs)

[sainikhil1705]

Summary

Sub-agents spawned directly via the Agent tool do not receive MCP tool access, even though the documentation states that sub-agents inherit all tools from the parent session (including MCP tools) by default.

Environment

• Claude Code version: latest (claude-sonnet-4-6)
• Platform: macOS Darwin 25.3.0
• MCP server: Atlassian (Jira)

Observed Behavior

Sub-agents spawned within a skill's execution context → ✅ MCP tools available (e.g. jira_get_issue, jira_search_fields, jira_create_issue — 17 successful MCP calls made)

Sub-agents spawned directly via the Agent tool (outside a skill context) → ❌ MCP tools not available. The agent reports only standard tools (Bash, Glob, Grep, Read, Edit, Write, etc.) and has no Jira/Atlassian tools in its tool list.

Reproduction Steps

1. Configure an Atlassian MCP server in Claude Code (~/.claude/settings.json)
2. Verify MCP is working (e.g. via a skill that uses Jira tools successfully)
3. Directly spawn a general-purpose sub-agent via the Agent tool:

   Agent tool:
     subagent_type: general-purpose
     prompt: "Call jira_get_issue with issue_key 'PROJ-123' and return the result"
   

4. Observe that the sub-agent reports no MCP tools in its available tool list and cannot make the call

Expected Behavior

Per the documentation:

Subagents can use any of Claude Code's internal tools. By default, subagents inherit all tools from the main conversation, including MCP tools.

Sub-agents spawned via the Agent tool should have access to the same MCP tools available in the parent session, regardless of whether they are invoked within a skill context or directly.

Additional Context

The inconsistency is specifically between:

• Skill-invoked agents → MCP tools ✅
• Directly spawned agents (via Agent tool in main conversation) → MCP tools ❌

This suggests the skill execution framework passes MCP context through correctly, but the direct Agent tool invocation does not.

[lucasilvano1]

Additional reproduction data — 3 scenarios with controlled tests

I ran into the same issue while trying to give MCP tools (Serena LSP, Context7 docs) to GSD workflow subagents. I set up 3 controlled tests that narrow down exactly when MCP propagation works vs. fails.

Environment

• Claude Code version: 2.1.72
• Platform: macOS Darwin 25.3.0 (arm64)
• MCP servers tested: Serena (LSP-based, stateful), Context7 (stateless docs), Figma, IDE

Test matrix

#	Flow	MCP tools available?	Details
1	Agent(subagent_type: "gsd-executor") — no skill context	NO	Only standard tools (Bash, Read, Edit, etc.). Zero mcp__* tools. Agent fell back to mcporter CLI bridge.
2	Skill("mcp-test-wrapper") → then Agent(subagent_type: "general-purpose") spawned from within skill	YES	All 49+ MCP tools available: mcp__plugin_serena_serena__* (27 tools), mcp__plugin_context7_context7__* (2), mcp__figma__* (15), mcp__ide__* (2). Serena activate_project + get_symbols_overview worked with persistent state across calls.
3	Skill("gsd:execute-phase") → orchestrator logic (reads workflow, runs CLI tools, analyzes JSON) → then Agent(subagent_type: "gsd-executor")	NO	Despite being spawned from within a skill context, the executor agent had zero mcp__* tools — same as Test 1.

Key finding: propagation depends on spawn depth/timing, not just skill context

Test 2 vs Test 3 is the critical comparison:

• Test 2: Skill loads → main agent immediately spawns subagent → MCP propagates ✅
• Test 3: Skill loads → main agent does intermediate work (reads files, runs bash commands, processes JSON) → then spawns subagent → MCP does NOT propagate ❌

This suggests the MCP context is available right after skill loading but gets lost after the main agent performs other tool calls before spawning the subagent. The intermediate orchestration work (even though it's still within the same skill context) breaks the propagation chain.

Reproduction steps for Test 2 (MCP works)

1. Create a minimal skill at ~/.claude/skills/mcp-test-wrapper/SKILL.md:

---
name: mcp-test-wrapper
description: Test MCP propagation
---
Spawn a general-purpose subagent that lists all mcp__* tools via ToolSearch.

2. Invoke: Skill("mcp-test-wrapper") → then Agent(prompt: "Use ToolSearch query='mcp__' and list results")
3. Observe: subagent has full MCP tool access

Reproduction steps for Test 3 (MCP fails)

1. From within a skill context, have the main agent do any intermediate work (e.g., read a file, run a bash command)
2. Then spawn a subagent
3. Observe: subagent has NO MCP tools

Impact

This blocks any orchestrator pattern (like GSD, or custom workflow skills) from giving MCP tools to executor subagents, since orchestrators inherently do intermediate work before spawning agents. The workaround of wrapping everything in a skill only works for the trivial case of immediate agent spawning.

Workaround (partial)

For stateless MCP servers (Context7, Perplexity), using a CLI bridge like mcporter works. For stateful servers (Serena LSP), there is no viable workaround — each CLI call spawns a new process, losing session state.