Digital Strategy Review | 2026
Claude Code Top 10 Highlights 07 | Agent-Specific MCP: Assigning Capabilities by Role, Not Dumping All Peripherals on the Main Model
By Uncle Fruit · Reading Time / 8 Min
Foreword
Everyone has been integrating MCP (Model Context Protocol) over the past few years, but the real challenge isn’t “can you connect it,” but rather how to avoid capability bloat once connected. This article aims to clarify why Claude Code chooses to distribute external capabilities by role rather than dumping everything onto the main model at once.
01
Agent-Specific MCP: Assigning Capabilities by Role, Not Exposing All Peripherals to the Main Model
MCP is no longer a novelty. However, Claude Code has a noteworthy approach: MCP capabilities do not belong solely to the main session; they can be mounted incrementally based on the Agent’s role.
The core implementation of this highlight lies in:
• src/tools/AgentTool/runAgent.ts
• initializeAgentMcpServers(...)
02
I. Common System Issues: Dumping All Capabilities on the Main Model
When many Agent systems integrate MCP or tool extensions, the typical approach is:
• Connect all external capabilities.
• Expose everything to the main model.
• Let the main model decide when to use them.
The biggest drawbacks of this approach are:
• High noise in the tool surface.
• Overly broad permission scope.
• Difficulty for sub-roles to maintain focus.
• Certain capabilities are only suitable for specific tasks but remain exposed indefinitely.
Claude Code is clearly not satisfied with this.
The focus of Claude Code is not “how many MCPs are connected,” but rather which capabilities should be assigned to whom.
03
II. The Strategy: Capabilities Can Be Mounted Upon Agent Startup
In Claude Code, an Agent definition can include mcpServers.
Consequently, when an Agent starts, the runtime will:
01 Check if it has declared agent-specific MCPs.
02 Connect to these servers.
03 Fetch the tools.
04 Merge these tools with the parent context’s tool surface.
05 Clean up the necessary connections when the Agent terminates.
This demonstrates that Claude Code treats MCP not just as a “global system capability,” but also as a “role-level capability extension.”
04
III. Why This Is Advanced
1. Precise Binding of Roles and Capabilities
If an Agent is dedicated to a specific type of analysis or external operation, it can mount the corresponding MCP only when it starts.
This is far superior to “always exposing all tools” because it is:
• More focused.
• More token-efficient.
• Less prone to misuse.
• Better for permission governance.
2. No Need for the Main Session to Pre-load Everything
Many capabilities are only used by specific Agents. If everything were pre-loaded in the main session, it would waste context and increase complexity.
Claude Code’s design essentially says:
Capabilities can be assembled on-demand, rather than being laid out all at once at startup.
3. It Gives Agent Definitions True “Resource Dependency” Semantics
In the previous article, we mentioned that Agent definitions are more like runtime specs. Agent-specific MCP is one of the aspects where this spec most closely resembles a system configuration.
It describes not only “how to think” but also “which peripherals to connect to at runtime.”
05
IV. Mature Distinction Between Shared and New Clients
Another mature aspect of initializeAgentMcpServers(...) is the distinction between:
• Servers referencing existing configurations by name.
• New servers defined inline within the Agent.
It only cleans up those “newly created, agent-private connections.”
This shows that the author has a clear understanding of resource lifecycles:
• Do not accidentally clear shared resources.
• Reclaim temporary resources when the agent finishes.
These details resemble system programming rather than typical AI application code.
06
V. Why This Is Particularly Valuable for Multi-Agent Systems
In a multi-agent system, if all Agents see the same set of external capabilities, two problems easily arise:
01 Each Agent is over-authorized.
02 Each Agent’s prompt space is diluted by irrelevant tools.
Claude Code’s role-level MCP can effectively mitigate these two issues.
To give an abstract example:
• An “Explore” Agent might only need read-only resource MCPs.
• A “Deployment” Agent might need specific publishing system MCPs.
• A “Verification” Agent might need browser / monitoring / diagnostic capabilities.
If these were all mixed into the main tool pool, the model would be heavily burdened. By mounting them per Agent, the coupling between capabilities and tasks becomes much more rational.
07
VI. This Also Means Claude Code Understands “Agents” More Like an Operating System
In a standard chat system, a role usually only differs by prompt. In Claude Code, an Agent can even possess its own attached capability space upon startup.
This is very similar to:
• A process mounting its own devices when it starts.
• A container having its own sidecar / volume / secret injected at startup.
In other words, a Claude Code Agent is no longer just a “reasoning role,” but an execution unit with a runtime resource view.
08
VII. Understanding This Highlight in One Diagram
09
VIII. Conclusion
Agent-specific MCP is a highly platform-oriented design. It doesn’t just solve “how to add one more tool,” but addresses:
• How to align capabilities precisely with roles.
• How to reduce unnecessary tool noise.
• How to ensure Agents truly carry runtime resource dependencies.
This type of design is highly valuable in multi-agent systems because it simultaneously improves:
• Focus.
• Cost.
• Security boundaries.
• Extensibility.
In summary:
Claude Code does not dump all external capabilities onto every Agent; instead, it allows each Agent to start its shift with its own specific view of peripherals.