MCP 协议：AI 工具接入的 USB-C 时刻到了吗

你给 AI 接一个日历工具，要写一套 Function Calling 的 schema。接一个数据库查询，再写一套。接 Slack、Jira、GitHub，各写一套。每个工具一种接法，每个模型提供商的 tool_call 格式还不完全一样。

这个场景像什么？像 2010 年前后的手机充电线。Nokia 一种、三星一种、摩托罗拉一种、苹果又是一种。每换一部手机就要买新线，抽屉里一堆乱七八糟的充电器。

后来 USB-C 出现了。一根线搞定。

Anthropic 在 2024 年底提出的 MCP（Model Context Protocol）想做的，大致就是这件事：给 AI 模型和外部工具之间定一个通用协议。工具只要实现一次 MCP Server，任何支持 MCP 的 AI 客户端都能直接用，不用重新适配。

MCP 的三层能力

一个 MCP Server 可以向客户端暴露三种东西：

Tools（工具）。模型可以主动调用的函数。比如"搜航班""发消息""建日程"。这是最核心的能力，替代了各家自己定义的 Function Calling schema。

Resources（资源）。被动的、只读的数据源。比如"这个项目的文档""这个数据库的表结构""这周的会议记录"。模型不是调用它，而是读取它来获得上下文。

Prompts（提示模板）。预置的指令模板，告诉模型怎么配合特定工具工作。比如"当用户问航班信息时，先调用 search_flights 工具，再用以下格式组织回复"。

这三层对应的是三种场景：执行操作、获取上下文、规范行为。之前你要在自己的代码里分别实现这些，现在 MCP 给了统一的结构。

生态现状：能用但还早

截至 2026 年 2 月，MCP 生态有这么几个东西：

官方参考实现。Anthropic 在 GitHub 上放了一批 reference servers：文件系统操作、Git 管理、Web 内容抓取、记忆图谱、顺序思考等。TypeScript 和 Python 都有 SDK。Go、Java、Rust、Swift 等语言也有社区维护的 SDK。

官方注册表。registry.modelcontextprotocol.io 上线了，可以搜索和发现社区发布的 MCP Server。有点像 npm registry，但内容还比较少。

客户端支持。Claude Desktop 原生支持 MCP。Cursor 编辑器也集成了。OpenAI 的 Responses API 在 2025 年 5 月宣布支持远程 MCP Server 连接。这是个信号——不只是 Anthropic 自己在推，OpenAI 也接了。

但说实话，目前的实际使用体验还比较粗糙。我试过几个社区的 MCP Server，碰到的问题包括：

很多 Server 只实现了 Tools，没有 Resources 和 Prompts。三层能力只用了一层。
Server 的错误处理参差不齐。有些 Server 在工具调用失败时返回的错误信息含糊不清，模型不知道怎么重试。
安全模型还不成熟。MCP Server 可以做任意操作（读写文件、发请求、执行代码），但目前没有标准化的权限沙箱。你安装一个社区 MCP Server，等于给了它你机器上的一部分控制权。

对开发者意味着什么

如果你在做 AI 产品，MCP 的价值取决于你的角色：

如果你在做 AI 应用（Client 端）。短期内你仍然需要自己写 Function Calling，因为并非所有模型都支持 MCP。但可以开始关注 MCP 生态里有没有现成的 Server 能直接用。比如你需要接 GitHub，与其自己写一套 tool schema + API 调用，不如看看有没有成熟的 GitHub MCP Server。

如果你在做工具/SaaS（Server 端）。提供一个 MCP Server 是个不错的分发渠道。就像你会给产品做一个 Slack 集成、一个 Zapier 集成一样，以后可能还需要做一个 MCP Server。让 AI Agent 能直接使用你的产品，这是一种新的获客方式。

如果你在做 API 聚合/网关。MCP 是个值得关注的方向。网关层如果能充当 MCP 的注册中心和代理，统一管理工具的发现、鉴权、限流，会比让每个 Client 自己去连各种 MCP Server 更可控。

几个还没解决的问题

发现机制。怎么让 Client 知道有哪些 MCP Server 可用？现在靠注册表和手动配置。缺少一个像 DNS 一样的自动发现协议。

版本兼容。MCP Server 升级了接口，Client 怎么办？目前没有版本协商机制。这在早期还好，一旦生态铺开，兼容性会是大问题。

信任和安全。我安装一个社区写的 MCP Server，怎么知道它不会偷偷读我的文件或者发恶意请求？需要一套类似 App Store 的审核机制，或者至少有一个权限声明和沙箱运行的标准。

性能。每次工具调用都经过 MCP 协议，多了一层序列化/反序列化。对实时性要求高的场景（比如代码补全中的工具调用），这个额外开销是否可接受，还需要更多实测。

类比 USB-C：标准化的路还很长

回到充电线的类比。USB-C 标准 2014 年发布，到 2024 年欧盟强制统一才算真正普及。中间十年，各种"支持 USB-C 但只能慢充""接口是 C 但协议是 2.0"的尴尬体验，大家都经历过。

MCP 大概率也会走类似的路：标准发布 → 头部玩家试探性支持 → 社区野蛮生长 → 碎片化问题暴露 → 标准迭代收敛 → 大规模采用。现在大概在第二到第三步之间。

值不值得现在投入？如果你的产品本身就需要大量工具集成，值得花时间了解 MCP 的设计思路，把自己的工具抽象做得更标准化一些。即使最终胜出的协议不是 MCP，这套思维方式也不浪费。如果你只是调用几个固定的 API，现阶段没必要追。

参考链接

MCP 官方网站：https://modelcontextprotocol.io/
MCP GitHub 组织：https://github.com/modelcontextprotocol
MCP 官方注册表：https://registry.modelcontextprotocol.io/