MCP server 返回消息无法获取 content.text 之外的信息 || MCP server returns message that information other than content.text cannot be obtained

What version of Kimi Code CLI is running?

kimi, version 1.34.0

Which open platform/subscription were you using?

/login

Which model were you using?

kimi-for-coding

What platform is your computer?

No response

What issue are you seeing?

我有一个mcp server会返回一个json，但是在kimi cli里面只看到了content.text里面的内容，这里面是一个摘要，然后我尝试用powershell直接执行能返回全部的消息，并且在claude code中执行相同的mcp server操作，返回的是structuredContent.items里面的信息。

下面是kimi code的回复：

我只看到了 前 3 条消息的摘要，和之前 PowerShell 方式里 result.content.text 的内容一模一样。

后面的 97 条消息，我通过 MCP 工具调用是看不到的。

原因和之前分析的一样：CipherTalk MCP 的返回有两层结构：

content.text：human-readable 的摘要（只列前 3 条）
structuredContent.items：完整的结构化数据数组（100 条全在）
当我通过 MCP 工具（get_messages）调用时，Kimi Code CLI 作为 MCP 客户端，只把 content 里的文本内容展示给了我。structuredContent 这部分完整 JSON 数据没有被透传到我的上下文中。

你可以理解成：

MCP 工具调用 = 只能拿到"摘要预览"
PowerShell / stdio 直连 = 才能拿到"原始完整 JSON"
所以如果你需要我做基于全部 100 条消息的详细分析、统计、或者导出结构化数据，还是得用 PowerShell / stdio 的方式。如果只是想快速看一下最新聊了什么、让我做个大致总结，MCP 工具调用就足够了（虽然这里只给了前 3 条，但结合上下文我也能做些推断）。

相同问题我在claude code中得到的回复：
--我想问为什么你mcp中提取的不是 content.text ，而是 structuredContent，这个是哪里控制的？

--这是 Claude Code 的 MCP 客户端框架 内部的解析逻辑，具体实现在 Claude Code 这个客户端软件里，而不是 MCP 协议或 CipherTalk server 控制的。

我能观察到的事实
从 shell 直连可以看到完整的 JSON-RPC 响应：

{
"result": {
"content": [{"type": "text", "text": "Loaded 100 messages..."}],
"structuredContent": {"items": [...], ...},
"isError": false
}
}
而 Claude Code 最终展示给你的是：

{"items": [...], "offset": 0, "limit": 100, "hasMore": true}
这说明 Claude Code 在收到响应后，主动选择了 structuredContent 字段，绕过了 content.text。

为什么是 structuredContent？
这属于客户端框架的智能适配逻辑。合理的推断是：

content 是给人类看的 —— text 是一段格式化字符串（"Loaded 100 messages.\n1. ..."）
structuredContent 是给机器/LLM 用的 —— 纯 JSON 数组，带字段、类型、时间戳
Claude Code 作为 LLM 的客户端，检测到存在 structuredContent 时，优先返回结构化数据，因为这样更便于下游做代码解析、表格展示、条件过滤
类比
就像你调用一个 REST API，服务端同时返回了：

message: 人类可读的错误描述
error_code: 机器可处理的错误码
一个智能的 SDK 客户端可能会优先把 error_code 抛给调用方做程序化判断，而不是只返回 message 字符串。

总结：这个提取行为是 Claude Code 内部实现的，不是你能通过配置或参数控制的。它看到 structuredContent 存在，就自动帮你拆包取结构化数据了

What steps can reproduce the bug?

使用mcp server的时候

What is the expected behavior?

mcp server的消息内容透传

Additional information

No response

---

What version of Kimi Code CLI is running?

kimi, version 1.34.0

Which open platform/subscription were you using?

/login

Which model were you using?

kimi-for-coding

What platform is your computer?

No response

What issue are you seeing?

I have an mcp server that returns a json, but in kimi cli I only see the contents of content.text, which is a summary. Then I try to use powershell to directly execute it to return all the messages, and perform the same mcp server operation in claude code, and the information in structuredContent.items is returned.

Here is kimi code’s reply:

I only saw the summary of the first 3 messages, which was exactly the same as the content of result.content.text in the previous PowerShell method.

The next 97 messages cannot be seen when I call them through the MCP tool.

The reason is the same as analyzed before: the return of CipherTalk MCP has a two-layer structure:

content.text: summary of human-readable (only the first 3 items are listed)
structuredContent.items: Complete array of structured data (all 100 items)
When I call it through the MCP tool (get_messages), Kimi Code CLI, as the MCP client, only displays the text content in content to me. structuredContent This part of the full JSON data is not passed through to my context.

You can understand it as:

MCP tool call = can only get "summary preview"
PowerShell / stdio direct connection = to get "original complete JSON"
So if you need me to do detailed analysis, statistics, or export structured data based on all 100 messages, you still have to use PowerShell / stdio. If you just want to quickly take a look at what was recently discussed and let me give a rough summary, the MCP tool call is enough (although only the first 3 are given here, I can also make some inferences based on the context).

The response I got from claude code to the same question:
--I would like to ask why the extracted content in your mcp is not content.text but structuredContent. Where is this controlled?

--This is the internal parsing logic of Claude Code's MCP client framework. It is specifically implemented in the Claude Code client software and is not controlled by the MCP protocol or CipherTalk server.

Facts I can observe
The full JSON-RPC response can be seen from the shell direct connection:

{
"result": {
"content": [{"type": "text", "text": "Loaded 100 messages..."}],
"structuredContent": {"items": [...], ...},
"isError": false
}
}
And what Claude Code finally shows you is:

{"items": [...], "offset": 0, "limit": 100, "hasMore": true}
This shows that after receiving the response, Claude Code actively selected the structuredContent field, bypassing content.text.

Why structuredContent?
This belongs to the intelligent adaptation logic of the client framework. A reasonable inference is:

content is for humans - text is a formatted string ("Loaded 100 messages.\n1. ...")
structuredContent is for machine/LLM use - plain JSON array with fields, types, timestamps
As the client of LLM, Claude Code will give priority to returning structured data when it detects the existence of structuredContent, because this is more convenient for downstream code parsing, table display, and conditional filtering.
analogy
Just like you call a REST API, the server also returns:

message: human-readable error description
error_code: error code that the machine can process
A smart SDK client may give priority to throwing the error_code to the caller for programmatic judgment instead of just returning the message string.

Summary: This extraction behavior is implemented internally by Claude Code and is not something you can control through configuration or parameters. When it sees that structuredContent exists, it automatically unpacks and retrieves the structured data for you.

What steps can reproduce the bug?

When using mcp server

What is the expected behavior?

MCP server message content transparent transmission

Additional information

No response

No source file, test, or entry point is named. Reproduce the MCP call using a server response containing both content.text and structuredContent, then trace the CLI's MCP response handling; done means the returned structured data is available to the model instead of only the summary text.