当 AI 客户端通过 MCP 调用搜索、数据库、文件系统或业务 API 时，真正影响稳定性的往往不是工具本身，而是双方对“支持什么、如何调用、失败后怎么办”的理解是否一致。🔧 服务端能力协商与客户端兼容降级，正是避免版本差异、能力缺失和扩展不兼容演变为线上故障的关键。
一、能力协商解决的核心问题
MCP 使用 JSON-RPC 2.0 组织通信，并将工具、资源、提示模板和客户端交互能力纳入统一协议。能力协商不能被简单理解为“获取工具列表”，它至少需要回答三个问题：双方使用哪个协议版本、服务端提供哪些能力、客户端能够处理哪些返回形式。MCP 规范的具体机制会随版本演进，因此实现时应以明确的协议版本为边界，而不是默认所有 MCP 节点行为完全相同。📌
在较早的会话式版本中，客户端通常先发送 initialize 请求，携带协议版本、客户端信息和客户端能力；服务端返回选定版本、服务端信息及其能力，客户端再发送初始化完成通知。按照对应生命周期规范，初始化完成前不应直接执行普通工具调用，相关流程可参考 旧版生命周期文档[1]。
在 2026-07-28 规范中，MCP 核心转向无状态、自包含请求，传统 initialize 和 initialized 交换被移除，能力信息可随请求传递，客户端也可以通过可选的 server/discover 提前发现服务端能力。因此，工程设计不能只实现一种固定握手流程，而应先识别协议版本，再进入对应的协商路径。新版变化可查看 官方版本说明[2]。
二、服务端如何声明真实能力
服务端应坚持“只声明已完整实现并通过测试的能力”。如果声明支持 tools、resources、prompts、通知、缓存或扩展功能，就要确保相关方法、参数校验、错误响应和生命周期行为保持一致。🚦 只实现部分逻辑却提前暴露能力，会让客户端进入错误分支，其危害通常大于直接声明不支持。
- 能力粒度要清晰：区分工具调用、列表更新、订阅、缓存和异步任务等不同特性，不要使用一个笼统开关代表全部支持。
- 工具描述要稳定：工具名称应保持唯一，输入结构应明确必填字段、类型和约束，避免客户端只能依赖自然语言猜测参数。
- 能力变化要可感知：工具目录发生变化时，按所采用协议版本使用通知、重新发现或缓存失效机制。
- 未知字段要保持兼容：解析请求时允许出现不影响语义的扩展字段，但对关键字段仍需严格验证。
三、客户端建立分层兼容模型
客户端不应把“连接成功”等同于“所有功能可用”。更稳妥的做法是建立能力快照，将服务端返回的协议版本、基础能力、扩展标识、工具清单和缓存策略保存在当前连接或服务实例上下文中。后续每次调用都先查询快照，再决定是否展示入口、发送请求或采用替代流程。
- 协议层降级：优先使用双方共同支持的版本；若无法匹配，应明确返回版本不兼容，而不是继续发送格式不确定的请求。
- 能力层降级：服务端未提供 tools 时，隐藏工具调用入口；不支持列表变更通知时，改用定时刷新或用户手动刷新。
- 交互层降级：不支持服务端发起的补充信息请求时，客户端可在调用前收集完整参数，减少执行过程中的二次交互。
- 功能层降级：异步任务不可用时，仅对耗时可控的操作退回同步调用；预计会超时的任务应停止执行并给出说明。
- 展示层降级：客户端无法渲染富媒体或扩展 UI 时，优先显示结构化文本摘要和可下载结果。
四、工具调用中的实际降级策略
假设客户端准备调用“企业知识库搜索”工具，首先应检查服务端是否声明工具能力，然后验证目标工具是否存在，并根据其输入结构生成参数。若工具不存在，可以刷新一次工具目录；刷新后仍不存在，则提示当前服务未提供该能力，不能用名称相似的工具自动替代，因为两个工具可能拥有完全不同的数据权限和副作用。
如果服务端返回“方法不存在”，客户端可将对应能力标记为暂时不可用，避免同一会话反复重试；如果返回参数错误，应重新校验参数结构，而不是切换协议版本；如果遇到限流、超时或临时故障，可采用次数有限的指数退避。⚠️ 对创建、付款、删除、发布等具有副作用的工具，除非服务端提供幂等依据，否则不得自动重试。
降级的目标不是不惜代价完成调用，而是在能力不足或实现不一致时，保持行为可预测、权限不扩大、数据不被误写。
五、版本与扩展兼容的工程原则
客户端应把未知能力视为“尚未支持”，而不是“默认可用”；服务端应忽略不影响核心处理的未知客户端能力，同时拒绝无法安全解释的关键参数。对于 Tasks、MCP Apps 等可选扩展，应采用显式启用、双方支持后生效的策略。新版规范将扩展定义为可选机制，相关边界可参考 MCP 规范[3]。
建议在代码中将版本适配器、能力判断器和工具执行器分离。版本适配器负责请求格式，能力判断器负责计算功能开关，工具执行器只处理业务调用。这样新增协议版本时，不必在每个工具中堆叠条件判断，也便于逐步移除过期兼容逻辑。
六、测试与可观测性不可缺少
测试矩阵应覆盖新客户端对旧服务端、旧客户端对新服务端、能力缺失、未知扩展、工具清单变化、无效参数、超时、重复请求和中途取消等场景。🧪 除成功率外，还应记录协商版本、发现能力、降级原因、工具名称、错误类型和重试次数，但日志中不要保存访问令牌、完整提示词或敏感业务参数。
在上线策略上，可以先让客户端同时支持新旧协议路径，再逐步升级服务端；通过指标观察旧版本调用占比和降级触发情况，最后按正式弃用周期移除旧实现。这样比一次性切换更容易定位问题，也能避免把协议升级变成全量中断。
总结
可靠的 MCP 工具调用建立在三个基础之上：服务端准确声明能力，客户端按协议版本解释能力，任何降级都遵守安全和可预测原则。✅ 将能力协商视为运行时契约，并配合分层降级、幂等控制、兼容测试和可观测性，才能让 AI 客户端在不同服务端、不同版本及不同扩展组合下稳定运行，而不是把兼容性寄托在偶然成功的调用上。
