MCP Go SDK 路线图深度解析：SEP-1730 Tier 1 评级、Sampling With Tools 与 OAuth 授权扩展的落地路径

MCP Go SDK 路线图深度解析SEP-1730 Tier 1 评级、Sampling With Tools 与 OAuth 授权扩展的落地路径【免费下载链接】go-sdkThe official Go SDK for Model Context Protocol servers and clients. Maintained in collaboration with Google.项目地址: https://gitcode.com/GitHub_Trending/gosdk23/go-sdk本篇技术指南以仓库 ROADMAP.md 为骨架系统解读 MCP Go SDK 官方路线图v1.4.0 时代锁定的三大焦点SEP-1730 Tier 1 SDK 评级、SEP-1577 Sampling With Tools、客户端 OAuth 支持、实验特性 SEP-1686 Tasks以及 ext-auth 授权扩展Enterprise Managed Authorization 与 OAuth Client Credentials。读完你将掌握每个路线图条目的技术内涵、对应的源码与测试位置以及它们在当前仓库中的实际落地状态可用于评估 SDK 能力边界、制定依赖选型与升级计划。路线图概览定位与版本语境ROADMAP.md 是 MCP Go SDK 官方维护者对短期当前焦点与中长期未来工作、实验特性、扩展技术方向的公开声明。阅读它之前必须先建立版本坐标系路线图中规划的 v1.4.0 条目以 2025-11-25 版 MCP 规范为基准而仓库 README 的版本兼容表显示 SDK 已演进到 v1.7.0对应 2026-07-28 规范SDK 版本最新 MCP 规范全部受支持的 MCP 规范v1.7.02026-07-282026-07-28、2025-11-25*、2025-06-18、2025-03-26、2024-11-05v1.4.0 - v1.6.12025-11-25*2025-11-25*、2025-06-18、2025-03-26、2024-11-05v1.2.0 - v1.3.12025-11-25**2025-11-25**、2025-06-18、2025-03-26、2024-11-05v1.0.0 - v1.1.02025-06-182025-06-18、2025-03-26、2024-11-05* 客户端侧 OAuth 为实验性支持** 对 2025-11-25 仅部分支持客户端 OAuth 与 Sampling with Tools 不可用。这意味着路线图中的计划中条目在仓库当前状态中大多已落地为实验支持或正式实现下文将逐条对照源码验证。当前焦点v1.4.0 的三大里程碑SEP-1730冲刺 Tier 1 SDK 评级路线图将 SEP-1730上游 issue #675列为第一优先目标是让本 SDK 被评为Tier 1 SDK即对 MCP 规范的符合性达到最高级别。这一目标的工程支撑在仓库中清晰可见——SDK 维护了一整套系统化的符合性测试资产conformance/everything-server/main.go 与 conformance/everything-client/main.go一个全功能参考服务端/客户端覆盖规范要求的能力面conformance/baseline.yml符合性基线配置mcp/testdata/conformance/server/ 下的 txtar 测试用例集discover.txtar发现、lifecycle.txtar生命周期、tools.txtar、prompts.txtar、resources.txtar、mrtr.txtar、version-latest.txtar/version-older.txtar版本协商、bad_requests.txtar异常请求、spec-sep-973-additional-metadata.txtar附加元数据scripts/server-conformance.sh 与 scripts/client-conformance.sh可直接运行的符合性验证脚本。配合 mcp/conformance_test.go这些资产让每个新版本都能自动回归验证协议行为。从源码结构看这套全功能 server txtar 用例 脚本的组合正是为 Tier 1 评级准备的合规性证据链。SEP-1577实现 Sampling With Tools路线图称Sampling With Tools是补齐 2025-11-25 MCP 规范完整范围的最后一个 SEP。通俗地讲它允许 server 在向 client 发起 sampling模型采样请求时把可用工具及其调用策略一并传给模型使模型能在采样过程中直接产出工具调用Tool Use与工具结果Tool Result消息。该能力在当前仓库中已是完整实现并带全套测试的状态核心证据集中在 mcp/sampling_test.goTestSamplingWithTools_ToolUseserver 通过CreateMessageWithTools发起采样CreateMessageWithToolsParams携带Messages[]*SamplingMessageV2、Tools[]*Tool含名称、描述、JSON Schema 输入定义与ToolChoice{Mode: auto}client 侧通过CreateMessageWithToolsHandler回调响应返回CreateMessageWithToolsResult其内容可包含ToolUseContent{ID, Name, Input}并以StopReason: toolUse标记TestSamplingWithTools_ToolResult/TestSamplingWithTools_ToolResultWithError覆盖工具结果回传SamplingMessageV2中可携带ToolResultContent{ToolUseID}消息以及工具失败场景的兜底文本TestSamplingToolsCapabilities验证能力协商的三种路径——client 显式声明Capabilities.Sampling.Tools SamplingToolsCapabilities{}、未声明时由 handler 自动推断、以及完全不支持时禁用。协议方法常量在 mcp/protocol.go 中定义为methodCreateMessage sampling/createMessage。需要特别注意sampling以及 roots、logging已自 2026-07-28 协议起被上游 SEP-2577 弃用SDK 在至少 12 个月的弃用窗口内继续兼容支持见 README.md 版本兼容表下方说明。mcp/sampling_test.go 文件头部的lint:file-ignore SA1019注释即明示这些测试演练的是已弃用但仍需保障兼容的 API。因此如果你是 2026-07-28 协议的新用户应优先考虑替代方案若运行旧协议服务则可继续依赖本实现。OAuth 支持补齐规范要求的授权解决方案路线图指出客户端侧 OAuth是按规范提供授权解决方案所需的最后一块功能。仓库中这一目标的落地横跨两个包auth/ 包定义授权基础原语。auth/client.go 中的OAuthHandler接口规定transport 若要支持 OAuth 2 授权就应配置一个OAuthHandler由它负责执行 OAuth 流程以获取访问令牌。具体实现包括 auth/authorization_code.go授权码流程其PreregisteredClient字段使用oauthex.ClientCredentials表示预注册客户端与 auth/oidc_login.go 等oauthex/ 包OAuth 协议扩展如 resource_meta.goProtectedResourceMetadata、dcr.go动态客户端注册、token_exchange.go令牌交换、audience.go受众声明。同时 go.mod 依赖golang.org/x/oauth2 v0.35.0与golang-jwt/jwt/v5为 JWT 与标准 OAuth2 流程提供底层支撑。对照 README 兼容表* 注Client side OAuth 已有实验支持可确认该路线图条目已进入实验支持阶段。从源码结构可以推断transport 层挂载OAuthHandler的统一设计正是为了让流式Streamable HTTP/SSE与命令式 transport 都能无差别地获得授权能力。未来工作等 tiering 体系就位后重绘蓝图路线图明确表示一旦 tiering分级体系落地将起草新路线图以描述长期战略其中可能包含下一节列出的实验特性或对 MCP 规范的扩展。这句话点出了 SDK 治理节奏的核心逻辑——路线图与规范分级体系强绑定规范的演进如 SEP-2577 弃用、2026-07-28 协议引入的resultType标注见 mcp/protocol.go 中completeResultWithType相关实现会直接改写 SDK 的优先级。这意味着读者应把本 ROADMAP 视作阶段性快照长期策略以新版本发布时更新后的文档为准。实验特性SEP-1686 Tasks路线图将Implement TasksSEP-1686上游 issue #626标记为实验性。Tasks 面向的是将长时间运行、可跨会话的任务作为一等公民纳入 MCP 的设想。需要如实说明在当前仓库源码中尚未检索到 Task 相关的实现或测试文件因此它仍处于实验构想阶段未进入mcp包的可导入 API。判断依据是搜索mcp/目录下无Task相关符号且路线图自身即将其标注为 experimental。建议关注后续 release 的 release notes以该 SEP 正式落地为准。扩展Authorization extensionsext-auth路线图单列Authorization extensions章节指向上游 ext-auth 扩展体系。这些扩展在仓库中对应的实体是 auth/extauth/ 子目录内含三组实现及配套测试Enterprise Managed Authorization进行中Enterprise Managed Authorization上游 issue #628对应 auth/extauth/enterprise_handler.go。路线图标注其状态为In progress关联上游 PR #770。从命名与同目录实现模式可以推断它旨在为企业托管授权场景提供专用的OAuthHandler风格实现——即授权端点、令牌端点由企业侧托管SDK 客户端只负责按规范完成握手。配套的 auth/extauth/enterprise_handler_test.go 表明该处理器已具备可测试的稳定形态。OAuth Client Credentials客户端凭证OAuth Client Credentials上游 issue #627对应 auth/extauth/client_credentials.go配套测试见 auth/extauth/client_credentials_test.go。这是 OAuth 2.0 的 client credentials 授权类型在 MCP 场景下的落地典型用于机器对机器M2M的授权调用——server 以自身身份而非终端用户身份获取令牌。其类型定义oauthex.ClientCredentials同时被 auth/authorization_code.go 复用为预注册客户端的载体说明该扩展与核心授权流程是同一类型体系内的一体化设计。如何在当前仓库中跟进与验证阅读规范映射文档docs/ 目录如 docs/protocol.md、docs/server.md将 MCP 规范逐条映射到各包 API是理解 SEP 落地细节的权威入口design/ 下的设计文档如 design/mrtr.md记录了对新特性的设计推演。运行符合性验证直接执行 scripts/server-conformance.sh 与 scripts/client-conformance.sh即可复现 Tier 1 评级所依赖的合规检查流程。学习参考实现examples/ 目录覆盖 serverbasic、everything、sse、streamable 等与 clientlistfeatures、middleware 等两侧examples/auth/ 下的 client/enterprise/server 三个示例专门演示授权相关用法。跟踪测试驱动的事实mcp包内*_test.go文件如 mcp/sampling_test.go、mcp/conformance_test.go是每个能力是否真正可用的最直接证据比任何文档都更及时。综上这份路线图既是一份待办清单也是 SDK 与 MCP 规范演进的编年史SEP-1730 与 SEP-1577 已在仓库中得到系统性实现与测试支撑OAuth 已进入实验支持ext-auth 扩展正在成型而 Tasks 仍在实验构想期。依赖本 SDK 的项目可按此脉络评估若面向 2026-07-28 协议应优先关注规范弃用项roots/sampling/logging的迁移若运行旧协议服务则 sampling、OAuth 等路线图能力均可直接使用。【免费下载链接】go-sdkThe official Go SDK for Model Context Protocol servers and clients. Maintained in collaboration with Google.项目地址: https://gitcode.com/GitHub_Trending/gosdk23/go-sdk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考