第 05 篇讲了工具调用:在请求里定义工具,模型提出调用,你的程序执行。这套机制有一个问题:每个 Agent 应用都要自己写一遍工具对接代码。MCP(Model Context Protocol)就是为了解决这个问题而出现的协议。
一、MCP 解决什么问题
假设你有 3 个 Agent 应用(一个聊天助手、一个编码工具、一个内部机器人),想让它们都能访问 5 个系统(数据库、文档库、工单系统、监控系统、代码仓库)。没有统一协议时,你要写 3 × 5 = 15 套对接代码,每个应用一套,格式还各不相同。
MCP 把这个问题变成了 3 + 5:
- 每个系统实现一次 MCP Server,把自己的能力按标准格式暴露出来;
- 每个 Agent 应用实现一次 MCP Client,就能连接任何 MCP Server。
这和 USB 接口的思路一样:设备和电脑之间约定一个标准,任何设备都能插到任何电脑上。
二、架构:Host、Client、Server
| 角色 | 是什么 | 举例 |
|---|---|---|
| Host | 用户直接使用的 Agent 应用,包含模型调用和 Agent Loop | 桌面聊天应用、编码工具 |
| Client | Host 内部负责和某个 Server 通信的组件 | 每连接一个 Server,就有一个对应的 Client |
| Server | 把某个系统的能力按 MCP 标准暴露出来的程序 | 数据库 Server、文件系统 Server、GitHub Server |
协议的消息格式基于 JSON-RPC 2.0,也就是请求带方法名和参数,响应带结果或错误。
三、Server 提供的三种能力
| 能力 | 是什么 | 由谁决定使用 | 举例 |
|---|---|---|---|
| Tools(工具) | 可以被调用的函数 | 模型决定 | 查询订单、创建工单、执行 SQL |
| Resources(资源) | 可以被读取的数据,用 URI 标识 | 通常由应用或用户决定 | 某个文件、某张表的结构、一份配置 |
| Prompts(提示模板) | 预先写好的提示词模板 | 通常由用户选择 | 「生成周报」「代码审查」模板 |
三者中,Tools 用得最多,它和第 05 篇讲的工具调用是同一回事,只是定义从 Server 那里获取,而不是写死在应用里。
典型的方法有:tools/list(列出工具)、tools/call(调用工具)、resources/list、resources/read、prompts/list、prompts/get。
四、一次工具调用的完整过程
- 发现:Client 向 Server 请求
tools/list,拿到工具列表(名称、描述、参数 Schema)。 - 提供给模型:Host 把这些工具定义连同自己的其他工具一起放进模型请求。
- 模型决定调用:模型输出工具调用请求。
- 转发:Host 发现这个工具属于某个 MCP Server,让对应的 Client 发送
tools/call。 - 执行并返回:Server 执行,返回结果;Host 把结果回填给模型。
可以看到,模型本身并不知道 MCP 的存在。对模型来说,这些工具和普通工具没有区别。
五、MCP 与 Function Calling 的关系
这两个概念经常被混淆,其实它们在不同的层次:
- Function Calling 是模型层的能力:模型能理解工具定义、输出结构化的调用请求。
- MCP 是应用层的协议:工具从哪来、怎么被发现、调用请求怎么送到真正执行的地方。
MCP 依赖 Function Calling 工作,但它解决的是工具的组织和接入问题,而不是模型如何调用的问题。
六、传输方式
- stdio(标准输入输出):Host 在本地启动 Server 进程,通过标准输入输出通信。简单、安全,适合本地工具,比如访问本机文件。
- Streamable HTTP:Server 作为一个 HTTP 服务运行,可以部署在远程,多个用户共用。适合公司内部共享的服务或 SaaS 提供的 Server。早期版本使用的 HTTP+SSE 传输方式已被它取代。
远程 Server 需要鉴权。MCP 规范定义了基于 OAuth 的授权流程,让用户以自己的身份授权 Agent 访问对应的系统。
七、协议在演进
MCP 还是一个较新的协议,版本更新比较频繁,学习时要注意看对应的版本。比如 2026 年 7 月发布的规范做了较大调整:
- 去掉了连接初始化握手和会话:早期版本要求 Client 先发
initialize请求协商版本和能力,新版本改为每个请求自带版本和能力信息,任何一台 Server 实例都能处理任何请求,更便于水平扩展和负载均衡。 - 新增
server/discover:Client 可以按需查询 Server 支持的版本和能力。 - Roots、Sampling、Logging 等几个特性被标记为弃用,有一年以上的过渡期。
这些变化对使用者影响不大,主要影响 SDK 和 Server 的实现。理解 Tools / Resources / Prompts 和 Host / Client / Server 这两组核心概念,就能读懂任何版本。具体细节以官方规范 modelcontextprotocol.io 为准。
八、MCP 的边界
- MCP 只负责接入,不负责安全。一个 Server 暴露了危险的写操作,Agent 就可能调用它。权限要在 Server 侧和 Host 侧共同控制。
- 工具描述来自 Server,如果 Server 不可信,工具描述里可能夹带恶意指令。只连接你信任的 Server。
- 每个 Server 的工具都会占用上下文,连接太多 Server 会让工具列表变得很长。
本篇小结
- MCP 用统一协议把 M × N 的对接问题变成 M + N。
- 角色:Host(应用)、Client(连接器)、Server(能力提供方)。
- Server 提供 Tools、Resources、Prompts 三种能力,Tools 最常用。
- Function Calling 是模型能力,MCP 是接入协议。
- 传输:本地 stdio、远程 Streamable HTTP,远程需要 OAuth 授权。
- 协议在快速演进,学习时注意版本。
思考与练习
- 如果要把业务数据库的查询能力做成 MCP Server,需要提供哪些 tools?哪些内容适合做成 resources?
- 本地 stdio 和远程 HTTP 两种方式,分别适合什么样的 Server?
上一篇:AI Agent原理篇11:多 Agent 协作:编排、子 Agent 与交接
下一篇:AI Agent原理篇13:MCP 实战:写一个自己的 MCP Server
返回系列总目录