Allow MCP tools to be available only to subagent

[eli0shin]

I have MCP tools that I use with frequency that I do want generally polluting the context of every chat. Playwright is a great example where the main chat should be able to give instructions to a subagent to use the tools without polluting the context of the main chat with all of the playwright MCP tool calls.
The issue is that when I do this the playwright tools are still available to the main agent, but the main agent should never use these tools directly and they take up precious space in the context window.

This is a feature request to allow for configuring whether tools or entire MCP servers are available to the main agent while allowing them to be enabled for subagents.

[coygeek]

Hey,

This is a fantastic feature request, and something I've run into myself. It's a great point that specialized tools, especially verbose ones managed via MCP, can really clutter up the main agent's context when you only ever intend to delegate tasks to a subagent.

From my understanding of the current implementation, based on the Subagents documentation, a subagent's toolset is defined by the tools property in its configuration file. If that property is omitted, the subagent inherits all of the main agent's tools. If it's specified, the subagent gets a subset of the main agent's tools. There doesn't seem to be a way to do the inverse—to make a tool available exclusively to a subagent but hidden from the main agent.

Your point about preserving precious context space is the key issue here. Having all those Playwright tool definitions loaded for the main agent, which will never (and should never) use them, is inefficient.

I think a configuration flag for this would be the perfect solution. Maybe something in the claude mcp add command or within the .mcp.json file, like a flag subagentOnly: true. This would prevent the tool from being exposed to the main agent's context but would keep it available for any subagents that are configured to use it.

Definitely adding a +1 to this. It would be a huge improvement for building more complex, modular agentic workflows.

[leourbina]

+1 on this - I'm running into the exact same thing. I use the github MCP server for a reviewer subagent, however it consumes ~30k tokens, which is excessive for being constantly enabled. It would be great to just enable it for the subagent.

[zen0wu]

Big plus! This will make so much room for the main agents context window

[Layvier]

I think this is absolutely needed. Being able to fully control the initial context of subagents is essential in my opinion, MCPs are part of it

[attilaveres]

I've been trying to implement this on my own and I'm honestly surprised there's no support for it out of the box.

[msokolnickiitt]

This is one of the few missing features that I've realized is crucial after you introduced the /context command.

The /context command clearly shows how much unnecessary noise MCP tools add to the main thread when they're only needed for specific agents. Being able to configure MCP exclusively for agents would keep the main context
clean and focused, while still allowing specialized agents to leverage powerful MCP integrations when needed.

[andrewleech]

Without this feature I've found out better to avoid MCP integration entirely and focus on cli tools I can get an agent to train itself on (updating its own agent md file) to avoid filling the main Claude context window at all.

[mikewrather]

Without this feature I've found out better to avoid MCP integration entirely and focus on cli tools I can get an agent to train itself on (updating its own agent md file) to avoid filling the main Claude context window at all.

I've found this is a good stop gap approach. From the perspective of keeping the primary agent's context slim, it makes sense to load in specific documentation for cli / api usage within the sub-agent rather than to try and use mcp servers.

Sub-agent delegation is far more powerful and foundational than mcp servers, so the lack of this feature seems to pave over the mcp innovation entirely.

[kingsonlo]

I’ve been running into this as well when trying to use Claude Code with MCP tools. Specifically, I’m attempting to isolate a tool so that only a subagent has access to it. However, the main agent still ends up invoking the tool and polluting the context, which defeats the purpose of separating responsibilities between the main agent and subagents

[christophercolumbusdog]

Completely agree that this would be a highly impactful and desirable feature. Currently, I'm forced to choose between including an MCP that I only use occasionally but impacts my context, or not using the MCP at all. It would be pretty convenient if I could, say, restrict the Playwrite MCP to strictly a Frontend Tester agent and therefore limit the context pollution.

[cosinusalpha]

I need this, claude code becomes useless very fast when using playwright-mcp.