MCP loading: fragmented settings, no just-in-time schema loading, no per-machine exclusions

Resolved 💬 1 comment Opened May 24, 2026 by theaiconsultantuk Closed Jun 24, 2026

Summary

Three related but distinct problems with MCP management that compound into a significant usability and performance issue.

---

Problem 1: Settings are split across desktop and web with no sync or visibility

Local MCPs are configured in ~/.claude.json and ~/.claude/settings.json. Remote MCP integrations are configured in claude.ai → Settings → Integrations. These are completely separate systems with no unified view, no sync, and no indication that the other exists when you're working in one.

Real impact: I spent several hours optimising my MCP setup — removing unused servers, archiving skills, reducing context bloat. The optimisation appeared to work locally. What I didn't know was that Adobe, Canva, Cloudflare, Dart, Gmail, Google Calendar, Google Drive, Letterly, Supabase, n8n, and neurosity were still loading full tool schemas every turn via the claude.ai remote integrations panel — a completely separate UI I had no reason to check again.

The result: 153,948 of my 200,000 token context window consumed on static MCP schemas before a single message is exchanged. 77% of context gone before any conversation starts. Compaction fires after only a few exchanges, feels broken, and the root cause is invisible.

Fix needed: Unified settings view across desktop and web. At minimum, surface in the desktop UI that remote MCPs exist and their token cost.

---

Problem 2: All-or-nothing MCP schema loading — no just-in-time loading

Every configured MCP loads its full tool schema on every turn, regardless of whether it will be used. Canva alone contributes 30+ tool definitions. A user who uses one Canva tool once a week is paying the full Canva schema cost on every single turn indefinitely.

The deferred tools mechanism already exists in Claude Code (tools listed by name only, schema loaded via ToolSearch on demand). This pattern should be the default for all MCP tools — declare the MCP exists cheaply, load the full schema only on first invocation in a session.

Fix needed: Lazy/deferred loading for MCP tool schemas. Load the manifest (name + one-line description) at session start. Load full schema on first tool call from that MCP.

---

Problem 3: No per-machine MCP exclusion

A user may want neurosity on their desktop machine with the headset attached, but never on their Mac Mini or laptop. Currently there is no way to exclude a remote MCP from loading on specific machines. It's all-or-nothing globally.

Fix needed: Per-machine MCP exclusion in local settings. Something like:

// ~/.claude.json
{
  "excludeRemoteMcps": ["neurosity", "canva"]
}

---

Combined impact

These three problems together mean:

  • Context optimisation work is silently undermined by a settings system the user doesn't know to check
  • 75%+ of a 200k context window consumed by tool schemas before conversation starts
  • No per-machine control over what loads

This is not a niche edge case — any user with more than 5-6 MCP integrations will hit this. The current behaviour is the opposite of a good plugin system: VS Code doesn't load every extension's full API surface on startup.

---

Environment

  • Claude Code desktop (Mac)
  • Model: claude-sonnet-4-6
  • Context window: 200,000 tokens
  • MCPs configured: 10 local + 11 remote (claude.ai integrations)
  • Static context at session start: ~154,000 tokens (77% of window)

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗