[BUG] "Tool access" setting has no effect — MCP tools always load eagerly in Claude Code Desktop
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:
- Toggling the setting changes nothing. Switching between "Load tools when needed" and "Tools already loaded", then starting a new conversation, produces identical
/contextoutput. MCP
tool schemas are always loaded eagerly regardless of the selected option.
- 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?
- Toggling between "Load tools when needed" and "Tools already loaded" should produce different
/contextoutput in new conversations.
- When "Load tools when needed" is selected, Desktop should defer MCP tool schemas the same way CLI does — the
/contextoutput 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:
- Go to Settings → Capabilities → Tool access → select "Load tools when needed"
- Start a new conversation, type "say hi", wait for response
- Run /context — note the "MCP tools" line
- Go to Settings → Capabilities → Tool access → switch to "Tools already loaded"
- Restart Claude Desktop
- Start a NEW conversation, type "say hi", wait for response
- 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:
- Open Claude Code CLI in the same directory:
claude - Type "say hi", wait for response
- 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_
4 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
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
/contextoutput in both modes:--no-mcp-tools: tools absentIf 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.
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" />
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.