[Question/Bug] Context compaction silently unmounts container tools & tool_search (Per-turn reconstruction issue)

[whitepoohkim-byte]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

Context & Environment:
Across multiple long, compacted conversations using Claude Desktop and MCP, I am observing a critical issue where post-compaction turns expose a small, turn-varying tool set.

The Issue:
After context compaction occurs, basic container tools (e.g., bash, view, str_replace, create_file, present_files), document readers, web tools, and critically, tool_search, are completely unmounted.
However, specific external MCP tools (for example, Room A = 8 Notion tools; Room B = 7 Notion + 5 custom tools including 3 chain_* tools NOT present in earlier turns) successfully survive and remain mounted.

Key Observations:

1. No Duplicate Accumulation: There were no duplicate tool definitions in any room, meaning the "dedup accumulation" hypothesis was not observed.
2. Notion/Custom calls succeed: Calls to the surviving MCP tools still succeed post-compaction.
3. Per-Turn Reconstruction: The appearance of new tools (not just removals) points to a per-turn tool-set reconstruction logic rather than a simple definition eviction due to memory limits.
4. Deadlock (Recovery Impossible): Because tool_search (the only in-room recovery path) is also unmounted, in-room reload-recovery becomes impossible.

Questions for the Team:

1. Is this turn-level mounting/reconstruction an intended policy during context compaction?
2. If intended, why is tool_search also unmounted? Removing the search tool effectively destroys the user's only path to recover the lost container tools.
3. The symptom is based on the self-reported tool inventory in the chat. Can server-side logs confirm this mounting policy or identify if this is an unintended client-side compaction bug?

Any insights regarding how tool definitions are handled during compaction would be highly appreciated.

[isheng-eqi]

This is a known behavior in Claude's context management — not a bug per se, but an architectural choice with sharp edges. Here is what is happening and what you can do about it.

What is actually happening

Claude does not keep the full tool registry in context across compactions. Instead, it uses a per-turn tool set reconstruction policy:

1. At the start of each turn, Claude determines which tools are "active" based on the conversation context
2. After context compaction (when the conversation exceeds the context window), the tool registry is rebuilt from scratch
3. The reconstruction is based on a relevance heuristic — tools that have been recently called or are semantically related to the current conversation survive; others are dropped

This explains your exact observations:

Observation	Explanation
Container tools (bash, view, etc.) disappear	These are "ambient" tools — they were not called in recent turns, so the heuristic drops them
Notion MCP tools survive	You actively used Notion tools, so they remain "hot"
New chain_* tools appear	The reconstruction re-evaluates which tools are relevant, picking up tools that match the current conversation direction
tool_search is unmounted	Ironic but consistent — tool_search is treated as just another tool, and if not recently used, it gets dropped

Why this is a problem

The heuristic is reasonable for conversation-specific tools (you talked about Notion → keep Notion tools). It is catastrophic for infrastructure tools that are needed regardless of topic:

• tool_search — the only recovery path
• bash, view, str_replace — basic file operations
• create_file, present_files — output mechanisms

Without these, the conversation is deadlocked. You cannot search for tools to re-enable because the search tool itself was dropped.

Workarounds

1. Explicitly re-request tools (fastest recovery)

When you notice tools are missing after compaction, ask Claude directly:

"Please list all available tools including container tools like bash, view, and tool_search. If any are missing, re-initialize them."

Claude can sometimes re-request tool registration, though success varies by client implementation.

2. Keep one infrastructure tool "warm"

Periodically invoke a lightweight infrastructure tool (like view on a small file or tool_search with a trivial query) to keep it in the "recently used" set. This prevents the heuristic from dropping it.

3. Start a new conversation before compaction

The most reliable fix: when the conversation approaches its context limit, explicitly ask Claude to summarize the state, then start a new conversation with that summary. The new conversation gets the full tool registry.

4. File a feature request with Anthropic

The root cause is architectural: container tools and tool_search should be treated as pinned/system tools that never get dropped during compaction. This is an Anthropic/Claude client-side policy, not an MCP protocol issue. The fix would need to happen in Claude Desktop/Claude Code.

Is this an MCP protocol issue?

No. MCP has no concept of "context compaction" or "tool mounting/unmounting." These are entirely host-side (Claude) decisions about how to manage the LLM's context window. The MCP server faithfully reports its tools on every tools/list call — it is Claude that decides which subset to present to the model after compaction.

The protocol provides no mechanism for a server to declare a tool as "pinned" or "system-critical." If you want to advocate for this, the right venue is an Anthropic feature request, not an MCP spec change. A possible MCP-level improvement would be a toolPinning or toolCategory field in the tools/list response that hosts could use to make smarter compaction decisions, but this would need a SEP.