官方 MCP SDK: 协议分层与能力契约¶
MCP (Model Context Protocol) 不是另一种工具调用框架，它是跨进程/跨语言的能力暴露协议。官方 SDK 的核心任务是实现协议骨架：处理 Transport、Session 握手与 Capability 发现，而不是替你做业务治理。
1. 协议执行链：从握手到调用¶
不要跳过 Initialize 阶段直接谈工具调用。MCP 的生命周期是极度严谨的：
- Transport 建立：选择传输层（Stdio、HTTP/SSE）。这一层只管“字节如何搬运”，不涉及业务逻辑。
- Initialize (初始化)：Client 与 Server 交换版本信息。
- Capability Discovery (能力发现)：Server 宣告自己拥有的资源（Resources）、工具（Tools）与提示词（Prompts）。工程直觉：Client 不应凭空猜测 Server 会什么，一切以 Session 内的发现结果为准。
- Structured Call (结构化调用)：基于 JSON-RPC 2.0 协议进行具体交互。
2. 核心对象与受力面¶
- Session：协议的上下文实体。它承载了初始化后的能力视图与认证状态，是长连接中的“共享现实”。
- JSON-RPC 层：将异构的消息搬运（Transport）与上层的语义调用解耦。无论底层是标准输入输出还是网络套接字，上层的 Tool Call 格式保持一致。
- Auth (接入鉴权)：SDK 提供认证钩子，但注意：认证不等于授权。SDK 负责确认“你是谁”，宿主系统仍需自行负责“你能不能用这个工具”。
3. 工程防腐：SDK 到底不负责什么？¶
很多开发者容易把 MCP SDK 误当成“中台”。必须明确其职责边界：
- 不负责 Planning：SDK 不管 Agent 怎么拆解任务。
- 不负责 Guardrails：SDK 不会自动拦截危险命令，安全护栏（Hooks）必须由宿主应用实现。
- 不负责持久化：Session 是内存态的，会话的持久化与恢复是上层运行时的责任。
4. Go 与 TypeScript 的风格差异¶
- Go SDK：侧重于后端服务的稳定性。代码结构（
jsonrpc/,auth/）切分极硬，适合构建长生命周期的 MCP Server。 - TypeScript SDK：侧重于前端/Node.js 宿主的适配性。通过 Middleware 模式提供更灵活的包装能力。
- 共同点：两者的协议状态机（State Machine）完全同步，确保了跨语言的互操作性。
5. 排查顺序：从通道到语义¶
- 查 Transport 通道：JSON 字节流是否能在 Stdio/SSE 间正常往返？是否有权限导致的进程启动失败？
- 查 Initialize 响应：
capabilities字段是否包含了预期的工具？Schema 版本是否匹配？ - 查 JSON-RPC 报错：是方法名写错了（
-32601），还是参数校验未通过（-32602）？ - 查宿主治理：协议通了但返回 403，通常是宿主层的 Token 注入或权限 Scope 逻辑出问题。
结论： MCP SDK 负责互通，宿主负责治理。好的架构是让 SDK 守住协议契约，确保能力发现的动态性，将复杂的业务鉴权与安全审计留给应用层。