frommcp.server.fastmcpimportFastMCPimporthttpx# 创建 MCP Server 实例mcp = FastMCP("weather-server")@mcp.tool()asyncdefget_weather(city: str) ->str:"""查询指定城市的当前天气信息"""asyncwithhttpx.AsyncClient() asclient:# 这里用免费的 wttr.in APIresp = awaitclient.get(f"https://wttr.in/{city}?format=j1"        )data = resp.json()current = data["current_condition"][0]return (f"{city} 当前天气：{current['weatherDesc'][0]['value']}，"f"温度 {current['temp_C']}°C，"f"体感 {current['FeelsLikeC']}°C，"f"湿度 {current['humidity']}%"        )if__name__ == "__main__":mcp.run(transport="stdio")

就这么多。一个 @mcp.tool()

@mcp.tool()

装饰器，一个带类型注解和 docstring 的函数，MCP SDK 自动帮你处理协议层的所有事情——工具注册、参数校验、结果序列化。

然后在 Claude Desktop 的配置文件里加上：

{"mcpServers": {"weather": {"command": "python","args": ["/path/to/weather_server.py"]    }  }}

重启 Claude Desktop，跟它说"北京今天天气怎么样"，它会自动发现这个工具、调用、返回结果。全程你不需要写任何提示词告诉它"你有一个天气工具"——MCP 协议会自动处理工具发现。

三个必踩的坑提前告诉你：

工具描述决定调用质量。那个 docstring 不是写给人看的，是写给 AI 看的。描述越清晰，AI 越知道什么时候该调用这个工具。写"查询天气"比写"获取数据"好十倍。

错误处理必须显式返回。工具执行失败时，别让异常直接抛出。用 try-catch 包住，返回一条清晰的错误信息。AI 需要理解"失败了"和"为什么失败"才能做出正确的下一步决策。

@mcp.tool()asyncdefget_weather(city: str) ->str:"""查询指定城市的当前天气信息"""try:# ... 正常逻辑excepthttpx.HTTPErrorase:returnf"查询失败：无法连接天气服务（{e}）"exceptKeyError:returnf"查询失败：未找到城市 {city} 的天气数据"

Server 不要贪多。一个 Server 挂 3-5 个工具就够了。工具太多会导致上下文膨胀——Claude Code 团队实测发现，工具描述超过上下文窗口的 10% 时，AI 的调用准确率明显下降。他们的解法是渐进式工具发现，token 用量直降 85%。

掌握这个模式之后，你可以快速包装任何 API。一个掘金上的实测数据：工具集成时间从传统方式的 2-3 天/个，降到了 MCP 方式的 2-3 小时/个，效率提升 5-7 倍。

年 MCP 生态全景

MCP 从 2024 年底 Anthropic 发布至今，经历了三个阶段：

2024年末-2025年初：诞生期。 Anthropic 主导，Claude 率先支持，开发者社区开始尝鲜。
2025年3月-年底：爆发期。 OpenAI 3月跟进、Google 4月跟进、Microsoft 将 MCP 集成进 Win11。国内阿里云百炼、腾讯云、百度、高德全面接入。GitHub 上 MCP Server 一个月新增三千个。中文互联网的热度到了"顶流"级别。
2026年至今：成熟期。表面上热度降了，但大厂在安静地做实事。几个标志性事件：

Linux Foundation 接管了 MCP 规范的治理，成立了 Agentic AI Foundation（AAIF），100+ 成员单位。这意味着 MCP 不再是 Anthropic 的"私有协议"，而是真正的行业标准。

2026年3月协议大更新： Auth 认证正式版落地，企业级权限控制终于有标准可循； Streamable HTTP 正式取代 SSE，MCP 可以在浏览器环境原生运行。

生产级实践也在加速。 Uber 搭建了 MCP Gateway + Registry 控制平面，自动暴露数千个内部 Thrift/Protobuf/HTTP 端点，GenAI Gateway 执行 PII 脱敏，每周数万次 Agent 执行全走 MCP。 Amazon 内部建了 MCP 发现基础设施，开源了 agent-sop 项目。 Docker 发布了 MCP Toolkit。 Meta 在 Connect 大会官宣支持。

2026年4月的 MCP 开发者峰会上，一个核心共识浮出水面：规模化部署 MCP，必须要有集中式网关。包括 AWS、Uber、Docker、Kong 在内的多家企业不约而同走向了同一个架构模式——这通常是一个协议走向成熟的标志。

冷静看待：MCP 的争议和边界

吹完生态，必须正视争议。MCP 远不是银弹，目前的问题很真实。

性能还不够稳。 ScaleKit 在2026年2月的基准测试显示，MCP 方式的任务完成率是 72%，而直接用 CLI 是 100%。平均耗时是 CLI 的 1.3 倍。28% 的任务因超时和连接不稳定而失败。在对可靠性要求极高的场景里，这个数字不够看。

上下文膨胀是真实痛点。 Simon Willison 发现，某主流 AI IDE 的 MCP Server 捆绑了 43 个工具，光工具定义就往上下文里塞了 55000 个 token。这不是 MCP 协议本身的问题，而是使用方式的问题——但它确实是实践中最常遇到的坑。

顶级技术人的质疑不能忽视。 YC CEO 说"MCP sucks"，Perplexity CTO 说"复杂度远大于它解决的问题，转回 API 和 CLI"。甚至 Anthropic 自家的 Claude Code，核心架构也是 CLI 而非 MCP——CLAUDE.md 自定义指令系统占了大量篇幅，MCP 只是"可选扩展"。

所以我的判断是什么？

MCP 的方向是对的，但当前阶段不适合所有人、所有场景。具体建议：