modelcontextprotocol/go-sdk¶
仓库：modelcontextprotocol/go-sdk
这个项目在系统里负责哪一层¶
官方 Go SDK 负责的是 MCP 协议层。它解决的问题是：如果你要认真理解 MCP 在 Go 里怎么落，哪些对象属于协议本体，哪些只是宿主环境适配。
它不是高层脚手架，更像协议实现。server、client、transport、auth、JSON-RPC 模型被明确拆开，目的就是让你看清 MCP 作为跨边界协议到底需要哪些正式部件。
先抓整体结构¶
比较合适的阅读顺序是：
- server 最小例子。
- client 如何连接。
- transport 和 auth。
- 再回头看包结构和模型对象。
这个顺序能避免一个常见误区：只记住包名，却没建立“连接、协商、请求、响应”这条协议主线。
一条典型执行链¶
一条 MCP 交互通常这样跑：
- client 和 server 先通过某种 transport 建立连接。
- 双方协商支持的能力和可用对象。
- client 发现工具、资源或 prompts。
- client 发起结构化请求。
- server 做认证、校验、执行，并返回结构化响应。
这条链的重要提醒是：MCP 不是“多暴露几个函数”，而是一套带连接、协商和传输语义的协议系统。
值得学的设计¶
这个 SDK 最值得学的是边界拆分。工具 schema、连接建立、能力协商、认证、请求响应模型都被当成独立层，而不是揉进某个 Web 框架 helper。对 Go 团队来说，这一点很值钱，因为 Go 项目最怕“看起来简洁，实际把边界全糊掉”。
它还会提醒你，协议理解不能只看 server。只看 server，你容易以为自己只是写了几个工具暴露出去；把 client 一起看，才知道互操作真正依赖的是什么。
适合借回自己项目的点¶
- 协议层和业务层分开。
- transport 不要直接等同于某个框架适配。
- 工具 schema、认证和能力协商当成正式边界。
- 同时站在 client 和 server 两边思考接口设计。
不要照抄的地方¶
- 不要为了同进程内部调用也硬上 MCP。
- 不要把 transport 绑定死在某个 Web 框架对象上。
- 不要只看 server 不看 client。协议理解必须两边一起看。