← 返回 AI 主页
先把你最该钉死的一句话记住：MCP（Model Context Protocol，模型上下文协议）是 Anthropic 在 2024 年底推出的一个开放标准协议，用来规定「大模型应用」和「外部工具 / 数据」之间怎么发现、连接、互相调用。它定义的是通信规则，不是一个具体的工具，也不是一个 Agent 框架。
所以你纠结的「MCP 不就是 Tool 吗」——答案是：MCP 是「装工具的集装箱 + 标准货运协议」；Tool 是集装箱里那件具体的货。一个 MCP Server 里面装的就是一个个 Tool（外加 Resource/Prompt）。下面用图把这件事拆开。
在没有 MCP 之前，集成是个 M×N 地狱
每个 Agent 应用（Claude Desktop、Cursor、你自己的 Python 脚本…）想接每个外部系统（GitHub、数据库、文件系统、Slack…）都得各自写一套对接代码。N 个应用 × M 个系统 = N×M 份重复集成。换一个应用，全部重写。
❌ 没有 MCP：N×M 集成
9 份定制连接器
每换一个 App 全重来
✅ 有 MCP：N+M 集成
应用侧 + 服务端
各自只写一次
定制对接代码
标准协议连接
MCP 解决的三个核心痛点
🔌标准接口
不再每家应用各写一套。工具方按协议实现一次 Server，任何兼容 MCP 的客户端都能即插即用——「写一次，处处可用」。
🧩解耦进程
工具可以跑在独立进程甚至远程机器上，和跑模型的应用隔离。崩溃、升级、加权限互不影响，还能统一管凭证。
🔍运行时发现
客户端启动时向 Server 问「你有哪些能力？」，动态拿到工具/数据的清单（schema），大模型才知道能调什么，不用写死在代码里。
MCP 是经典的 客户端 / 服务器（C/S）架构，外加一个「宿主（Host）」概念。三层角色分工明确，点下面的方块看各自职责。
HOST
宿主应用
真正跑大模型 + 编排逻辑的程序
例：Claude Desktop、Cursor、你自己写的 Agent
⇅
CLIENT
MCP 客户端
内嵌在 Host 里，与 Server 1:1 连线
负责握手、发 list / call 请求
⇅
SERVER
MCP 服务器
把外部系统包成标准能力暴露出来
例：GitHub Server、Postgres Server、文件系统 Server
宿主（Host）= 大模型所在的应用
Host 是「用户真正面对的那个 AI 应用」。它里面装着 LLM 和对话/编排逻辑，决定什么时候、要不要调用工具。一个 Host 可以同时连多个 MCP Server（每个 Server 一个 Client）。
- Host 负责：加载系统提示、调 LLM、解析模型返回的「我要调工具」、把结果回填给模型。
- 常见 Host：Claude Desktop、Cursor、Windsurf、Cline、各种自研 Agent 后端。
MCP 客户端（Client）= Host 内部的「接线员」
每个 MCP Server 对应 Host 里一个 Client，二者一对一建立持久连接。Client 把 Host 的意图翻译成 JSON-RPC 请求发给 Server，再把 Server 的回复翻译回 Host。
- 发起
initialize 握手、协商能力（capabilities）。
- 调用
tools/list 拿工具清单、tools/call 触发执行。
- 客户端不是「另一个 LLM」，它只是传输 + 协议层。
MCP 服务器（Server）= 能力的「集装箱」
Server 是一个独立进程/服务，把某个外部系统（数据库、API、本地文件…）封装成协议标准的能力：Tools（可执行动作）、Resources（可读数据）、Prompts（提示模板）。
- 它自己不跑模型，只负责「被调用时去真实系统干活」。
- 可以本地启动（stdio 子进程），也可以远程（HTTP/SSE）。
- 凭证（token、密码）留在 Server 端，Host 不碰——更安全。
两种传输方式（Transport）
协议本身和「怎么传」无关，底层靠 JSON-RPC 2.0 编码消息，再套一层传输。常见两种：
🖥️ stdio（标准输入输出）
Host 把 Server 当成本地子进程启动，双方通过 stdin/stdout 收发 JSON。适合本机工具（读文件、本地命令）。
# Host 启动本地 Server 子进程
spawn("mcp-server-filesystem")
# 通过 stdin/stdout 交换 JSON-RPC
{"method":"tools/call", ...}
🌐 Streamable HTTP / SSE
Server 跑在远程，Host 通过 HTTP（流式）连接。适合云端 SaaS、多人共享、需要鉴权的企业服务。
# 客户端通过 HTTP 端点连接远程 Server
POST https://api.xxx.com/mcp
# 服务端可经 SSE 把结果流式推回
event: message
data: {"result": ...}
这是你最该看透的一节。先纠正一个根深蒂固的错觉：「MCP」和「Tool」不是同一层的东西，没法直接并列比较。
· Agent 里的 Tool：是一个代码层面的抽象——一个带 schema 的函数，供 LLM 调用。它描述的是「能力长什么样」。
· MCP：是一套跨进程的标准通信协议——它规定 Tool 怎么被「发现、序列化、远程调用、回传」。它描述的是「能力怎么传」。
所以正确的对比是：「把工具写死在 Agent 进程内」 ↔ 「把工具通过 MCP 协议放在独立 Server 暴露」。两者最终都给 LLM 一个可调用工具，MCP 只是额外加了标准化 + 解耦 + 跨客户端复用。
两种「给 Agent 加工具」的方式对比图
① 硬编码工具（进程内）
工具函数和 Agent 代码在同一个进程、同一份代码里。
Agent 进程
├─ LLM 推理
├─ def search_web(q): ... # 写死
├─ def send_mail(...): ... # 写死
└─ tools=[search_web,send_mail] # 手动注册
换一个 Agent → 工具代码得重写 / 复制。工具崩溃 → 整个进程崩。
② 通过 MCP 暴露工具（跨进程）
工具在独立 Server 进程，Agent 只管按协议连线调用。
Agent 进程 ──JSON-RPC──► MCP Server 进程
(Host+Client) ├─ tools/list → [{name, schema}]
├─ tools/call → 真去干活
└─ 连接 GitHub / DB / FS …
同一个 Server → 任何 MCP 客户端都能用。Server 挂了 → Agent 还能跑。
六维逐项对比
| 维度 | 硬编码 Tool（进程内） | MCP 暴露的 Tool |
|---|
| 本质 | 代码函数 + 手写 schema | 函数 + JSON-RPC 标准协议封装 |
| 运行位置 | 与 Agent 同一进程 | 独立进程 / 远程 Server |
| 跨应用复用 | 差，每套 Agent 各写各的 | 好，写一次到处连 |
| 能力发现 | 手动注册，编译期写死 | 运行时 tools/list 动态获取 |
| 隔离 / 安全 | 凭证混在主程序，崩了全崩 | Server 隔离，凭证集中管控 |
| 适合规模 | 小脚本、一次性原型 | 多工具、多客户端、生产级 |
🔧 交互演示：一个真实的 MCP 调用会话
点「开始连接」看 Host↔Server 之间到底 exchanged 了些什么——你会发现普通 Tool 根本没有这套握手与发现。
MCP 不只传「工具」。它定义了四类原语（Primitive），区别在于「谁来控制」——这是它比「只给 LLM 塞函数」想得更周全的地方。
模型控制 · Model-controlled🛠 Tools
可被模型主动调用、通常有副作用的动作：查 API、发邮件、写文件、跑 SQL。模型看到 schema 后自己决定何时调用。
应用控制 · App-controlled📄 Resources
只读的数据源，像「可以读的文件」：数据库某行、日志、文档。由应用决定何时塞进上下文，模型一般不主动「调」。
用户控制 · User-controlled💡 Prompts
可复用的提示模板，用户主动选：例如「总结这段代码的 bug」「按模板写周报」。相当于预置工作流。
反向控制 · Server→Client🔁 Sampling
最反直觉：Server 反过来请求让 LLM 干活（经 Client 中转）。让工具内部也能调用模型能力，实现「工具里套模型」。
一句话记：Tools 让模型动手，Resources 让模型读书，Prompts 让用户选流程，Sampling 让工具也能问模型。普通 Agent 的「Tool」只覆盖了第一种。
还有两个常被忽略的能力
📂Roots（根目录）
Client 告诉 Server「你只允许访问这些路径 / 资源范围」，做最小权限约束。
❓Elicitation（信息征询）
Server 运行中可向用户反问缺的参数（如「要连哪个数据库？」），而不必预先全写死。
一次完整的 MCP 交互，本质是一次带握手的 JSON-RPC 会话。下面用步进动画走一遍「从连接到真正调工具」的全过程。
1
initialize · 握手
Client 连上 Server，交换协议版本与各自支持的 capabilities（谁支持 tools？谁支持 sampling？）。双方对齐「能聊什么」。
2
initialized · 就绪
Client 收到 Server 的 initialize 结果后，发一个 notifications/initialized 通知，握手完成，正式开始通信。
3
tools/list · 发现能力
Client 问「你有哪些工具？」Server 返回每个工具的 name + 输入 schema。模型之后看到的「可用工具列表」就来自这里。
4
LLM 决策
Host 把工具清单塞进模型上下文。模型根据用户问题，决定「我要调 send_mail，参数是…」，返回 tool_call。
5
tools/call · 真正执行
Client 把模型的 tool_call 转发给 Server；Server 去真实系统（邮件服务）执行，拿到结果。
6
结果回填 · 继续推理
Server 把执行结果经 Client 回传 Host，Host 把结果作为新消息喂给模型，模型据此生成最终回答。
MCP 不是实验室玩具。凡是「让 LLM 安全、标准化地连上真实世界数据 / 系统」的地方，都是它的用武之地。
📚
接入私有数据（RAG 替代 / 补充）
把公司文档、知识库、数据库做成 Resource Server，模型按需读取，不必把所有内容硬塞进 prompt，也不必每个应用各接一遍。
LLM ⇄ MCP ⇄ 内部 Wiki / DB
⚡
让模型真正「动手」
通过 Tools Server 让模型执行动作：发邮件、提单、查订单、调内部 API，且凭证集中在 Server 端。
LLM → tools/call → GitHub / Jira / CRM
💻
IDE / 编码 Agent
Cursor、Cline、Windsurf 等通过文件系统 / Git / 代码检索 MCP Server 直接读懂你的代码库，无需把仓库拷进对话。
编码 Agent ⇄ MCP ⇄ 本地代码仓库
🔁
一处编写，多处复用
一个 Postgres MCP Server 写好，Claude Desktop、Cursor、你的自研后端都能连——彻底消灭重复集成。
1 Server ⇄ N 个 Host 客户端
🏢
企业级统一网关
公司把内部系统封成受控 MCP Server，集中做鉴权、审计、最小权限（Roots），安全合规地给各种 AI 应用供货。
AI 应用 → 网关 ⇄ 内部系统
🖥️
桌面应用本地集成
Claude Desktop 通过本地 stdio Server 访问你的文件系统、日历，全程本机进程，数据不出电脑。
桌面 App ⇄ stdio ⇄ 本机文件系统
一句话收尾：MCP 是「大模型到外部世界的 USB-C 接口」——它不替代 Tool，而是把 Tool（和 Resource/Prompt）用一套标准协议序列化、发现、跨进程调用，从而解决「每个应用重复造轮子 + 工具绑死在代码里」的老大难。
核心速查
- MCP = 协议，不是框架、不是工具、不是 Agent。
- 三层角色：Host（跑模型的应用）→ Client（接线员，1:1）→ Server（能力集装箱）。
- 传输：stdio（本地子进程）/ Streamable HTTP（远程）。
- 四类原语：Tools（模型控）、Resources（应用控）、Prompts（用户控）、Sampling（Server 反向问模型）。
- 生命周期：initialize → initialized → tools/list → LLM 决策 → tools/call → 结果回填。
- MCP vs Tool：Tool 是「能力本身」，MCP 是「能力的标准运输方式」；正确对比是「硬编码进程内工具」vs「跨进程协议暴露工具」。
三个常见误解
❌「MCP 就是一种 Tool」
错。Tool 是能力，MCP 是搬运能力的协议。一个 MCP Server 里面装的才是 Tool。
❌「用了 MCP 模型就更聪明」
错。MCP 不改进推理，只决定模型「能不能、怎么」连上外面的数据和动作。
❌「不用 MCP 就不能调工具」
错。硬编码 Tool 一样能调；MCP 解决的是标准化、解耦、复用，不是「能不能」。
记忆口诀：「协议不替代工具，只是给工具上了标准集装箱；写一次 Server，连遍所有 Host；模型控 Tool、应用控 Resource、用户控 Prompt。」