Problem Statement

Currently, all enabled MCP servers load at session start, consuming significant context budget before any actual work begins.

Measured impact (from community reports):

Many MCPs may never be used in a given session, yet they permanently occupy context space.

Real-World Pain Point: The Modern Work Hub Dilemma

Modern knowledge workers manage numerous platforms simultaneously:

The Dilemma:

• Option A (Install All): 50,000+ tokens consumed at session start = 50% context gone
• Option B (Separate by Project): Defeats Claude Code's value as a unified command center

Neither option is acceptable. We need on-demand loading to unlock Claude Code's potential as a universal work orchestrator.

Key Distinction: Context Isolation, Not Lazy Loading

This proposal is fundamentally different from traditional lazy loading approaches.

Traditional Lazy Loading:
Main Context ──[need MCP]──> Load MCP ──> Main Context (now occupied)

Our Proposal (Context Isolation):
Main Context (stays clean)
    └── Fork Agent Context ──> Load MCPs ──> Isolated Context
                                              └── Released when done

This approach:

• Keeps main context permanently clean (not temporarily)
• Reuses existing context: fork infrastructure (lower implementation cost)
• No runtime dynamic loading complexity (load once at fork creation)

Observation

Claude Code 2.1.x introduced context: fork for skills, enabling isolated context for specialized operations. This architecture already supports:

• Spawning isolated sub-contexts
• Independent tool permissions per fork
• Clean context separation

Proposal: On-demand MCP Loading

Extend the fork architecture to support MCP assignment at the agent/skill level:

# Example: agents/database-specialist.md
---
name: database-specialist
description: Database operations expert
tools: [Read, Bash, Grep]
mcp: [postgres, redis]  # Only loads when this agent runs
context: fork
---

# Example: skills/deploy/SKILL.md
---
description: Deploy to production
mcp: [vercel, github]  # Only loads during /deploy
context: fork
---

Proposed Architecture

Main Session (Lean)
    │
    ├── Base MCPs only: filesystem, memory
    │   (minimal context footprint)
    │
    ├── Task: database-specialist (forked)
    │   └── Loads: postgres, redis (isolated)
    │
    └── Skill: /deploy (forked)
        └── Loads: vercel, github (isolated)

Benefits

1. Context Efficiency: Main context stays lean, only loading MCPs when needed
2. Granular Permissions: Each agent/skill has its own MCP scope
3. Progressive Security: Layered access control instead of all-or-nothing
4. Scalability: As MCP ecosystem grows, selective loading becomes essential

Proposed Implementation: Two-Sided Configuration

The ideal solution combines both MCP-side and Agent/Skill-side configuration for maximum flexibility and backward compatibility:

MCP-Side: Lazy Loading Flag in settings.json

{
  "mcpServers": {
    "memory": { "command": "...", "lazy": false },
    "github": { "command": "...", "lazy": true },
    "postgres": { "command": "...", "lazy": true }
  }
}

Agent/Skill-Side: Frontmatter Declaration

# agents/database-specialist.md
---
name: database-specialist
mcp:
  required: [postgres]
  optional: [redis]
context: fork
---

Loading Logic:

Why this approach?

• Backward compatible: Omitting lazy maintains current behavior
• Gradual migration: Move heavy MCPs to lazy: true one at a time
• Fine-grained control: Both infrastructure and application level settings

Challenges to Consider

About Us: Claude World

This proposal comes from Claude World - a Claude Code developer community based in Taiwan.

• 200+ developers joined on Day 1 of our community launch
• We focus on Claude Code best practices, advanced patterns, and architectural improvements
• MCP efficiency and context management is one of our most discussed topics
• We're actively documenting MCP token costs, designing workarounds, and sharing learnings with the global community

We'd love to hear the team's thoughts on this direction!

Related

• context: fork implementation in 2.1.0
• Context awareness features in 2.0.65+
• MCP ecosystem growth
• Issue Feature Request: Lazy Loading for MCP Servers and Tools (95% context reduction possible) #7336 (Lazy loading feature request)
• Issue Lazy-load MCP tool definitions to reduce context usage #11364 (Lazy-load MCP tool definitions)

Full Write-up

For detailed analysis with architecture diagrams and implementation considerations:

• Article: The Future of MCP: From Always-On to On-Demand Loading
• RFC: RFC-0001: MCP Context Isolation