[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.