Python 版 MCP server 和 TS 版差异在哪？给团队选型的参考

公司 AI 平台组的 lead 上个月让我写个技术选型报告。

背景：团队要推一批内部 MCP server 给各业务线用，后端组 Python 强、前端和 infra 组 TS 强，到底哪个语言做标准栈？lead 的原话是”别拍脑袋，给我跑数据”。

我搞了三天，用 TS 和 Python 各搓了一版同功能 MCP server（操作公司内部 GitLab 和 Confluence），把启动时间、内存、开发体验、部署复杂度都量化了一下。结论有点反直觉。

FastMCP：Python 生态的主力框架

Python 官方也有 mcp 包，但真正好用的是 FastMCP（现已并入官方 SDK 的 mcp.server.fastmcp 命名空间）。装饰器风格，写起来比 TS 版还短。

1

pip install mcp

一个等价的 weather server：

1
2
3
4
5
6
7
8
9
10
11
12

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather-mcp")

@mcp.tool()
def get_weather(city: str) -> str:
    """查询指定城市当前天气（摄氏度）"""
    # 真实场景调 API
    return f"{city} 当前 17℃，多云"

if __name__ == "__main__":
    mcp.run()

15 行。对比 TS 版的 40 行，行数少了超过一半。

FastMCP 做了几件事：

• 从函数 type annotation 自动生成 inputSchema
• docstring 直接用作 tool description
• 返回值类型自动包装成 MCP content 结构
• transport 默认 stdio，一行 mcp.run() 起服务

Python 这边”约定优于配置”做得比 TS 版 SDK 激进得多。好处是简洁，坏处是你想定制就得翻源码。

异步 vs 同步默认行为

这是 Python 版一个挺隐蔽的坑。

TS 版因为 JS 天生异步，handler 默认都是 async，没什么心智负担。Python 版 FastMCP 会自动识别你的函数是不是 coroutine——如果你写 def get_weather 就是同步调用，写 async def get_weather 就走 asyncio。

问题在于：同步 handler 会阻塞整个事件循环。

我踩过一次，一个 GitLab MCP server 的 search_issues tool 内部调了 requests.get（同步 HTTP），上线后同一个 Agent 只要并发发两个请求，第二个就要等第一个走完。延迟从预期 420ms 飙到 890ms。

改成 async def + httpx.AsyncClient 之后恢复正常。

所以我的建议：Python 版 MCP server 所有 IO 操作都用 async，除非你确定这个 tool 只会被串行调用。TS 版没这问题，不用考虑。

实测对比：TS vs Python

两版同功能 server（6 个 tool，对接 GitLab），在我的 M2 Pro 上测：

冷启动 Python 慢 2.25 倍，主要是 import 开销。如果你的 MCP server 是短命进程（比如 Claude Desktop 场景每次启动都 spawn），这个差距会被放大——我测过一个 Claude Desktop 会话平均 spawn MCP server 9 次（窗口切换、idle 超时等），累计 TS 省下约 2.1 秒。

但如果是常驻服务（streamable HTTP 部署），启动时间只付一次，没区别。

内存差距在单台机器跑十几个 MCP server 的场景下会吃掉明显的 RAM。我们内部平台跑了 23 个 server，全换成 Python 的话内存比 TS 高 550MB+。

开发体验：Python 明显更爽

代码行数差了一倍，这是实打实的。

Python 版的装饰器让你几乎感觉不到 MCP 协议的存在，写起来像在写普通函数。TS 版虽然 SDK 已经够简洁，但 setRequestHandler + inputSchema 手写还是有仪式感。

迭代速度上：

• Python：改代码保存，Claude Desktop 重启客户端就行
• TS：改代码 → tsc 编译 → 重启客户端（如果不用 tsx watch 的话）

给初级工程师上手，Python 版 4 小时能产出第一个 tool，TS 版平均要 7-8 小时（主要卡在 zod schema 和 handler 注册的样板）。

部署：Python 才是真的坑

这是我这次选型的重大发现——开发爽归开发爽，部署 Python MCP server 比 TS 麻烦得多。

具体问题：

虚拟环境：Claude Desktop 或任何 MCP 客户端去 spawn 你的 server，默认是系统 Python。如果你的 server 装在 venv 里，客户端找不到依赖。解决方案有几种：

• uv 启动：command: uv, args: [run, server.py]，现在主流做法
• shebang 硬写 venv 路径：#!/path/to/venv/bin/python3，移植性差
• 打包成 wheel 然后 pipx install：最规范，但流程长

PyInstaller 打单文件：理论上能打，实际上 MCP SDK 依赖了一堆 native 扩展（比如 pydantic 的 C 加速），打出来经常运行时报错。我试过三次，每次都能跑出不同的神奇 bug。

TS 这边：node dist/index.js 直接跑，或者 npx ncc build 打成单文件 bundle 就结束了。客户端只要有 node，无所谓 npm global 装没装。

选型结论

按这三天的实测，我给 lead 的建议是：

选 Python 的场景：

• 数据处理密集型 server（比如对接 pandas/numpy/ML 模型）
• 团队是纯后端/数据团队，JS 栈不熟
• 已有 Python 业务逻辑直接封装成 MCP

选 TS 的场景：

• 桌面 Claude Desktop 大量用户分发（部署简单、启动快）
• 内存敏感环境（边缘部署、一台机器跑多个 server）
• 团队有 Node.js 工具链

混用也行：我们最后定的策略是核心平台 tool 用 TS，AI/数据相关 tool 用 Python，两边走统一的注册中心。

想看 TS 版详细实现参考我的另一篇 TS 从零搓 MCP server，上面的 40 行代码模板就是起步。如果你在 Claude Code 里挂这些 server，Claude Code MCP 集成 那篇讲了两种语言 server 配置的微妙差异。

一个给团队的小建议

不管选哪边，MCP server 的 tool 描述和参数设计是跨语言的。这部分时间投入远比纠结语言重要。我们团队现在维护一个”MCP server review 清单”，每个 tool 上线前走 7 个检查点——描述够不够短、参数够不够少、错误处理够不够明确。MCP Server 内置工具设计 里聊过类似原则。