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

Mon, 01 Jun 2026 00:00:00 +0000

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

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

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

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

在没有 MCP 之前：

写 GitHub API 调用代码 + OAuth 认证 + 错误处理 + 格式转换，确保返回结果能被模型理解
写文件系统操作代码 + 权限管控 + 路径沙箱，防止模型删除不该删的文件
写 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 后：

自动启动各 MCP Server 进程
读取各 Server 暴露的 tools/resources/prompts 列表
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 工具生态从碎片化走向标准化的关键转折点

思考题

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

Model Context Protocol on SelfTechHub

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

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

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

二、MCP 是什么？

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

四、MCP 的三类核心能力

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

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

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

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

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

七、MCP 对生态的影响

八、本章小结

思考题