Implement Agent-Scoped MCP Configuration with Strict Isolation

[btebbutt]

Custom subagents should be decoupled from main agent

Expected behavior

• It should be possible to configure a sub‑agent with MCP servers in non‑inheriting mode such that:
• The main thread does not list these servers in /mcp.
• The main thread cannot call their tools/resources (they appear unknown).
• Only the owning sub‑agent materializes/uses those servers during its lifecycle.

Actual behavior
Any MCP server configured via global scopes is enumerable and callable from the main thread, even if operationally intended for a specific sub‑agent.

Every tool description is another thing for the main agent to manage and potentially degrade performance and is counter intuitive to what the docs mention as a key benefit 'Context preservation'. Please support agent‑scoped MCP configuration with explicit non‑inheritance and hard isolation.

Environment Info

• Platform: linux
• Terminal: vscode
• Version: 1.0.61
• Feedback ID: 68fb84e4-5930-4edc-9263-22704b94ecda

[rinormaloku]

I'm just verifying that we're discussing the same issue. You want MCP Servers that are scoped for a single agent. such as shown below

claude mcp add --scope agent=my-superduper-agent ...mcp server details

Then only the my-superduper-agent has access to the tools of that mcp server?

[btebbutt]

I'm just verifying that we're discussing the same issue. You want MCP Servers that are scoped for a single agent. such as shown below

claude mcp add --scope agent=my-superduper-agent ...mcp server details

Then only the my-superduper-agent has access to the tools of that mcp server?

That's right. But pivotally the main thread / agent who not only can't use it but has no knowledge it exists.

Right now the main agent has to be exposed to every mcp added which I don't want.

This isn't permissions either , it should simply have no knowledge of the mcp.

[musnows]

I also have a similar need, I hope that a certain MCP tool will only expose subagents to avoid the main agents being misled by these MCP tools.

Currently, the alternative solution I can think of is to create a sub-agent that doesn't inherit specific MCP tools, and directly specify in the main agent to let this sub-agent work in place of the main agent. But it seems like subagents cannot create another subagents? (no Task tool)

[JonCrawford]

This could also be accomplished by allowing users to set any agent as the primary agent when they start Claude. With that agent having its own tool scope in its config.

[michabbb]

this should work without any changes to the primary agent. any sub-agent should have its own MCP config, so the context window of the main agent does get filled out with stuff the main agent never uses. if you then start claude with any specific agent, that´s up to you.

[OmniZenRaj]

I agree that configuring MCP Servers agent level (with current support for tool limits) would be a great way to control context size issues.
The main CC system should not be aware of any agent scoped MCP servers due to how much context they use up even when they are NOT being used (just to setup config).

[btebbutt]

I agree that configuring MCP Servers agent level (with current support for tool limits) would be a great way to control context size issues. The main CC system should not be aware of any agent scoped MCP servers due to how much context they use up even when they are NOT being used (just to setup config).

yes exactly the whole purpose of subagents is to help with context control. MCP tool call descriptions take up a significant amount of context every single session when this simply should be optional / possible to offload to a specific subagent.

[damusix]

You can also make agents scoped to specific mcps and specific tools for those selected mcps. This way, for example, a typescript agent will only have access to context7 and playwrite, while a sql agent has access to only database read queries—whatever the user defines.

Similar to the allowed tools options.

[dwayn]

I'm just verifying that we're discussing the same issue. You want MCP Servers that are scoped for a single agent. such as shown below

claude mcp add --scope agent=my-superduper-agent ...mcp server details

Then only the my-superduper-agent has access to the tools of that mcp server?

I would also like to suggest the ability to add an mcp with an empty agent scope so that it can be added, but no agent picks it up for use right away.

claude mcp add --scope agent   ...mcp server details

Then in the agent config menu (from /agents in CC), add a the ability to turn on/off each of the mcp servers that are either available to the main agent or in the pool of agent scoped mcp servers.

Also, I am a really big fan of the idea of being able to switch persona to that of any agent you have defined as others have mentioned...so many times I have wished I could interactively work with a configured agent.

[christopher-buss]

As long as the main context thread has an idea of what each MCP should be used (some context), then they don't need to necessarily have the full context of every MCP and what the full details are, they would then be able to delegate to subagents who could have the full MCP context. This would allow us to have many MCPs that can be useful in niche cases, without fully polluting the scope. I downloaded a few useful common MCPs and ended up with 40k context used in MCPs! I removed the ones that are more niche use case, but I still would like to have access to them on occasion.