[BUG] Custom plugin subagents cannot access MCP tools (built-in agents can)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Custom subagents defined in Claude Code plugins cannot access MCP tools, regardless of how the tools field is configured in the agent definition. Built-in agents like general-purpose DO receive MCP tools, but custom plugin-defined agents do not.
What Should Happen?
When a custom plugin agent specifies MCP tools in its tools field (or omits the field to inherit), those tools should be available to the spawned agent, just as they are for built-in agents.
Error Messages/Logs
Steps to Reproduce
- Create a plugin with a custom subagent that needs MCP tools:
~/.claude/plugins/my-plugin/
├── .claude-plugin/
│ └── plugin.json
├── agents/
│ └── my-agent.md
└── skills/
└── my-skill/
└── SKILL.md
- Define the agent with MCP tools in
agents/my-agent.md:
---
name: my-agent
description: Agent that uses Playwright MCP for UI testing
tools: mcp__playwright__browser_navigate, mcp__playwright__browser_snapshot, Read, Grep, Glob
---
# Agent instructions here...
- Spawn the agent via Task tool:
Task(
subagent_type="my-plugin:my-agent",
prompt="Navigate to http://localhost:5173 and take a snapshot"
)
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.0.64
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Other
Additional Information
What I've Tried
| Configuration | Result |
|---------------|--------|
| tools: mcp__playwright, Read, Grep, Glob | MCP tools not available |
| tools: mcp__playwright__browser_navigate, ... (explicit full names) | MCP tools not available |
| Omitting tools field entirely (should inherit all) | MCP tools not available |
In all cases, the subagent reports that Playwright MCP tools are not in its available function list.
Evidence
The primary agent CAN use MCP tools directly:
mcp__playwright__browser_navigate("http://localhost:5173") // Works
mcp__playwright__browser_snapshot() // Works
But when the same tools are requested for a subagent, they're not provided.
Documentation Reference
From https://code.claude.com/docs/en/sub-agents:
MCP Tools: Subagents can access MCP tools from configured MCP servers. When the tools field is omitted, subagents inherit all MCP tools available to the main thread.
This does not appear to work for custom plugin-defined subagents.
Related Issues
- #2169 - MCP resources not available for subagents (different but related)
- #6915 - Allow MCP tools to be available only to subagent (feature request for inverse problem)
- #13254 - Background subagents cannot access MCP tools (confirmed:
run_in_background: falseis required)
Impact
This prevents creating specialized subagents for tasks like:
- UI testing with Playwright (isolating browser context from main conversation)
- Database operations via MCP
- Any MCP-based tooling in a dedicated context
Workaround
Use the built-in general-purpose agent type instead of custom plugin agents:
<invoke name="Task">
<parameter name="subagent_type">general-purpose</parameter> <!-- Works! -->
<parameter name="run_in_background">false</parameter>
<parameter name="prompt">Use mcp__playwright tools to test...</parameter>
</invoke>
This works because built-in agents receive MCP tools, but custom plugin agents do not.
15 Comments
Confirm I've also encountered this issue.
Is this gonna get respolved?
Also encountering this issue. It makes it very difficult to take advantage of using subagents for different tasks in plugins, particularly for context-heavy tasks such as using browser tools.
It would be great to have some response from the dev team on this...
I could confirm this is the case in version 2.1.20
I have the same issue. Managed to get working (with v2.1.22) by removing
tools:from agent file. Not the real solution but at least agents can use now MCP tools as they inherit configuration from CLAUDE.Additional Context from Related Investigation
While investigating LSP eager loading (#22335), I discovered this issue is part of a broader pattern of subagent/plugin context management problems.
Related Issues Filed
Workaround Confirmation
Can confirm the workaround mentioned in the original issue works:
Built-in agents receive MCP tools, custom plugin agents do not. This suggests the tool filtering logic handles built-in agents differently than plugin-defined agents.
Possible Root Cause
The tool injection for subagents appears to have two code paths:
The
toolsfield in plugin agent frontmatter may not be processed the same way as built-in agent tool lists.Update: Related issues now filed with full cross-links:
disable-model-invocationlike user skills doAll four issues point to systemic problems with subagent/plugin context management.
📊 Cumulative Impact Analysis
This issue is part of a broader investigation into subagent/plugin context management. Here's the full picture:
The Four Issues
Why This Issue Matters Most
The other issues are optimization - this one is functionality:
| Without this fix | Impact |
|-----------------|--------|
| Can't isolate MCP context | Browser state bleeds into main conversation |
| Can't create specialized agents | No DB agent, no UI testing agent |
| Workaround required | Must use
general-purposefor everything |Combined Session Cost
| Source | Tokens | Fixable? |
|--------|--------|----------|
| Subagent bloat (#22344) | ~66K | ✓ Optimization |
| Plugin overhead (#22345) | ~220K | ✓ Optimization |
| MCP workaround (this) | +~30K* | ✓ This fix |
| Total | ~316K | |
*Estimated extra tokens from using
general-purposeinstead of focused plugin agents---
Related issues: #22335, #22344, #22345
Adding a data point: I'm seeing this same MCP tool loss with a simple skill that does NOT use
context: forkor subagents.My setup:
~/.claude/skills/MyCustomSkill/skill.mdnameanddescription- nocontext: fork, no agent configurationclaude_desktop_config.jsonand works in Chat modeWhat works vs doesn't when skill is invoked:
| Tool Type | Available? |
|-----------|-----------|
| Built-in (Bash, Read, Write, Glob, Grep) | ✅ Yes |
| mcp__Claude_in_Chrome__* | ✅ Yes |
| mcp__mcp-registry__* | ✅ Yes |
| mcp__coda__* | ❌ No |
The pattern:
/vivskill): Coda MCP ❌This suggests the bug may be broader than subagents - simple skill injection also loses us
[memo written by MyCustomSkill]
Has anyone tested if this fix in 2.1.30 resolved this issue?
_Fixed subagents not being able to access SDK-provided MCP tools because they were not synced to the shared application state_
I'm also encountering this bug.
Maybe claude code could use a bit of a refactor. Plugins seem like the best place to start over from.
Confirmed fixed in
@anthropic-ai/claude-agent-sdk@0.2.63(Claude Code 2.1.30+).We tested this with a standalone program that:
type: "http",url: https://mcp.atlassian.com/v1/mcp)toolsincludingmcp__atlassian__*Result: Both returned identical, real Confluence data. The custom subagent successfully called MCP tools — no hallucination.
The key requirements:
toolsconfiguration (e.g.,mcp__atlassian__*)This answers @rlichtenwalter's question — yes, the fix in 2.1.30 does resolve this issue.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.