先记住这个答案
在 MCP 工具调用结果中，content 是必含的内容块数组，例如文本或图像，用于渲染给用户或交给大语言模型理解。structuredContent 是可选的 JSON 对象，若工具声明了 outputSchema，其结构应当与之一致。outputSchema 是 JSON Schema，它定义了结构化返回的字段与类型，客户端可据此校验和直接提取数据。消费时应当优先使用 structuredContent，因为它不需要文本解析且类型安全；仅当它缺失时才退而解析 content。若两者同时存在但信息冲突，通常信任 structuredContent。
- 结构化内容优先于文本解析
- outputSchema 声明返回结构
- 缺失 structuredContent 时读取 content
内容块与结构化对象的互补机制
在 MCP 的工具调用响应中，result 对象需要包含 content 数组，数组里放的是诸如 TextContent、ImageContent 等带类型标记的元素，它们适合被用户界面展示，也容易嵌入到大语言模型的提示里。structuredContent 则是可选单个对象，服务端把机器可用的数据以干净、有一定结构的形态放进去。它的键和嵌套类型应当与工具通过 outputSchema 声明的模式吻合（当声明了 outputSchema 时），客户端可以从工具清单里获得该 schema。
协议规定只有 content 是必须发送的，structuredContent 完全由服务端决定是否给出。当两边都返回时，content 往往承载叙述性摘要，而 structuredContent 提供可直接编程存取的值。客户端应把 structuredContent 当成首选来源，因为它免去了解析自然语言的成本，也避免因措辞变化导致的错误。只有 structuredContent 字段不存在时才解析 content，这是一种常见的安全回退策略。
仓库统计工具中的双通道返回
比如有一个 get_repo_stats 工具，其 outputSchema 声明 owner 为 string、stars 为 integer、license 可为 null。某次返回里，content 是一段英文：“octocat/hello-world has 1523 stars and is MIT licensed.”，而 structuredContent 是 {"owner":"octocat","stars":1523,"license":"MIT"}。下游的排序逻辑需要得到整数 1523，显然不能依赖从文本正则抽取。
编排层在拿到结果后先检查 structuredContent 是否为对象，再用 JSON Schema 比对字段的存在与类型，确认无误后直接读取 stars 属性。假如 schema 不一致，就记录错误并退回到文本正则，但生产环境一般把这个风险暴露为日志，而不是盲目信任任意文本。这样处理让展示型文本和业务数据脱钩，工具实现方能够独立演进。
依赖边界与校验代价
依赖 structuredContent 的前提是服务端真的按 outputSchema 返回。如果工具没有声明 outputSchema，那么我们无法根据 schema 判断对象长什么样，使用 structuredContent 需要额外的信任或自行约定，否则可能更倾向于依赖 content。另外，outputSchema 允许是空对象 {}，那表示“任意结构”，也不能提供任何类型保证，同样需要额外的信任或自行约定。
当结构化对象与 schema 不一致时，协议没有规定错误码，客户端只能自行检测。投入严格的 JSON Schema 校验会占用 CPU 但换来稳定性，更实际的做法是在测试环境启用完整校验、生产环境做轻量类型判断并用 try/catch 处理异常。一旦发现异常就抛给上一层，别让损坏的数据悄悄钻进后续流程。
容易答错的地方
- 认为 structuredContent 只是 content 的压缩版
- 其实两者载体不同：content 是可展示的块列表，structuredContent 是单一对象。即使内容相同，structuredContent 缺失时无法从文本中无损还原，因此二者不是等价替代。
- 把 outputSchema 误解为只校验输入
- outputSchema 专门描述返回对象的结构，而 inputSchema 用于入参。若只按输入场景使用，客户端就无法为返回数据生成类型提示或校验逻辑，容易在字段改名时悄然崩溃。
面试官还会怎么问？
如果 structuredContent 和 outputSchema 不一致，客户端可以怎么做？
没有强制要求，但可视为服务端错误。稳妥做法是放弃该对象并回退到 content，同时打印警告；若数据是交易关键则直接抛错误，避免下游被虚假值污染。
有没有必须使用 structuredContent 的场景？
有。例如结果需要写入数据库或参与计算，字段必须是整数或枚举。此时文本无法可靠解析，只有结构化数据能携带准确的类型。
content 为空数组但 structuredContent 有值时合法吗？
合法，content 字段可以为空数组，但它必须存在以维持结构完整性。客户端若只关心结构化数据，可以不理会 content。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。