深入解读 SEP-1036：MCP URL 模式 Elicitation 如何实现安全的带外交互

人工智能AI Agent工具调用【免费下载链接】specificationSpecification and documentation for the Model Context Protocol项目地址https://gitcode.com/gh_mirrors/specification2/specification点击查看免费下载本篇文章以 SEP-1036URL Mode Elicitation for secure out-of-band interactions 为核心系统讲解 Model Context ProtocolMCP如何在不经过 MCP 客户端的前提下安全收集敏感凭据、执行第三方 OAuth 授权与支付流程。读完本文你将掌握 URL 模式 Elicitation 的协议消息结构、能力协商方式、响应动作语义、错误处理机制以及客户端与服务端各自必须遵守的安全边界和防钓鱼要点并了解该特性从 2025-11-25 版本引入到 2026-07-28 版本随 Multi Round-Trip RequestsMRTR模式演进后的最新形态。背景与动机为什么需要带外交互MCP 自 2025-06-18 版本起提供了 Elicitation诱导式信息收集机制让服务端可以在处理客户端请求的过程中通过结构化、带内in-band的请求向用户收集非敏感信息——最常见的形态是 MCP 客户端渲染一个表单供最终用户填写。然而有三类关键场景要求交互绝不能经过 MCP 客户端敏感数据收集API Key、密码等凭据绝不允许穿过任何中间系统包括 MCP 客户端与 LLM 上下文。外部第三方授权MCP 服务端经常需要以用户名义访问第三方 API。MCP 授权规范只覆盖客户端到服务端的授权不覆盖服务端到第三方的授权官方 Security Best Practices 文档明确禁止 token passthrough令牌透传。因此必须有一种安全机制来承载外部 OAuth 流程这来自 #234 和 #284 等讨论。支付与订阅流程金融交易需要满足 PCI 合规与安全的支付处理无法通过带内的表单式数据采集实现。在没有标准化机制之前MCP 服务端只能退回到非标准变通方案甚至采用通过带内表单收集 API Key这类不安全做法。SEP-1036 正是针对这些缺口引入了复用成熟 Web 安全模式的 URL 模式 Elicitation。需要特别强调URL 模式 Elicitation 与 MCP 授权是两回事。它不是用于授权 MCP 客户端访问 MCP 服务端那由 MCP 授权规范处理而是用于 MCP 服务端需要代表用户获取敏感信息或第三方授权时。在整个过程中MCP 客户端的 bearer token 保持不变客户端的唯一职责就是向用户展示服务端希望其打开的 Elicitation URL 并获取上下文。两种模式Form 与 URLElicitation 被更新为支持两种模式Form 模式带内服务端通过可选的 JSON Schema 校验向用户请求结构化数据。此模式在既有能力上基本无变化只是为既有能力补上了名称。URL 模式带外服务端将用户引导到外部 URL完成不能经过 MCP 客户端的敏感交互。这一同一机制、两种模式的设计在 2026-07-28 规范中依然保留。官方规范原文见 docs/specification/2026-07-28/client/elicitation.mdx其中明确指出 URL 模式是敏感信息交互密码、API Key、访问令牌、支付凭据的唯一合法通道服务端MUST NOT使用 Form 模式请求此类敏感信息。能力声明与协商支持 Elicitation 的客户端MUST声明elicitation能力。在 2025-11-25 及之前版本中该声明位于初始化阶段的capabilities字段{ capabilities: { elicitation: { form: {}, url: {} } } }在 2026-07-28 版本中协议改为无状态SEP-2575能力声明随每个请求携带在_meta.io.modelcontextprotocol/clientCapabilities中{ _meta: { io.modelcontextprotocol/clientCapabilities: { elicitation: { form: {}, url: {} } } } }向后兼容规则不变空的能力对象等价于只声明支持form模式{ capabilities: { elicitation: {} // 等价于 { form: {} } } }客户端声明了elicitation能力后MUST至少支持一种模式form或url服务端MUST NOT向不支持对应模式的客户端发送 Elicitation 请求。URL 模式请求规范URL 模式 Elicitation 请求MUST指定mode: url并包含以下参数名称类型说明urlstring用户需要导航到的 URLMUST是有效 URLelicitationIdstringElicitation 的唯一标识符2025-11-25 版messagestring向用户解释为何需要该交互的可读消息版本差异提示elicitationId仅在 2025-11-25 版本中存在。2026-07-28 版本changelog 第 11 条移除了该字段与notifications/elicitation/complete通知详见下文演进小节。典型示例OAuth 授权流程{ jsonrpc: 2.0, id: 3, method: elicitation/create, params: { mode: url, elicitationId: 550e8400-e29b-41d4-a716-446655440000, url: https://github.com/login/oauth/authorize?client_idabc123statexyz789scoperepo, message: Please authorize access to your GitHub repositories to continue. } }相同的请求结构也可以指向输入 API Key 的安全页面或支付页面区别仅在于 URL 与 message 内容。Schema 层面的定义在 schema/2026-07-28/schema.ts 中两种模式的请求参数被建模为可辨识联合类型ElicitRequestFormParamsmode?为可选的form省略时默认为 form携带message与requestedSchema仅允许顶层属性、无嵌套的 JSON Schema 受限子集。ElicitRequestURLParamsmode为必填的url携带message与带format uri标注的url字段。export interface ElicitRequestURLParams { /** The elicitation mode. */ mode: url; /** The message to present to the user explaining why the interaction is needed. */ message: string; /** The URL that the user should navigate to. format uri */ url: string; }从源码结构可以看出URL 模式在类型层面就强制要求mode与url同时存在而 Form 模式允许省略mode以保持向后兼容——这与规范正文的表述完全一致。响应动作模型URL 模式 Elicitation 的响应沿用与 Form 模式相同的三动作模型{ jsonrpc: 2.0, id: 3, result: { action: accept // 或 decline 或 cancel } }三种动作的语义accept用户明确同意并提交。Form 模式content字段携带符合请求 schema 的数据URL 模式content字段必须省略用户提交的数据在带外发生客户端不接触。decline用户明确拒绝content通常省略如点击Reject/Decline/No。cancel用户未做明确选择即关闭如关闭对话框、按 Esc、浏览器加载失败。关键语义action: accept仅表示用户已同意交互不代表交互完成。带外交互的最终结果客户端无从直接得知服务端需要自行判断。完成通知从 2025-11-25 到 2026-07-28 的演进2025-11-25 版本显式完成通知SEP-1036 于 2025-11-25 版本正式落地见 docs/specification/2025-11-25/changelog.mdx 第 6 条。该版本中服务端SHOULD在带外交互完成后发送notifications/elicitation/complete通知使客户端能够程序化响应{ jsonrpc: 2.0, method: notifications/elicitation/complete, params: { elicitationId: 550e8400-e29b-41d4-a716-446655440000 } }规则要点通知MUST只发送给发起 Elicitation 请求的那个客户端通知MUST携带原始elicitation/create请求中的elicitationId客户端MUST忽略引用未知或已完成 ID 的通知若完成通知迟迟不来客户端SHOULD提供让用户手动继续交互的方式且不能无限等待通知投递不保证送达。客户端MAY利用该通知自动重试收到URLElicitationRequiredError的请求、更新界面或继续交互。2026-07-28 版本并入 MRTR 模式随着 SEP-2322MRTR 的引入2026-07-28 版本发生了结构性变化changelog 第 11 条notifications/elicitation/complete通知与elicitationId字段被移除。原因在于MRTR 模式下elicitation/create不再作为服务端发起的独立请求而是被包装在服务端返回的InputRequiredResultresultType: input_required的inputRequests字段中客户端在重试原始请求时通过inputResponses回传结果。客户端通过重试原始请求就能得知带外交互的最终结果服务端发起的完成信号以及用于关联的 ID 便不再契合协议形态。需要跨重试关联 Elicitation 的服务端改为在自己的requestState中编码自有的标识符。MRTR 模式的详细说明见 docs/specification/2026-07-28/basic/patterns/mrtr.mdx其类型定义InputRequiredResult可在 schema/2026-07-28/schema.ts 中查看。该版本中客户端收到accept后重试原始请求时服务端根据回显的requestState或自身存储的状态判断带外交互是否完成并返回最终结果或再次下发InputRequiredResult客户端SHOULD提供手动重试/取消的控件。URL 模式完整消息流2026-07-28 版URLElicitationRequiredError 错误处理当请求在 Elicitation 完成前无法继续处理时服务端MAY返回URLElicitationRequiredError错误码-32042明确告知客户端需要一次 URL 模式 Elicitation。服务端MUST NOT在非此场景下返回该错误。{ jsonrpc: 2.0, id: 2, error: { code: -32042, message: This request requires more information., data: { elicitations: [ { mode: url, elicitationId: 550e8400-e29b-41d4-a716-446655440000, url: https://oauth.example.com/authorize?client_idabc123response_typecode..., message: Authorization is required to access your Example Co files. } ] } } }规则要点错误中返回的 ElicitationMUST全部是 URL 模式且MUST携带elicitationId2026-07-28 版起不再要求该字段返回该错误等价于发送一次elicitation/create请求——这是给客户端的提示使其明确某个 Elicitation 与某个失败的客户端请求直接相关客户端必须将URLElicitationRequiredError视同elicitation/create请求处理可在外交互成功完成后例如收到完成通知后自动重试失败的请求。设计原理与备选方案为什么扩展现有 Elicitation 而非另建机制最初曾考虑为带外交互单独设计一套机制#475 讨论但与 MCP maintainers 沟通后决定扩展现有 Elicitation理由有三两种机制的根本目的相同——向用户收集信息两个相似但不相同的机制并存容易造成混淆与错误mode参数可以干净地区分两种交互模式。为什么客户端不能代为执行交互一个诱人的想法是让 MCP 客户端亲自执行交互例如充当第三方授权服务器的 OAuth 客户端但这不可行若客户端从第三方授权服务器取得用户令牌并转交给服务端服务端就变成了被明确禁止的 token passthrough 服务器对支付类流程客户端将被迫承担 PCI 合规的支付处理责任这不应成为 MCP 客户端的义务。为什么服务端不阻塞等待 Elicitation 完成URL 模式 Elicitation 在设计上就是异步断连式流程因为其承载的交互天然异步支付流程、外部授权可能耗时数分钟甚至可能被用户放弃而永不完成。为什么 Form 模式禁止 URL在规范层面严格限定URL 只能出现在 URL 模式请求的url字段中能显著改善客户端的整体安全姿态客户端可以实现与安全模型一致的 UX 模式例如拒绝把 Form 模式请求中的 URL 渲染成可点击超链接从而降低用户误点恶意服务端发送的恶意 URL 的概率。被否决的备选方案Token Passthrough将 MCP 客户端的令牌直接透传给外部服务或因安全考虑由客户端代取额外令牌再转交服务端——均因 Security Best Practices 中记录的安全问题被否决。OAuth 专用能力曾考虑为第三方 OAuth 授权创建专门能力最终被否决转而采用能覆盖多类用例的更通用的 URL 模式 Elicitation。社区反馈该提案整合了 #475、#234、#284 讨论以及 Discord 上 #auth-wg 工作组的大量社区反馈。社区明确提出了四方面需求不暴露给客户端的凭据安全收集、独立于 MCP 授权的第三方授权模式、支付与订阅流程支持、清晰的安全边界与信任模型。安全影响与实现要求URL 安全要求SSRF 防护客户端必须校验 URL 以防服务端请求伪造Server-Side Request Forgery协议限制URL 模式 Elicitation 只允许 HTTPS URL域名明示客户端必须向用户清晰展示目标域名。信任边界URL 模式 Elicitation 明确建立了三条信任边界MCP 客户端永远看不到服务端通过 URL 模式 Elicitation 获取的敏感数据MCP 服务端必须独立验证用户身份第三方服务通过安全的浏览器上下文与用户直接交互。身份验证服务端必须验证完成 URL Elicitation 的用户与发起该请求的用户是同一人且验证不能依赖来自客户端的不可信输入如用户自述。实现要求清单客户端必须使用可防止用户输入被检视的安全浏览器上下文例如 iOS 上使用SFSafariViewController而非WKWebView校验 URL 以防 SSRF在打开 URL 前取得用户明确同意清晰展示目标域名。服务端必须将 Elicitation 状态绑定到已认证的用户会话在 URL Elicitation 流程开始与结束时验证用户身份实施适当的速率限制。双方应当记录安全事件以供审计为 Elicitation 请求实现超时机制对安全失败提供清晰的错误消息。防钓鱼一个必须防范的攻击场景URL 模式 Elicitation 会返回一个可被攻击者转发的 URL。服务端MUST在接收信息前验证打开该 URL 的用户身份典型的验证方式是借助 MCP 授权服务器通过浏览器会话 cookie 或等价物识别用户。一个典型的钓鱼攻击路径是恶意用户 Alice 连接良性服务端并触发 Elicitation → 服务端生成指向第三方授权服务器的授权 URL → Alice 的客户端展示 URL 征求同意 → Alice 不去点击而是诱骗同一服务端的受害者 Bob 点击 → Bob 误以为是在为自己授权而完成流程 → 服务端收到回调后误认为是 Alice 的请求 → 第三方令牌被绑定到 Alice 的身份造成账户接管。标准缓解做法非规范性示例服务端把 Elicitation URL 指向自己的https://mcp.example.com/connect?...页面而非第三方授权端点该connect 页面校验访问者是否持有与发起 Elicitation 用户一致的有效会话 cookie——例如比对 MCP 授权服务器给出的权威subclaim 与会话 cookie 中的 subject。确认同一用户后再将其引导至第三方授权服务器完成正常 OAuth 流程。若服务端无法通过 Web 访问、无法使用会话 cookie则必须采用其他机制且所有实现都必须保证身份判定机制能抵御攻击者对 Elicitation URL 的篡改。向后兼容与迁移路径SEP-1036 引入了两类破坏性变更能力声明客户端必须显式声明支持的 Elicitation 模式form/url而此前仅声明elicitation: {}mode 参数所有elicitation/create请求必须携带mode参数form或url。迁移建议服务端SHOULD在发送模式相关请求前检查客户端能力客户端MAY初期只支持 form 模式以维持兼容既有 Form 模式实现加上mode参数后即可继续工作省略时默认按 form 处理。从 SEP 到规范的落地验证如果你想在仓库中追踪该特性的完整生命周期可以按以下路径串联提案原文seps/1036-url-mode-elicitation-for-secure-out-of-band-intera.md2025-11-25 版规范含elicitationId与完成通知docs/specification/2025-11-25/client/elicitation.mdx2026-07-28 版规范MRTR 化后的最新形态docs/specification/2026-07-28/client/elicitation.mdx版本变更记录docs/specification/2026-07-28/changelog.mdx类型定义schema/2026-07-28/schema.tsMRTR 模式详解docs/specification/2026-07-28/basic/patterns/mrtr.mdx总结SEP-1036 通过为既有 Elicitation 能力增加 URL 模式为 MCP 补上了安全的带外交互这一关键拼图凭据收集、第三方 OAuth 授权与支付流程从此有了标准化、不经过 MCP 客户端的通道。其核心设计原则——同一机制、两种模式、严格的 URL 安全边界、服务端身份绑定与防钓鱼验证——贯穿了从 2025-11-25 引入到 2026-07-28 随 MRTR 模式重构的整个演进过程。对于 MCP 客户端与服务端的实现者而言理解能力协商、三动作响应模型、URLElicitationRequiredError语义以及客户端/服务端各自的安全义务清单是正确、安全地落地这一特性的前提。赞分享人工智能AI Agent工具调用【免费下载链接】specificationSpecification and documentation for the Model Context Protocol项目地址https://gitcode.com/gh_mirrors/specification2/specification点击查看免费下载相关推荐在 mcp-use 中实现 MCP Elicitation表单确认与外部授权 URL 双模式实战在 mcp use 中实现 MCP Elicitation表单确认与外部授权 URL 双模式实战 本篇技术指南基于 mcp use 仓库中的 Elicitat后端MCP 服务MCP ClientsAI Agent人工智能python-sdk 中的 MCP Elicitation 引导式交互Resolver、表单与 URL 跳转实战python sdk 中的 MCP Elicitation 引导式交互Resolver、表单与 URL 跳转实战 Elicitation引导式交互让 MC人工智能MCP 服务MCP Clientspython-sdk 中的 MCP 询问Elicitation完全指南表单模式、URL 模式与 Resolver 深度解析python sdk 中的 MCP 询问Elicitation完全指南表单模式、URL 模式与 Resolver 深度解析 Elicitation询问人工智能MCP 服务MCP Clients上一篇智能体安全应用Learn-Agentic-AI的应用安全扫描与代码审计系统下一篇终极NES模拟器兼容性测试指南哪些经典游戏能完美运行创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考