MCP 协议解析:给大模型接上 USB-C 接口

Words: 1105Read Time: 3 minLast edited: 2026-8-4

要解决的问题:N 乘 M 的集成地狱

去年 11 月 Anthropic 发布 MCP(Model Context Protocol)的时候,我扫了一眼没当回事——又是一个新协议。直到今年春天它遍地开花:Claude Desktop、Cursor、Cline 相继支持,连 OpenAI 都宣布接入,我才回头认真研究,结论是它确实解决了真问题。
什么问题?假设有 M 个 AI 应用(聊天客户端、IDE 插件、Agent 框架)和 N 个工具/数据源(数据库、文件系统、各种 SaaS)。没有标准时,每个应用接每个工具都得写一套定制集成,共 M×N 套。MCP 相当于定了 USB-C 标准:工具方按协议写一个 server,所有支持 MCP 的应用插上就能用,M×N 直接变 M+N。

架构:Host、Client、Server

MCP 的角色划分不复杂:
  • Host:用户直接用的 AI 应用,比如 Claude Desktop。
  • Client:Host 内部的连接器,和每个 server 保持一对一连接。
  • Server:工具提供方,一个轻量进程,通过 stdio(本地)或 HTTP/SSE(远程)与 client 通信。
对我们写工具的人来说只需关心 server:一个普通进程,按 JSON-RPC 规范和 client 通信,把能力以标准格式暴露出去。

三类原语:Tools、Resources、Prompts

server 能向 client 暴露三种东西:
  • Tools:可执行的函数,和 function calling 里的工具是一回事——查天气、查数据库、发消息。
  • Resources:可读取的数据,类似 GET 接口——文件内容、配置、日志,用 note://xxx 这样的 URI 标识。
  • Prompts:预定义的 prompt 模板,把"工具怎么用效果最好"的经验固化下来。
大部分场景用 Tools 就够了,Resources 适合给模型喂背景资料,Prompts 目前用得最少。

动手:官方 SDK 写个最小 server

官方 Python SDK(pip install mcp)里的 FastMCP 把样板代码全干掉了,一个最小 server 不到 20 行:
装饰器对应三类能力;函数的类型注解会自动生成参数 schema,docstring 就是给模型看的工具描述——所以 docstring 必须认真写,模型靠它决定什么时候调这个工具
然后在 Claude Desktop 的配置文件里挂上:
重启客户端,聊天框里就能看到工具列表,对话时模型会自己决定调用。调试推荐 SDK 自带的 mcp dev server.py,会起一个网页版 Inspector,可以手动调每个工具看返回值,不用反复重启客户端。

上手后的几点体会

  • stdio 模式的 server 里千万别随手 print。stdout 就是协议通道,print 一句调试信息就把 JSON-RPC 污染了,客户端直接解析失败。日志要写到 stderr,这个坑我踩了半小时。
  • 协议和 SDK 都还年轻,接口变动快,依赖版本建议锁死,升级前看 changelog。
  • 生态起来之后,接工具的思路也变了:以前想"我的应用怎么接这个 API",现在先搜"有没有现成的 MCP server",社区已经写好了一大堆。
对独立开发者来说,MCP 把"给 AI 接工具"的门槛打到了写一个普通 Python 函数的水平。我打算把常用的几个运维脚本也包成 server,让所有客户端都能直接调。
Loading...
© 2024 - 2026 ihuadz
中文