The MCP You Connected Is Invisible to Your Spawned Agent

The MCP you connected in your main session is invisible to your spawned agent. An MCP is a plugin that gives an agent access to an outside tool, like Linear or GitHub.

You confirm Linear is wired in your orchestrator. You spawn a Claude sub-agent to do scoped work in a worktree. The first thing it reports back is that Linear MCP is unavailable. It then proceeds to infer the ticket scope from the prompt text you passed in.

This is not a bug. It is the design.

What actually propagates

In my setup, the orchestrator session has Linear, Neon, core file tools, and a Chrome MCP wired in. Spawned Claude sessions inherit a strict subset: core file tools, Neon, and Chrome. Linear does not cross the boundary.

That subset is not arbitrary. The line seems drawn around MCPs that hold read state safe to share across sessions, and it excludes MCPs that hold write state tied to a specific operator context. I have not found documentation that confirms this. The pattern is consistent across my runs.

The practical effect: a spawned agent cannot read your Linear tickets, your GitHub issues, your Slack threads, or anything else that lives behind an MCP you connected at the orchestrator layer.

Why text scope is the workaround

Because runtime context does not propagate, the only channel that reliably crosses the session boundary is text. The orchestrator has to extract the relevant scope from its own MCP access and pass it embedded in the prompt.

That extraction is real work. Before spawning, you or the orchestrator must:

Pull the ticket description and acceptance criteria from Linear.

Identify the file paths the work will touch.

Write the validation rules in plain text.

List the verification steps.

All of that gets pasted into the spawn prompt. The spawned agent treats that text as ground truth because it has nothing else.

Where this breaks

Text scope is brittle in three specific ways.

Drift. The orchestrator pulls scope at spawn time. If the Linear ticket gets updated mid-run, the spawned agent does not see the update. It is working against a snapshot.

Truncation. Long tickets lose detail when summarized. The spawned agent builds against the summary, not the source. If the summary omitted a constraint, the constraint might as well not exist.

No round-trip. The spawned agent cannot ask the ticket a question. If scope is ambiguous, it guesses. You see the guess in its decisions log, not in real time.

What I do about it

I treat MCP-bound context as orchestrator-only. Anything the spawned agent needs gets extracted into text before spawn, with explicit acceptance criteria and verification steps. Anything that needs live access to Linear, GitHub, or Slack stays at the orchestrator layer and gets handled there.

This is a stricter split than I would prefer. It is the only split that matches what actually propagates.

Verify it yourself

Spawn one sub-agent. Ask it which MCPs it can see. Compare that list to the MCPs in your main session. The gap between those two lists is the work you have to do at spawn time, every time, until the boundary changes.