[BUG] "Tool access" setting has no effect — MCP tools always load eagerly in Claude Code Desktop

Status Fixed / completed
Reported on v2.1.109
Maintainer reply None cached
Activity 4 comments · opened Apr 16, 2026 · closed Apr 16, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

The "Tool access" setting (Settings → Features → Tool access) has no effect on how MCP tools are loaded in Claude Desktop.

Two problems:

  1. Toggling the setting changes nothing. Switching between "Load tools when needed" and "Tools already loaded", then starting a new conversation, produces identical /context output. MCP

tool schemas are always loaded eagerly regardless of the selected option.

  1. Desktop differs from CLI. Claude Code CLI correctly defers MCP tool schemas (loaded on-demand via ToolSearch, 0 tokens at session start). Desktop always loads them eagerly — ~75k tokens

for 155 tools in my setup.

This causes Desktop sessions to have 4× higher baselines than CLI (~92k vs ~22k). For agentic tasks with many tool iterations, the overhead compounds across every turn via the prompt cache.

What Should Happen?

  1. Toggling between "Load tools when needed" and "Tools already loaded" should produce different /context output in new conversations.
  1. When "Load tools when needed" is selected, Desktop should defer MCP tool schemas the same way CLI does — the /context output should show "MCP tools · /mcp (loaded on-demand)" with ~0

tokens, matching CLI behavior.

Error Messages/Logs

Steps to Reproduce

Setup: macOS, Claude Desktop, multiple MCP connectors enabled (e.g. Linear, Datadog, Slack).

Test 1 — Setting toggle has no effect:

  1. Go to Settings → Capabilities → Tool access → select "Load tools when needed"
  2. Start a new conversation, type "say hi", wait for response
  3. Run /context — note the "MCP tools" line
  4. Go to Settings → Capabilities → Tool access → switch to "Tools already loaded"
  5. Restart Claude Desktop
  6. Start a NEW conversation, type "say hi", wait for response
  7. Run /context — "MCP tools" line is identical to step 3

<img width="678" height="994" alt="Load tools when needed" src="https://github.com/user-attachments/assets/b4b90a66-a973-4085-b0b0-572be691277f" />

<img width="662" height="988" alt="Tools already loaded" src="https://github.com/user-attachments/assets/f4defca0-ee8f-48d7-8619-70db6089b380" />

Test 2 — Desktop vs CLI comparison:

  1. Open Claude Code CLI in the same directory: claude
  2. Type "say hi", wait for response
  3. Run /context — observe "MCP tools · /mcp (loaded on-demand)" with 0 tokens

<img width="717" height="474" alt="CLI mcp tools" src="https://github.com/user-attachments/assets/0a9b23d3-275f-4a88-a9be-0d8f459a564b" />

Results:

  • Setting A ("Load tools when needed"): MCP tools = 33.6k
  • Setting B ("Tools already loaded"): MCP tools = 33.6k — identical
  • CLI (same machine, same connectors): MCP tools = 0 (on-demand)

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.109 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗

4 Comments

github-actions[bot] · 6 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/41472
  2. https://github.com/anthropics/claude-code/issues/47645
  3. https://github.com/anthropics/claude-code/issues/25892

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

0xbrainkid · 6 months ago

The "Tool access" setting having no effect in Desktop while correctly deferring in CLI is a platform-specific capability configuration bug — the setting exists in the UI, changes are accepted, but Desktop does not apply them when initializing the session.

The 4× context baseline difference (~92k vs ~22k tokens for 155 tools) is significant: for agents that iterate on tools many times, that ~70k token overhead at baseline compounds across every turn via cache, extending the time to context exhaustion and increasing compaction frequency.

From an agent capability and configuration perspective, a setting that is visible in the UI but has no behavioral effect is a broken capability claim — the user believes they are controlling how tools load, but the actual loading behavior is determined by something else entirely.

Root cause hypothesis: The Desktop application likely has its own session initialization code that always loads MCP tools eagerly, independent of the CLI's lazy-loading mechanism. When the "Load tools when needed" setting is applied, it may correctly configure the CLI subprocess but the Desktop wrapper that initializes the session ignores it.

Verification: Check the /context output in both modes:

  • CLI with --no-mcp-tools: tools absent
  • CLI without flag: tools present if loaded eagerly, "loaded on-demand" if deferred
  • Desktop with "Load tools when needed": should match deferred CLI behavior

If Desktop always shows tools eagerly loaded regardless of setting, the setting is not being passed to or respected by the Desktop session initialization path.

Impact quantification: 70k baseline token difference × cost per token × turns per session × sessions per day = significant real cost for heavy users. This is worth treating as a billing-relevant bug, not just a UI configuration annoyance.

eulbat · 6 months ago

Closing at this seems to be fixed :)

<img width="591" height="516" alt="Image" src="https://github.com/user-attachments/assets/db1e64f0-039f-4af8-a497-114407375436" />

github-actions[bot] · 5 months ago

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.