📌 项目地址：PrefectHQ/fastmcp | ⭐ 26,457 颗星 | 🔧 Python | 📜 未标注
一个函数搞定MCP
先看最核心的代码：
from fastmcp import FastMCP
mcp = FastMCP("Demo 🚀")
@mcp.tool
def add(a: int, b: int) -> int:
"""Add two numbers"""
return a + b
if __name__ == "__main__":
mcp.run()这段代码来自README，跑起来之后，任意MCP客户端都能调用add函数。你不需要写Schema定义，不需要配置JSON-RPC消息格式，不需要操心传输层是stdio还是SSE。函数参数的类型注解自动生成工具Schema，函数的docstring自动成为工具描述。
这就是FastMCP的核心设计：你写Python函数，框架处理MCP协议。
为什么有存在的必要
MCP协议本身只有三层：JSON-RPC通信格式、传输层（stdio或SSE）、工具Schema定义。单看每一层都不复杂。但把它们和业务逻辑搅在一起，会出现几个实际问题：
第一，Schema维护成本高。 每写一个接口，就要手动维护一份JSON Schema文档。函数签名改了，Schema没同步，客户端调用的参数就错了。
第二，传输层有暗坑。 是走本地stdio还是远程SSE？连接断了怎么重试？认证怎么处理？生命周期怎么管理？这些细节堆起来，比业务逻辑还费时间。
第三，文档滞后。 功能改完了，开发者忘了更新文档，客户端拿到的是过时的接口信息。
FastMCP的逻辑是：把MCP的复杂度封装到框架里，开发者只关心函数本身。README里说得很直接，“Declare a tool with a Python function, and the schema, validation, and documentation are generated automatically”。
三个组件解决三类场景
FastMCP把功能拆成Servers、Apps、Clients三个模块，分别覆盖MCP工作流的不同环节。
Servers：把Python函数包装成MCP的工具、资源、prompt。这是最常用的模块。你定义函数，框架负责协议部分。本地跑或远程部署都行。详细用法看官方文档的Servers章节。
Apps：给工具加上交互界面。不是纯文本返回，而是对话里直接出现的按钮、表单。用户要填个参数、做个确认，不用写聊天逻辑，工具自己处理交互。适合需要用户决策的场景。具体看Apps文档。
Clients：连接服务端的编程接口和CLI工具。内置认证、超时、重连机制。你可以从代码里调用其他MCP服务，也可以用命令行测试协议是否合规。文档在Clients章节。
这三个模块单独能用，组合起来也能用。定义工具、提供交互界面、作为服务端被消费，一套框架走完，不用拼凑不同库。
数据说明成熟度
项目当前26,457个star。Prefect官方数据是日下载量百万次，跨语言的MCP服务器里，约70%用了某个版本的FastMCP。2024年FastMCP 1.0被官方MCP Python SDK吸收，但独立版本一直在迭代。
这些数据说明两个事：一是解决了真实问题，很多人用；二是代码质量经过验证，不是试验品。
商业产品解决什么问题
Prefect做了个商业产品叫Prefect Horizon，README提到它主要做三件事：
- 从GitHub部署FastMCP服务器，有分支预览和即时回滚
- 用SSO做工具权限控制，记录审计日志
- 把工具组合成不同端点，分给不同团队或Agent
项目本身是MIT协议，个人或小团队直接用免费版。需要企业级治理的，考虑付费版。
我试下来的感受
跑本机测试，十分钟能验证功能通不通。mcp.run()启动后，客户端直接连就能调工具。
如果你第一次碰MCP，直接复制README里的代码跑一下。然后根据场景看对应文档：
Python 3.8+，MIT协议，当前1.x稳定版。跟踪更新看GitHub Releases。
一个建议
别去手动拼JSON-RPC消息。用FastMCP，写函数就完了。