Feature Request: Dynamic/Lazy MCP Server Loading to Reduce Context Window Usage

Problem

MCP server tool definitions are injected into the system prompt at session start, consuming significant context window space even when those tools are never used. Users with multiple MCP servers configured face a choice:

1. Keep all servers enabled → Wastes context on unused tool definitions
2. Manually enable/disable servers → Requires remembering which server is needed before each task, and forgetting means the task fails

This is especially painful for users who:

• Have many MCP servers configured (Linear, Obsidian, database tools, etc.)
• Often chat or do tasks that don't require MCP tools
• Work across different contexts requiring different tool sets

Proposed Solution: Dynamic MCP Server Loading

Implement lazy loading of MCP server tool definitions, similar to Cursor's dynamic context discovery approach. Their implementation achieved 46.9% token reduction in runs that called MCP tools.

How It Could Work

Option A: File-based tool registry (Cursor's approach)

1. Sync MCP tool schemas to local files instead of system prompt
2. Include only server names and brief descriptions in context
3. When Claude needs a tool, it reads the full schema from the file
4. Server connection established on first tool use

Option B: On-demand server activation

1. All servers start in "registered but disconnected" state
2. Claude sees a lightweight registry: linear: "Issue tracking", obsidian: "Note management"
3. When Claude determines it needs a server, it activates it mid-conversation
4. Optional: Auto-disconnect after N minutes of inactivity

Option C: Explicit mid-conversation enable

1. Allow /mcp enable <server> to work mid-conversation without restart
2. Claude can instruct itself (or user) to enable specific servers as needed
3. Tool definitions loaded dynamically into active context

Benefits

• Reduced context usage: Only load tool definitions when actually needed
• Better UX: No need to pre-configure which servers are needed
• Scalability: Users can have many MCP servers without penalty
• Smarter conversations: Claude can determine what tools are needed based on the task

Additional Context

From the Cursor blog post on their implementation:

"We sync MCP tool descriptions to folders. Agents can then discover and access them through search tools. In runs that called an MCP tool, this strategy reduced total agent tokens by 46.9%."

The key insight is treating tool definitions as discoverable resources rather than always-present context.

Alternatives Considered

• Multiple .mcp.json profiles: Works but requires manual switching before sessions
• Tool registry skill: Helps Claude know what to ask for, but still requires manual enable
• Smaller tool descriptions: Reduces but doesn't solve the core problem

---

Would love to see this in Claude Code! Happy to help test or provide more details.