AI探索

第5章：MCP——工具调用的标准化革命

第5章：MCP——工具调用的标准化革命

系列导读：本章是上章的延伸。如果你还在手写每个工具的集成代码，MCP 就是来救你的。它能让你接入一个工具的效率从「一天」降到「十分钟」。

一、没有 MCP 之前，接工具有多麻烦？

想象你要给 Claude Desktop 接入三个工具：GitHub（查仓库）、文件系统（读本地文件）、Slack（发通知）。

在没有 MCP 之前：

  1. 写 GitHub API 调用代码 + OAuth 认证 + 错误处理 + 格式转换，确保返回结果能被模型理解
  2. 写文件系统操作代码 + 权限管控 + 路径沙箱，防止模型删除不该删的文件
  3. 写 Slack API 调用代码 + Bot 配置 + 消息格式化

折腾了三周，终于接好了。三个月后 Claude 升级了，接口变了，你的代码又得重写。

最致命的问题：每个工具都要单独集成，而且强绑定到某个模型。你想换 Gemini 用这些工具？之前写的所有代码都要重写一遍嫁接逻辑。更别说换个多模态模型（比如能看图、能听语音的），工具 layer 可能完全不兼容。

这种碎片化的结果就是：目前市面上有成百上千个有用的工具 API，开发者和模型提供者之间形成了一个糟糕的分发瓶颈——每一家模型厂都要跟每一家工具厂谈合作、做适配。

二、MCP 是什么？

MCP（Model Context Protocol，模型上下文协议）是 Anthropic 在 2024 年底推出的开放协议（不是框架，是协议）。

它的核心目标是：工具实现一次，到处复用；任何支持 MCP 的 AI 客户端，都能自动发现并接入。

你可以把它理解成 AI 时代的「USB-C 接口」——所有工具都按统一标准做接口，所有 AI 客户端都支持这个接口。工具提供者按协议标准写一个 Server，任何支持 MCP 的客户端都能直接拿来用，不需要再说服 OpenAI 或 Google 专门为你做对接。

三、MCP 的架构：Client-Server 模式 

    ┌──────────────┐                    ┌──────────────┐
    │  AI Client   │ ←─── MCP 协议 ───→ │ MCP Server 1 │ (GitHub工具)
    │ (Claude,     │    JSON-RPC 2.0     └──────────────┘
    │  OpenAI SDK) │                          ┌──────────────┐
    │              │ ←─── MCP 协议 ───→       │ MCP Server 2 │ (文件系统)
    └──────────────┘    (stdio / SSE / HTTP) └──────────────┘
  • MCP Server：每个工具按 MCP 协议实现一个服务进程，暴露能力
  • AI Client：在配置文件中声明 MCP Server 地址，自动发现可用的工具
  • 通信方式：支持 stdio（本地进程）、SSE（HTTP流式）、HTTP（远程调用）

这种设计的妙处在于：工具提供者只需要写一份标准化的 Server 实现，所有客户端（Claude、OpenAI SDK、Cursor IDE、Zed 编辑器等）都能自动发现并调用它的能力。工具生态的分发效率得到了本质提升。

四、MCP 的三类核心能力

1. Tools（工具）—— 执行有副作用的操作

如发送邮件、创建文件、调用 API。每次调用都可能改变外部世界状态。工具调用后需要返回执行结果给模型，模型据此决定下一步。

2. Resources（资源）—— 只读数据通道

如读取文件内容、访问数据库、查看日志。资源可以被"挂载"到客户端上下文，模型可以随时调用，不会产生副作用。

3. Prompts（提示词模板）—— 结构化输入模板

预定义一组任务模板，用户可以在使用前填充参数。比如 “生成代码审查提示词” → 填充 “文件路径” → 拿到完整 prompt。这类能力让 MCP Server 不仅是被动的工具提供者，也是主动的交互助手。

这三类能力覆盖了 AI 工具生态中的"执行"、“读取”、“交互模板"三个核心场景。

五、MCP vs Function Calling：不是替代，是互补

维度 Function Calling MCP
层级 API 调用格式（命令） 工具生态协议 + 发现机制
解决的问题 模型怎么说出「我要调什么」 工具怎么被接入和管理
类比 HTTP 请求格式 REST API 规范 + 服务注册发现
关系 依赖关系 MCP 底层还是靠 Function Calling！

最关键的一句话：MCP 底层驱动的仍然是 Function Calling。MCP 不是「不用 Function Calling 了」，而是在 Function Calling 之上加了一层生态层。

  • Function Calling 说：模型输出的工具调用应该是 JSON Schema 格式
  • MCP 说：工具怎么注册、怎么发现、怎么通信、怎么复用，都按统一标准来

你可以只靠 Function Calling 写一辈子代码，但接入第10个工具时你就会想要 MCP。手动管理10个工具的 schema、认证、状态同步、错误重试，是在做重复的体力活。

六、配置一个 MCP Server 有多简单？

以 Claude Desktop 为例，它的配置文件中加几行就行：

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/docs"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxx" }
    }
  }
}

启动 Claude Desktop 后：

  1. 自动启动各 MCP Server 进程
  2. 读取各 Server 暴露的 tools/resources/prompts 列表
  3. Claude 自动发现这些工具并能随时调用

零代码接入。

七、MCP 对生态的影响

  • 工具开发者：按 MCP 标准实现一次，OpenAI、Claude、Gemini 都能用。分发成本从 O(NxM) 降到 O(N+M)。
  • AI 客户端开发者：接入 MCP 协议就能自动获得成百上千的工具
  • 终端用户：AI 能做的事情从「聊天+联网搜索」变成「调用整个数字世界”

MCP 的意义跟当年 HTTP 协议标准化 web 服务是一样的底层逻辑。如果没有 HTTP，每个网站都得写自己的传输协议，浏览器永远做不到通用。MCP 的目标是让 AI 工具的接入也有同样的标准化基础。

八、本章小结

  • MCP 是 AI 工具生态的"USB-C"标准化协议
  • 三类能力：Tools（执行）、Resources（只读数据）、Prompts（模板）
  • MCP 和 Function Calling 是不同层次的东西：FC 解决"格式"问题，MCP 解决"生态"问题
  • 配置 MCP Server 只需几行配置，零代码接入
  • MCP 代表了 AI 工具生态从碎片化走向标准化的关键转折点

思考题

  1. MCP 的「开放协议」定位意味着它的生命周期会长于任何单一公司的产品。如果这个协议成为事实标准，会对 AI 工具生态产生什么深远影响？
  2. 在 MCP 的三种能力（Tools/Resources/Prompts）中，你认为哪一类最有商业想象空间？为什么？
© 2026 SelfTechHub