PrefectHQ/fastmcp¶
这个项目在系统里负责哪一层¶
FastMCP 负责的是 MCP server 的高层开发框架。它解决的问题是：如果你现在更在意原型速度，而不是先把协议细节全部摊平，能不能快速把一个 MCP server 搭出来。
它更像加速器，不像协议教科书。适合原型期，但不适合替代你对协议边界的理解。
先抓整体结构¶
读这个项目时，比较合适的顺序是：
- 最小工具 server。
- resources 和 prompts。
- client。
- transport、auth 和 lifecycle。
这个顺序能让你先看到高层封装为什么顺手，再回头确认哪些复杂度只是被框架收起来了，没有消失。
一条典型执行链¶
一条 FastMCP 链路通常这样跑：
- 你把 Python 函数或对象声明成工具、资源或 prompt。
- 框架自动生成 schema，并默认带上校验。
- server 通过选定的 transport 暴露能力。
- client 连接后发现这些对象，并按 MCP 协议调用。
- 框架负责一部分 metadata、validation 和 lifecycle。
对原型期来说，这条链很舒服，因为很多样板代码都被拿掉了。
值得学的设计¶
FastMCP 最值得学的是默认值设计。schema 自动生成、validation 默认开启、protocol lifecycle 由框架兜底，这些都不是小便利，而是在逼你从第一版起就把接口做得更正式。
这类设计的工程价值很直接。原型期最容易出现的问题是“先随便跑通，后面再补”。FastMCP 的很多默认行为，刚好是在帮你减少这种债务。
但它最需要反向提醒的地方也在这里。框架帮你生成 schema，不代表权限、审计、租户隔离和高风险动作治理已经自动完成。它只是把协议层样板代码拿掉了，没有替你完成业务治理。
适合借回自己项目的点¶
- 对外接口尽量默认带 schema 和 validation。
- 原型期也把 metadata、auth、lifecycle 当正式能力。
- 高层脚手架可以提速，但要明确哪些底层概念自己仍然得懂。
不要照抄的地方¶
- 不要把高层 ergonomics 误当成协议理解已经到位。
- 不要因为框架帮你生成 schema，就放松权限和审计治理。
- 不要在复杂跨语言互通场景里完全跳过底层 MCP 模型。