modelcontextprotocol/typescript-sdk¶
仓库：modelcontextprotocol/typescript-sdk
这个项目在系统里负责哪一层¶
它负责的是 MCP 在 TypeScript 和 Node 生态里的协议实现。这个项目最大的价值，不是“Node 里也能跑 MCP”，而是非常直接地告诉你：协议层和宿主运行时适配层必须分开看。
很多人一上来就看 Express 或 Hono 示例，然后误以为自己已经理解 MCP。这个仓库最重要的作用，就是纠正这种误会。
先抓整体结构¶
比较合适的顺序是：
- 先看一个 Streamable HTTP 示例。
- 再看 stdio。
- 回头看
server、client、运行时适配和 schema 校验的拆分。
只有两种 transport 都看过，你才会知道什么是协议主干，什么只是宿主环境的承载方式。
一条典型执行链¶
一条链路通常这样跑：
- server 通过某种 transport 暴露工具、资源或 prompts。
- client 建立连接并协商能力。
- client 发现可用对象，按 schema 发起请求。
- server 校验输入、执行逻辑并返回结构化结果。
- transport 负责把协议消息安全地带过当前宿主环境。
这个过程和 Go SDK 是同一条协议主线，只是宿主环境变成了 Node 生态。
值得学的设计¶
这个仓库最值得学的是包拆分。server、client、Node 运行时适配、schema 校验工具被明确分开，刚好对应四件不同的事：协议角色是谁，连接双方怎么互动，宿主环境怎么承载 transport，输入输出怎样被正式约束。
这件事放到工程里很重要。很多团队最后做着做着只剩下“某个 Web 框架 demo 能跑”，问题通常不是框架不好，而是协议边界没立住。
另一个值得注意的是版本成熟度。协议 SDK 演进通常很快，工程选型不能只看概念新不新，还要看稳定分支、迁移成本和上下游兼容性。
适合借回自己项目的点¶
- 协议主干和 Express、Hono、Node HTTP 这类适配层拆开。
- schema 校验不要只靠口头约定，最好成为正式依赖。
- transport 选择服务互操作性，而不是只服务眼前的宿主框架。
- 看协议实现时，同时关注版本演进和迁移成本。
不要照抄的地方¶
- 不要把某个 Web 示例当成协议本体。
- 不要只盯 API 表面写法，不看包拆分和版本演进。
- 不要把宿主框架的便利性误解成协议层已经设计清楚。