MCP 常见问题
本页回答实施 MCP 时常见且可以从当前规范核验的问题。协议行为以 2026-07-28 当前文档及对应规范为准。
版本与规范
当前应实现哪个版本？
新实现应以 2026-07-28 为基线，并使用该版本对应的 SDK 和扩展文档。客户端与服务器仍需通过初始化或发现流程协商双方实际支持的协议版本和能力。
历史版本和 SEP 能否作为当前实现依据？
历史规范用于维护旧实现或理解协议演进。SEP 记录提案的设计背景与裁决，但已发布协议或扩展可能在后续继续变化。实现当前能力时，应回到当前规范、扩展文档和 changelog 核对要求。
Draft 提案是否已经成为协议能力？
不是。Draft 表示提案仍在讨论，不能当作已发布合同。只有在当前规范或正式扩展中出现并完成相应能力协商的功能，才能作为互操作依据。
请求与交互
什么是 MRTR？
多轮往返请求（MRTR）允许服务器以 InputRequiredResult 结束当前请求，并让客户端在获得所需输入后重试原方法。每次重试必须使用新的 JSON-RPC ID；requestState 必须由客户端原样回传，客户端不得检查、解析或修改它。
什么是信息征询（elicitation）？
信息征询让服务器请求用户提供完成操作所需的信息。表单模式用于结构化输入；URL 模式用于在客户端之外完成敏感交互。客户端应清楚展示请求来源和用途，并且只在用户明确接受 URL 模式请求后打开 URL。用户拒绝或取消时，客户端必须把 decline 或 cancel 响应返回服务器；超时可以按客户端策略映射为 cancel。服务器据此决定替代方案、稍后提示或结束操作。
Tasks 与普通业务任务有什么区别？
Tasks 扩展是长时间运行请求的协议扩展，提供持久句柄、状态轮询、执行中输入和延迟取回结果。应用中的待办事项、工单或作业记录只是业务数据，除非实现并协商 Tasks 扩展，否则不属于协议 Tasks。
SEP-1686保留了 Tasks 早期进入核心协议时的历史设计。2026-07-28 已将 Tasks 迁移为官方扩展，新实现应使用当前扩展标识和协商方式。
授权与安全
MCP 是否要求所有服务器使用 OAuth？
本地 stdio 服务器通常依赖宿主和操作系统的本地安全边界。受保护的远程 HTTP 服务器应按当前授权规范发布受保护资源元数据，并使用适合客户端类型的 OAuth 流程。
客户端如何发现授权服务器？
客户端优先使用 401 Unauthorized 响应中 WWW-Authenticate 的 resource_metadata 参数。缺失时，再按规范顺序尝试受保护资源的 well-known URI。取得授权服务器元数据后，必须验证 issuer；请求 token 时应携带目标 resource，服务器必须拒绝 issuer、resource 或 audience 不匹配的凭据。
一个客户端能否复用不同授权服务器的注册信息？
不能。客户端 ID、客户端凭据和 token 都绑定到签发它们的授权服务器。PRM 列出多个授权服务器时，客户端必须分别保存每个服务器的注册状态和凭据。
使用 MCP 是否自动满足安全或合规要求？
不会。协议提供互操作机制，不替代应用的身份认证、授权、输入校验、用户确认、审计、数据保留和合规评估。实现应遵循最小权限，验证所有外部输入和 token，禁止 token 透传，并避免在日志中记录凭据或敏感数据。
故障处理
初始化或能力调用失败时先检查什么？
先确认客户端与服务器协商出的协议版本、传输方式和能力声明，再核对失败方法是否属于已声明能力。保留 JSON-RPC 错误码、HTTP 状态、相关 ID 和已脱敏日志，用它们区分版本不匹配、能力未协商、输入无效和服务器内部错误。
远程授权反复失败时如何定位？
依次检查 PRM 地址、授权服务器发现端点、元数据 issuer、客户端注册归属、redirect URI、PKCE、scope、resource 参数以及 token 的 audience。不要通过放宽 issuer 或 audience 校验来绕过问题。
分页 cursor 或缓存失效时怎么办？
每个 cursor 页面独立缓存。cursor 被服务器拒绝后，客户端应丢弃该列表的全部缓存页面，并从不带 cursor 的第一页重新获取；收到相关变更通知时，即使 TTL 尚未到期也应立即使缓存失效。
在哪里报告无法复现或疑似规范问题？
先用最小请求和脱敏日志确认问题属于规范、SDK 还是具体实现，再到对应仓库提交可复现示例。一般讨论可以进入 MCP GitHub Discussions。