ModelContextProtocol规范中工具错误处理机制的设计思考

在构建基于ModelContextProtocol（MCP）的AI交互系统时，工具执行过程中的错误处理是一个需要精心设计的环节。本文将从协议设计的角度，探讨工具错误反馈机制的技术考量与实现方案。

错误处理的两种范式

当工具在执行过程中发生错误时（包括第三方API调用失败等预期内错误），协议层面存在两种典型的反馈方式：

1. MCP协议级错误
   将工具执行错误作为协议层的错误响应返回，遵循标准的错误处理流程。这种方式符合HTTP/RPC等传统协议的惯例，但可能割裂LLM对工具调用的连续性认知。

2. 结果对象内嵌错误
   在工具的正常返回结果结构中扩展错误字段（如error键或错误注解），保持协议交互的成功状态。这种方式更符合LLM的认知模式，但需要额外的结果结构设计。

技术权衡分析

协议级错误的局限性
当采用第一种方案时，虽然符合传统API设计习惯，但会导致LLM接收到的响应类型与预期不符。大型语言模型在发起工具调用时期望获得工具执行结果，突然收到协议错误可能导致：

• 错误恢复逻辑复杂化
• 丢失原始错误上下文
• 需要额外设计错误转译机制

结构化错误的优势
第二种方案通过保持协议交互的成功状态，允许：

• 错误信息与正常结果采用相同传输通道
• LLM可以直接处理工具级错误而不中断工作流
• 更细粒度的错误分类（业务错误/系统错误）
• 保留完整的错误上下文供模型决策

推荐实现方案

基于对LLM交互特性的考量，建议采用结构化错误方案，具体设计要点包括：

1. 结果对象扩展

{
  "result": {...},
  "error": {
    "code": "API_RATE_LIMIT",
    "message": "第三方API调用次数超限",
    "retryable": true
  }
}

2. 错误分类标准

• 业务逻辑错误（如参数校验失败）
• 依赖服务错误（如API调用失败）
• 系统级错误（如超时、内存不足）

3. 协议兼容性
   保持原有MCP成功状态码（如HTTP 200），通过结果体内的错误字段区分具体错误场景，避免破坏现有监控体系。

实施建议

对于协议实现者，建议：

1. 在工具SDK中提供标准错误封装方法
2. 定义跨工具的错误代码体系
3. 为常见错误类型提供重试建议标记
4. 保持错误信息的可读性与机器可解析性平衡

这种设计既满足了LLM对工具调用的连续性需求，又为系统运维提供了足够的错误诊断信息，体现了协议设计中对不同角色需求的平衡考量。