MCP 协议入门：为什么它可能改变 AI 工具生态

MCP 想做的是 AI 工具的 USB：工具方实现一次，所有支持 MCP 的应用都能用。但生态成熟度和安全权限仍是现实挑战。

MCP 解决的到底是什么问题

如果你同时用过几个 AI 工具，会发现一个很烦的现象：同样的事情，要在每个工具里重新配置一遍。

想让 AI 读你的本地文件——要在 Claude Desktop 里配一次，在 Cursor 里配一次，在自己写的应用里再实现一次。

想让 AI 查你的数据库——又是三套实现。

这个问题的根源是：每个 AI 应用都定义了自己的工具接入方式。模型本身没有统一的标准来「知道有哪些工具可用、怎么调用它们」。

MCP（Model Context Protocol）就是来解决这个的。它的定位可以类比为：

MCP 之于 AI 工具，就像 USB 之于外设。

在 USB 之前，每个厂商有自己的接口，鼠标键盘打印机各接各的口。有了 USB，设备方实现一次就能插到任何电脑上。

MCP 想做的是同一件事：工具方实现一次 MCP Server，所有支持 MCP 的 AI 应用都能直接用。

架构：三个角色

MCP 的架构很清晰，只有三个角色：

MCP Host（AI 应用，如 Claude Desktop、你的应用）
    ↓ 建立连接
MCP Client（协议客户端，通常内置于 Host）
    ↓ 通信
MCP Server（提供能力的一方）

关键点：MCP Server 提供的是能力，不是数据。

一个 MCP Server 可以暴露三类东西：

1. Tools（工具）

可被模型调用的函数。比如「查询数据库」「发送邮件」「创建文件」。

这是最常用的一类。它和 Function Calling 的关系是：MCP 是 Function Calling 的标准化封装和分发机制。

模型仍然通过 Function Calling 来调用工具，只是工具从哪来、怎么发现，由 MCP 规范定义。关于 Function Calling 的底层机制，可以参考 Function Calling 原理与实现。

2. Resources（资源）

可被读取的数据。比如文件内容、数据库记录、API 返回的数据。

和 Tools 的区别：Resources 是只读的数据提供，Tools 是可能产生副作用的操作。

3. Prompts（提示词模板）

预定义的提示词模板，用户可以调用。

这一类用得相对少，但在一些标准化场景（比如「代码审查」这类固定流程）有价值。

为什么这个设计重要

优势一：解耦

在 MCP 之前，如果你想让自己公司的数据能被 AI 使用，得为每个 AI 应用写一个插件。

有了 MCP，你只需要写一个 MCP Server，所有支持 MCP 的客户端都能用。

这对企业内部尤其有意义：IT 部门维护一套 MCP Server，员工用任何 AI 工具都能访问内部系统。

优势二：运行时发现

MCP Server 可以动态告诉客户端「我现在有哪些工具」。

这意味着工具可以按需加载——不用把所有工具定义都塞进提示词。这在工具数量多的时候很重要，因为过多的工具定义会稀释模型注意力。

优势三：传输层可替换

MCP 规定了通信协议，但底层传输可以是：

  • stdio：本地进程间通信，适合本地工具
  • HTTP/SSE：远程服务，适合云端工具

这意味着本地工具和远程工具可以用同一套接口规范。

一个具体的例子

假设你要让 AI 能查询公司内部的订单系统。

没有 MCP 时：你得为每个 AI 应用写对接代码，处理认证、参数格式、错误处理……

用 MCP：你写一个 MCP Server，暴露一个工具：

工具名：query_order
描述：根据订单号查询订单详情
参数：
  order_id: string，订单号
返回：订单状态、金额、下单时间

然后任何 MCP 客户端都能通过标准方式发现并调用它。

你的 Server 不需要知道调用它的是 Claude 还是别的什么——这就是解耦的价值。

现实中的限制

MCP 是个好方向，但目前（写这篇文章时）有几个实际限制需要注意：

限制一：生态还在早期

支持的客户端数量有限，且各家的实现完整度不一。有些只支持 Tools，不支持 Resources。

这意味着「写一次到处能用」的理想还没完全实现。

限制二：安全和权限是开放的难题

这是最需要认真对待的问题。

MCP Server 可以访问你的文件系统、数据库、内部 API。如果配置不当，风险很大。

具体的风险场景：

  • 恶意 MCP Server 窃取数据
  • 提示词注入让模型调用不该调用的工具
  • 权限过宽，模型能访问超出需要的数据

当前的建议：

  1. 只安装可信来源的 MCP Server——它本质上是在你的机器上运行代码
  2. 最小权限原则——只给它需要的访问范围
  3. 敏感操作用只读账号——查数据就用只读权限
  4. 审计调用日志——出了问题能追溯

限制三：调试体验不统一

不同客户端的日志、错误提示差异较大，排查问题有时比较麻烦。

你应该用它吗

分几种情况：

如果你是工具/服务提供方

值得关注。 如果你的服务想让 AI 应用接入，提供 MCP Server 比提供私有插件更有前景——因为一次实现能覆盖所有 MCP 客户端。

但要评估：目前 MCP 客户端的覆盖率，是否已经超过你的目标用户群。

如果你是应用开发者

看你的工具来源。

  • 如果工具都是自己实现的（比如自己的数据库、自己的 API），直接用 Function Calling 更简单，没必要引入 MCP 这一层
  • 如果需要接入第三方工具，或想让自己的工具被其他应用复用，MCP 有价值

不要为了用 MCP 而用 MCP。 多一层协议就多一层调试成本。

如果你是企业 IT

这是最有价值的场景。

维护一套 MCP Server 供内部 AI 应用使用，比让每个团队各自对接更可控——权限、审计、更新都能集中管理。

和现有方案的关系

MCP 不是凭空出现的，它和一些已有方案有重叠，值得对比一下：

方案特点与 MCP 的关系
私有插件每个应用一套MCP 想统一它
OpenAPI/Swagger描述 HTTP APIMCP 可包装 OpenAPI 服务
Function Calling模型调用工具的能力MCP 是它的标准化分发层

注意最后一行：MCP 不替代 Function Calling，它是在 Function Calling 之上加了一层「工具怎么被发现和分发」的标准。

理解这个层次关系很重要——很多讨论把两者混为一谈，导致对 MCP 的期待错位。

一个务实的判断

MCP 代表了正确的方向：工具接入应该标准化，而不是每个应用重复造轮子。

但它目前的成熟度，还不足以让所有场景都迁移过去。

我的建议：

  1. 先用 Function Calling 把功能做出来——这是底层能力，无论如何都要懂
  2. 关注 MCP 生态的进展——尤其是主流客户端的支持情况
  3. 当你的工具需要被多个应用复用时，再考虑封装成 MCP Server
  4. 涉及内部系统的 MCP Server，安全设计要放在第一位

小结

MCP 的核心价值是标准化 AI 工具接入，类比 USB 对外设的意义。

三个关键认知：

  1. MCP 不替代 Function Calling——它是工具发现和分发的标准层
  2. 最大价值在企业内部——一套 Server 供所有 AI 应用复用，权限可控
  3. 安全是当前最大的挑战——MCP Server 能访问你的系统和数据，权限设计必须谨慎

如果你现在只是做一个应用，先把 Function Calling 用熟就够了。MCP 值得关注，但不必急着上——等你的工具真的需要跨应用复用时，它的价值才真正体现出来。

相关阅读

返回 AI 教程列表