MCP tool call records missing from model context in long conversations

[kangfenmao]

Problem Description

When managing conversation context, Cherry Studio currently has an asymmetry between what users see and what the model receives regarding MCP tool call records:

• User sees: Complete MCP request → parameters → response chain
• Model receives: MCP call records are filtered out, only natural language interaction content (main text) is retained

Impact

This "information asymmetry" accumulates and amplifies in long-context conversations, causing the model to gradually form incorrect cognitive patterns. This design flaw is particularly evident in tool-intensive conversations:

1. Tool call hallucinations: The model mistakenly believes that language intent like "Let me open the Bing search page!" can directly drive functionality, rather than through the standardized MCP protocol
2. Fake call tendency: In complex or multi-turn conversations, the model tends to "speak out" tool functionality rather than actually calling tools
3. Reliability degradation: The longer the conversation, the more confused the model becomes about how to use tools

Environment

• Version: 1.7.7 | Platform: win32
• Verified models with issues: DeepseekChat (Deepseek v3.2), GLM-4.7 (approximately after 30k context)
• MCP tools used: @playwright/mcp@latest

Reproduction

What the client (user) sees in context:

Let me open the Bing search page!
{
   "params": {
     "url": "https://www.bing.com"
   },
   "response": {
     "content": [...]
   }
}
The Bing page has been successfully opened! Now seeing the Bing Chinese version homepage...

What is actually sent in the request context:

Let me open the Bing search page!
(MCP call record missing here)
The Bing page has been successfully opened! Now seeing the Bing Chinese version homepage...

Proposed Solution

Adopt a lightweight structured MCP record strategy that retains request metadata while omitting detailed responses:

Historical calling process format (for model to inherit)

{
   "type": "mcp_request",
   "method": "tool_method_name",
   "params": {"key_params": "..."}
}

Historical calling result format (helps model understand execution status)

{
   "status": "COMPLETED"  // or "FAILED", "INTERRUPTED", "INVALID_PARAMS", etc.
}

Technical Advantages

1. Solves hallucination root cause: Model clearly sees "MCP call is a necessary intermediary"
2. Context efficiency: Retains key metadata (~200 tokens), omits detailed responses (potentially thousands of tokens)
3. Status learning: Through independent status fields, the model can learn failure patterns and retry strategies
4. Protocol standardization: Reinforces MCP as a standardized interface
5. Long conversation stability: Prevents error patterns from accumulating in context

Technical Context

Looking at the codebase:

• src/renderer/src/aiCore/prepareParams/messageConverter.ts - The convertMessageToSdkParam function currently only processes MainText, File, Image, Thinking blocks
• src/renderer/src/utils/messageUtils/find.ts - Has a deprecated getContentWithTools function that converts Tool blocks to text, but it's not used in the main flow
• Tool blocks (MessageBlockType.TOOL) exist but are not included when building the model context

Labels

• bug
• enhancement
• mcp

[Qtgcy08]

Thank you to the Cherry Studio team for carefully considering my suggestion email and giving it attention.

Considering the differences in usage scenarios among different users, I suggest designing the feature of adding MCP status to the context as a configurable option. This is particularly important for users who run models locally, as context length may be more limited, and they may need more flexible control.

Additionally, I'd like to suggest considering compatibility with the advanced reasoning paradigms introduced by next-generation models like GLM-4.7. According to its official documentation, GLM-4.7 enhances Interleaved Thinking and introduces Preserved Thinking and Turn-level Thinking mechanisms. The core concepts include:

• Thinking between actions: The model reasons before each response and tool call to improve instruction following.
• Preserving reasoning across turns: Automatically retains thinking blocks in multi-turn scenarios (e.g., coding agents), reusing existing reasoning rather than re-deriving from scratch.
• Turn-level control: Allows per-session control over reasoning—disabling for lightweight tasks to reduce latency/cost, enabling for complex tasks to improve accuracy.

I suggest Cherry Studio consider providing configuration options to support such "thinking-action" paradigms within the MCP context management system. This would allow users to flexibly choose whether and how to preserve reasoning records based on their model's capabilities and specific task requirements.