[Feature Request] MCP Context Isolation - Assign MCPs to Forked Agent/Skill Contexts

+1, this definitely needs an effective solution for the current “full bundle loading” behavior of MCP. Otherwise, there is an awkward gap between AgentSkills and MCP right now. Ideally, the two could complement each other and reach a better balance.

One of the most straightforward and lowest-cost approaches I can think of is to allow Skill Scripts to communicate directly using the MCP protocol. This would make it possible to use MCP server tools from Claude Code without having to install MCP inside Claude Code itself.
A reference implementation can be found here:
https://github.com/cablate/mcp-progressive-agentskill

I also strongly agree with @gn00295120’s idea of more explicitly loading MCP only for certain agents, supporting proper context isolation.

Or providing switches to enable/disable specific MCP-connected sub-tools. This would allow exposing only the necessary information and avoid the waste caused by loading everything by default. These are all capabilities that the MCP client side can already support.

Hope Anthropic team can implement similar optimizations in Claude Code.

Update: Why MCP Matters - Centralized Authentication

Some might suggest: "Why not just abandon MCP and wrap API calls in Skills using bash/curl?"

The critical issue is authentication:

| Aspect | MCP | Skills + Scripts |
|--------|-----|------------------|
| Credential Management | Centralized in settings.json | Scattered across .env, scripts, env vars |
| Security | Environment isolation | Risk of exposure in logs/shell history |
| Token Refresh | Handled automatically | Manual implementation required |
| Error Handling | Standardized responses | Different per API |

MCP's value isn't just the tools—it's the centralized, secure credential management.

Context Isolation preserves this security benefit while solving the context consumption problem. This is why we need MCP Context Isolation, not MCP abandonment.

---

This update has also been added to the RFC and article.

+1, please implement this. We need to be able to have a clean default Claude instance at all times. Also, make it possible for it to have some MCPs loaded by default.

1. Make the default orchestration instance have its own MCPs activated.
2. Make the individual skill have its own MCPs activated.
3. Make the subagents have their own MCPs activated.

Problem solved.

@ivanjuras Great breakdown\! This aligns perfectly with the RFC proposal.

Three Components, Three Roles

| Component | Role | MCP Scope |
|-----------|------|-----------|
| MCP | Provides services (tools, credentials, API access) | - |
| Agents | Isolated brain with clean context | Domain-specific (github, postgres) |
| Skills | Defines workflow - how to process data | Task-specific (stripe, vercel) |

Architecture: Parallel Forked Contexts

Main Context (Minimal - ~1,300 tokens)
├── Base MCPs: filesystem, memory
│
├── Agents (forked)              ← isolated context
│   ├── code-reviewer: + git
│   ├── database-specialist: + postgres
│   └── deploy-agent: + vercel, github
│
└── Skills (forked)              ← isolated context
    ├── /payment: + stripe
    ├── /db-migrate: + postgres
    └── /deploy: + vercel, github

Both Agents and Skills fork from Main Context with their own MCP scope. This enables:

1. ✅ Context efficiency - Main context stays permanently clean
2. ✅ Granular permissions - Each component loads only needed MCPs
3. ✅ Security isolation - Credentials scoped to specific tasks
4. ✅ Scalability - 20+ MCP servers without context pressure

Bonus: Skills Can Invoke Agents

Skills can also delegate to specific Agents via agent frontmatter:

---
name: deploy-workflow
agent: deploy-agent        # ← delegates to this agent
mcp: [vercel]
context: fork
---

This creates a powerful composition: Skill defines WHAT to do, Agent executes HOW to do it - each with isolated MCP contexts.

+1 for per-level MCP scoping\!

+1, it would also be nice, optional, to define specific tools for a mcp. Often, I need just 1 or 2 for Agent/Skill.

# agents/database-specialist.md
---
name: database-specialist
mcp:
  required: [postgres]
    tools: [mcp__<server_name>__<tool_name>, mcp__<server_name>__<tool_name>, ...]
  optional: [redis]
context: fork
---

Further questions: What are the arguments against including this in the RFC for commands as well?

+1 - was just just going to open a feature request.

Example - a security review agent does not need access to my google calendar or gmail mcp

This proposal covers context isolation well. Worth noting there's a complementary problem: security isolation. Even with per-agent MCP scoping, each MCP tool still runs with the full permissions of the host process. A write_file tool and a read_file tool share the same filesystem access. A tool that needs network access grants that to every other tool in the same server.

We built sandlock to address this. Its McpSandbox enforces per-tool sandbox policies at the kernel level (Landlock + seccomp), deny-by-default:

from sandlock.mcp import McpSandbox

mcp = McpSandbox(workspace="/project")
mcp.add_tool("read_file", read_fn)  # read-only access, no network
mcp.add_tool("write_file", write_fn, capabilities={"fs_writable": ["/project"]})
mcp.add_tool("fetch_api", fetch_fn, capabilities={"net_allow_hosts": ["api.example.com"]})

Each tool invocation runs in its own sandbox. read_file can't write. write_file can't reach the network. fetch_api can only talk to api.example.com. No root, no containers.

For MCP servers discovered via sandlock:* tool annotations, policies are extracted automatically:

caps = capabilities_from_mcp_tool(tool)  # reads sandlock:* annotations
policy = policy_for_tool(workspace="/project", capabilities=caps)

Context isolation (this proposal) and security isolation (sandlock) solve different layers of the same problem. The two could work together -- forked contexts for token efficiency, kernel sandboxing for least-privilege enforcement per tool.

Disclaimer: I'm the sandlock author.

Very good proposal! Maybe for MCP servers with lots of tools it would be helpful to be able to limit tools in the skill frontmatter as well? I have made a slightly overlapping proposal: https://github.com/anthropics/claude-code/issues/41068

I would prefer to have the concept of "profiles" that contains a set of skills, agents, and MCPs that can be loaded up before loading up claude .

Any progress on this topic ? This is a real nightmare.