Feature Request: Improve Claude Code Token Management with MCP Servers

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/6638
2. https://github.com/anthropics/claude-code/issues/6309
3. https://github.com/anthropics/claude-code/issues/1774

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Hey, this is a fantastic and incredibly well-detailed feature request. You've perfectly articulated a major friction point in using MCP servers for complex, discovery-driven workflows. That static 18k+ token hit just for the possibility of needing a tool is a tough pill to swallow when context is so valuable.

While we wait for an official solution from the Claude Code team, exploring some of the existing configuration options might offer a potential workaround to mitigate the issue.

Potential Workaround 1: Project-Scoped MCP Configurations

One approach could be to utilize Project-Scoped MCP Configurations. Instead of managing all MCP servers at the user/global level, they can be defined per-project in a .mcp.json file at the root of a repository.

The documentation on MCP mentions this capability:

Project scope: Project-scoped servers enable team collaboration by storing configurations in a .mcp.json file at your project's root directory. This file is designed to be checked into version control, ensuring all team members have access to the same MCP tools and services.

This would allow you to only have relevant servers loaded for a given project, which could help separate, for instance, a Node.js project's tools from a Python project's tools, reducing the overhead in each.

Potential Workaround 2: Using the --mcp-config flag for "Task Profiles"

A second, perhaps more flexible, possibility involves using the --mcp-config CLI flag. This flag lets you load MCP server definitions from a specified JSON file at launch, and can be combined with --strict-mcp-config to ignore all other configurations. This could effectively be used to create "task profiles."

For instance, one could create a few different JSON files for common task types:

• ~/.claude/mcp_profiles/aws-lambda-debug.json (loads just aws-core, aws-documentation)
• ~/.claude/mcp_profiles/aws-cdk-dev.json (loads aws-core, aws-cdk)
• ~/.claude/mcp_profiles/aws-billing.json (loads aws-pricing)

A session could then be started that is tailored to a specific task, loading only the necessary tools:

# Start a session just for debugging a Lambda function
claude --mcp-config ~/.claude/mcp_profiles/aws-lambda-debug.json --strict-mcp-config

This still requires a restart to switch contexts, but it seems like a faster way to manage toolsets without the huge token overhead of a monolithic global configuration.

---

Again, these are just stopgaps. Your proposed solution of runtime MCP management via the /mcp command is the ideal state. Being able to dynamically load/unload tool schemas mid-conversation without losing context would be a game-changer for token efficiency and workflow fluidity.

+1 from me. Thanks for writing this up so clearly.

I've created a working implementation that addresses your token management concerns:

🔗 Repository: https://github.com/machjesusmoto/claude-lazy-loading
📝 Full discussion: #7336

Solves your specific issues:

• Static overhead eliminated: AWS MCP (18.3k) loads only when AWS operations detected
• Discovery-friendly: Tools load based on context, not pre-configuration
• No restart needed: Registry approach enables dynamic loading (with native support)

Your AWS example:

# Default state: 5k registry only (not 18.3k)
"Explain this Python function" → AWS stays unloaded

# AWS work detected: Load on-demand
"Deploy to Lambda" → AWS MCP loads (+18.3k)

The implementation shows 95% reduction is achievable (108k → 5k initial tokens). This would give you back that 9.2% of context immediately.

I approached this from a different angle, choose what MCP servers you want when you start the session. Since you can resume a session, I feel it's OK to quit a session, select the MCP server you want to load and resume the session.

https://github.com/gsong/ccmcp

@gsong - looks like a useful tool. I've ended up in a similar spot:

• created scripts to enable/disable MCP servers and subsets of servers
• simply quit and continue a conversation when I need to enable one

Would still like to see CC add some type of MCP server management as part of the default tooling - the deferred loading until we request using the server would be ideal, IMO.

Having people choose which MCPs they'll need throughout a session is not really scalable. When you manage MCPs in a centric way, have subagents use those dynamically and want developers to have the best experience this should be totally transparent. Currently, it also limits the number of MCPs one can configure without bloating the entire context window.

While i created a wrapper that people can config which MCPs they would like to load in a specific session, this is not good enough.
This also defeats many initiatives like using central MCP gateways for exposing different MCPs to different groups of developers / devops engineers / secops / etc.
Can we make MCPs lazy loaded per the tool they need in realtime?

@nCubed - Yeah, I've taken a similar workaround approach of enabling/disabling the MCP servers by script for servers I toggle often. I have a bunch that are versatile and used frequently enough that I keep them on, though.

@talf - I think a production-ready feature would be a hybrid of deferred loading and lazy loading. Both would leverage a registry, and servers would load when directly requested or the agent/subagent contextually determines and loads it automatically.

I'd like to emphasize several critical issues stemming from having MCP tools continuously active in Claude Code:

1. Token Consumption Overhead

Active MCP servers inject all tool schemas into every session — even when not used. This leads to massive context pollution and wastage of thousands (sometimes tens of thousands) of tokens per conversation. For many workflows, especially those only rarely requiring MCP integration, this means a huge fraction of the token window is lost to tool definitions instead of core code or dialogue.

1. Performance and Developer Experience

Context bloat degrades LLM performance:

• Tool selection becomes less reliable as the model is forced to consider irrelevant tools.
• Users face sluggish conversations, occasional crashes, and an opaque experience where token depletion happens unpredictably.

1. Security Risks

Passive exposure of all tool APIs increases the attack surface. Any tool — even dangerous ones (filesystem access, shell commands) — is potentially available for misuse unless specifically filtered. This violates least privilege principles, making systems more vulnerable to prompt injection, misuse, and lateral privilege escalation.

1. Inefficiency for Standard Workflows

Most conversations do not need MCP tools at all. Users are penalized with overhead and risks for a capability they didn't request. Activation should be explicit: the context and resources stay optimized unless an MCP action is invoked.

1. Scalability, Flexibility, and Predictability

When tool orchestration is handled on-demand (lazy loading or orchestrator-driven activation), developers can scale up as needed without fear of breaking context or workflow. This design preserves context for code, reduces cognitive stress over token management, and greatly improves security transparency.

Proposal: MCP servers in Claude Code should be disabled by default, and only activated on-the-fly via a dedicated orchestrator when the user requests a capability. No token or security stress should exist unless an explicit MCP call is made. This would restore predictable resource allocation, high security, and the best developer experience for both coding and AI-assisted workflows.

It's worth noting that MCP Toggle functionality has been added in Claude Code 2.0.10:

## 2.0.10 - Rewrote terminal renderer for buttery smooth UI - Enable/disable MCP servers by @mentioning, or in /mcp - Added tab completion for shell commands in bash mode - PreToolUse hooks can now modify tool inputs - Press Ctrl-G to edit your prompt in your system's configured text editor - Fixes for bash permission checks with environment variables in the command

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.