MCP tools available in parent thread not accessible to plugin-defined subagents

Summary

MCP tools that are connected and working in the parent thread are not accessible to plugin-defined subagents spawned via the Agent tool. In our repro, the subagent received only the built-in file/shell tools — Read, Grep, Glob, Edit, Bash — regardless of what the agent definition's tools: frontmatter specifies, or whether that field is present at all. This suggests MCP availability is not being propagated to the subagent process/context.

Reproduction

Claude Code version: 2.1.84
MCP server: stdio-transport (lean-lsp alias, via uvx lean-lsp-mcp)

1. Configure an MCP server

Add to ~/.claude.json:

{
  "mcpServers": {
    "lean-lsp": {
      "command": "uvx",
      "args": ["lean-lsp-mcp"],
      "type": "stdio"
    }
  }
}

2. Create a plugin with an agent definition

Create a plugin containing an agent file at plugins/<name>/agents/my-agent.md:

---
name: my-agent
description: Test agent for MCP propagation
tools: Read, Grep, Glob, Edit, Bash, mcp__lean-lsp__lean_goal, mcp__lean-lsp__lean_diagnostic_messages
model: sonnet
---
List your available tools when asked.

Install the plugin so Claude Code loads it. On session start, confirm Claude Code recognizes the installed plugin agent and can dispatch it by name.

3. Confirm MCP works in the parent thread

In the Claude Code session, call an MCP tool directly — e.g. mcp__lean-lsp__lean_goal on a Lean file. This succeeds.

4. Dispatch the plugin-defined subagent

In the same session, immediately after step 3, ask Claude Code:

Dispatch a my-agent subagent with this prompt: "List every tool in your available tool set, one per line."

Claude Code generates this Agent tool call:

Agent(subagent_type="<plugin>:my-agent", prompt="List every tool in your available tool set, one per line.")

Expected

Subagent can access MCP tools available in the parent thread. When tools: is omitted from the agent definition (Run C below), the subagent should inherit MCP tools from the parent thread.

Actual

Subagent reports only: Read, Grep, Glob, Edit, Bash. No MCP tools are available.

Controlled experiment

To rule out the tools: frontmatter format as a factor, we tested three configurations. Each run was a fresh Claude Code session (full exit and relaunch between runs). In every run, the parent thread successfully called mcp__lean-lsp__lean_goal immediately before dispatching the subagent.

| Run | tools: frontmatter | Parent thread MCP | Subagent MCP | Subagent tools |
|-----|----------------------|-------------------|--------------|----------------|
| A | Short names (lean_goal, ...) | works | missing | Read, Grep, Glob, Edit, Bash |
| B | Prefixed names (mcp__lean-lsp__lean_goal, ...) | works | missing | Read, Grep, Glob, Edit, Bash |
| C | tools: field removed entirely | works | missing | Read, Grep, Glob, Edit, Bash |

Note: We only tested plugin-defined agents. We have not verified whether project-level agents (.claude/agents/) exhibit the same behavior.

Impact

This blocks any pattern where plugin-defined subagents need MCP tool access. As a concrete example, our Lean 4 plugin dispatches specialized subagents for proof-repair and proof-optimization that rely on LSP tools for iterative work. Without MCP propagation, these agents degrade to script-based fallbacks that are significantly slower and less capable.

Workaround

We pre-collect MCP results in the parent thread and pass them as text context in the agent prompt, then have agents use Bash for iterative validation (e.g. lake env lean File.lean instead of lean_diagnostic_messages). This works but loses the interactive MCP workflow that makes the agents effective.