MCP 协议入门：为什么 AI Agent 需要一个统一的工具调用标准

2025 年，AI Agent 的开发者面临一个尴尬的现实：

你想让 Claude Desktop 连接 GitHub、Slack 和 Postgres 数据库。做法是什么？为每个服务单独写集成代码——GitHub 用 REST API、Slack 用 WebSocket、Postgres 用数据库驱动。每个工具的认证方式不同、数据格式不同、错误处理不同。

更糟的是，如果换个 AI 应用（比如从 Claude Desktop 换到 Cursor），所有的集成代码要重新写一遍。

这不是某个开发者的疏忽。这是整个 AI 工具调用生态的系统性碎片化。

而 MCP（Model Context Protocol），正是为了解决这个问题而诞生的。

用 LSP 类比，秒懂 MCP 的价值

在理解 MCP 之前，先看一个你已经受益的类似标准：LSP（Language Server Protocol）。

1980 ~ 2015 年，代码编辑器的世界是这样的：每个编辑器都要为每种语言单独实现代码补全、跳转定义、错误诊断。VS Code 写一套 Python 插件，Vim 写一套，Sublime 再写一套。N 个编辑器 × M 种语言 = N×M 套实现。

2016 年，微软发布 LSP。核心思想很简单：一种语言只需要写一个 Language Server，所有编辑器通过统一协议对接它。

LSP 彻底改变了编辑器生态。今天你写 Python 时享受的智能补全，背后是同一个 Pyright Server——不管你在 VS Code、Vim 还是 Zed 里写代码。

MCP 在 AI 工具调用领域做的是同样的事。有了 MCP，GitHub 工具只需要写一个 MCP Server，Claude Desktop、Cursor、Continue、Zed——任何实现了 MCP Client 的 AI 应用都能即插即用。

架构三角：Host → Client → Server

MCP 的架构由三个角色组成——理解这个三角形，就理解了 MCP 的全部结构：

Host（宿主应用）

Host 是最终用户看到的 AI 应用。比如 Claude Desktop、Cursor IDE、一个自建的聊天界面。Host 负责：

• 接收用户的输入
• 将上下文（对话历史、文件内容等）通过 Client 传递给 LLM
• 展示最终回答给用户

Host 不直接和 MCP Server 通信。它通过内置的 Client 完成所有协议操作。

Client（协议客户端）

Client 是嵌入在 Host 内部的 MCP 协议实现层。它负责：

• 建立和维护与 MCP Server 的连接（stdio 或 HTTP）
• 向 Server 发送协议请求——发现工具有哪些（tools/list）、读取资源（resources/read）、获取提示词模板（prompts/get）
• 将 LLM 发出的工具调用指令转发给 Server，并将结果返回给 LLM

Client 是 MCP 架构中最关键的桥梁——它同时连接 LLM 和外部工具，对两者进行协议翻译。

Server（工具提供者）

Server 是实际执行工具的程序。一个 MCP Server 暴露一组能力：

• Tools：可以被 LLM 主动调用的工具（查天气、发消息、查数据库）
• Resources：可以被 Client 读取的上下文数据（文件内容、API 响应）
• Prompts：预定义的提示词模板（让用户快速选择常用对话模式）

一个 Server 可以同时提供这三类能力，也可以只提供其中一部分。

一个最小化调用流程

用文字描述 MCP 的一次完整调用链路：

用户在 Host 中提问："帮我查 GitHub 上 MCP 相关的最新 Issue"

  ┌─────────────── Host（Claude Desktop）───────────────┐
  │                                                      │
  │  ① 用户输入                                  ⑧ 展示结果 │
  │     ↓                                                ↑ │
  │  ┌──────────────── Client ────────────────────┐     │ │
  │  │                                              │     │ │
  │  │  ② tools/list ────────────────→  MCP Server │     │ │
  │  │     ← [search_issues, create_issue, ...]     │     │ │
  │  │                                              │     │ │
  │  │  ③ LLM 看到可用工具，决定调用 search_issues   │     │ │
  │  │                                              │     │ │
  │  │  ④ tools/call ─────────────────→  MCP Server │     │ │
  │  │     {"name":"search_issues",                  │     │ │
  │  │      "arguments":{"query":"MCP","limit":5}}   │     │ │
  │  │                                              │     │ │
  │  │  ⑤ ← 返回 Issue 列表 JSON                      │     │ │
  │  │                                              │     │ │
  │  │  ⑥ LLM 收到结果，生成自然语言回答               │     │ │
  │  └──────────────────────────────────────────────┘     │ │
  │                                                      │ │
  └──────────────────────────────────────────────────────┘

关键点：LLM 不知道 MCP Server 的存在，也不直接和 Server 通信。LLM 只看到工具的名称、描述和参数 schema——它决定"调用哪个工具、传什么参数"。实际的协议通信由 Client 完成。

这个分层设计是 MCP 最优雅的地方：模型和协议解耦。换一个 LLM 提供商，Client 不变、Server 不变——只需要 Host 换一个模型 API 调用。

三大核心原语速览

MCP 定义了三类核心能力，分别服务于不同的调用场景：

为什么要区分这三者？因为不同场景的调用权限不同。Tool 是 LLM 自动决定调用的——需要慎重暴露（防止模型误操作删除文件）。Resource 是应用层主动读取的——不需要 LLM 参与决策。Prompt 是用户手动选择的——给用户快捷入口。这个分类让 MCP Server 可以精确控制"什么角色在什么情况下能做什么"。

所有原语都通过 JSON-RPC 2.0 传输，支持两种传输方式：

• stdio（标准输入输出）：适合本地进程间通信，无需网络配置
• Streamable HTTP（支持 SSE 流式推送）：适合远程服务，支持流式响应和断线续传

MCP vs 原生 Function Calling：关键区别

这是开发者最容易混淆的地方。我们用一个清晰的对比来说清楚：

一句话总结：Function calling 定义的是"模型怎么输出工具调用"，MCP 定义的是"工具怎么被管理和连接"。两者不是竞争关系——MCP 的 Client 层最终会把 MCP 工具描述翻译成对应模型需要的 function calling 格式。MCP 是更上层的抽象。

一个具体场景：有 MCP 和没有 MCP 的区别

假设你要让 Claude Desktop 同时连接三个外部工具：GitHub（查看 Issue）、Slack（发送消息）、Postgres（查询数据库）。

没有 MCP 时

• GitHub 集成：写一套代码处理 GitHub REST API 认证、请求、响应解析、错误重试
• Slack 集成：再写一套代码处理 Slack Web API 认证、消息格式、文件上传
• Postgres 集成：再写一套代码处理数据库连接池、SQL 执行、结果格式化

三套代码，三套认证逻辑，三套错误处理。哪天想加第 4 个工具（比如 Jira）——再写一套。而且换到 Cursor IDE 时，所有集成代码全部重写。

有 MCP 时

• 启动 github-mcp-server（社区已有，一行命令）
• 启动 slack-mcp-server（社区已有，一行命令）
• 启动 postgres-mcp-server（社区已有，一行命令）

Claude Desktop 作为 Host，通过内置 Client 自动发现三个 Server 暴露的所有工具。LLM 看到统一的工具列表，按需调用。加第 4 个工具？再启动一个 MCP Server 即可。换到 Cursor IDE？三个 Server 不用改，Cursor 内置的 Client 直接连。

这就是标准化协议的力量。跟 USB 统一了外设接口一个道理——你不需要为每个鼠标写驱动。

MCP 是谁做的？

发起方：Anthropic 于 2024 年 11 月开源发布 MCP。

当前托管：2025 年移交 Linux Foundation 托管，成为正式的开源标准项目。

许可协议：Apache 2.0，完全开放，无厂商锁定。

值得强调的是：MCP 不是 Anthropic 的私有协议。移交 Linux Foundation 意味着：

• 开源社区共同治理，任何组织都可以参与标准制定
• Apache 2.0 许可允许商业使用、修改、分发
• 已有大量社区构建的 MCP Server（GitHub、Slack、Postgres、Google Maps、Figma 等）

如果你担心"用了 MCP 是不是就被 Anthropic 锁定了"——不用担心。MCP 的定位和 Kubernetes、Node.js 一样：开放标准，多厂商实现。

常见误区：「MCP 就是 Function Calling 2.0」

这是最高频的误解。再次强调：

Function calling 是模型的能力。模型说"我理解了这个工具，我想调用它，参数是这个"。

MCP 是协议层标准。它规定"工具怎么被发现、怎么描述自己、调用请求长什么样、结果怎么返回、走什么传输通道"。

类比理解：

• Function calling 相当于"一个人会说英语"（语言能力）
• MCP 相当于"国际邮件的格式标准"（协议规范）

一个人会说英语（function calling），但如果每个人写信的格式不同，跨组织沟通仍然混乱。MCP 制定了统一的"信封格式"——发件人、收件人、主题、正文各放哪里——让任何会说英语的人都能高效沟通。

动手之前：你需要知道的基础概念

在本系列下一篇开始写代码之前，确保你已经内化了这几个概念：

1. MCP 的架构三角：Host（用户界面）→ Client（协议桥梁）→ Server（工具执行）。三层各司其职。
2. 三大原语的区别：Tools（模型调用）、Resources（应用读取）、Prompts（用户选择）。分清谁控制谁。
3. MCP ≠ Function Calling：MCP 是协议层，function calling 是模型能力。MCP Client 负责把 MCP 工具翻译成模型理解的 function calling 格式。
4. 传输无关：stdio 用于本地，Streamable HTTP 用于远程。写 Server 时不需要关心传输细节。

如果对 AI Agent 本身还不够熟悉，建议先阅读：

• 什么是 AI Agent — 从聊天机器人到自主智能体
• Agent 工具设计 — 如何为 AI Agent 选择合适的工具
• 手写第一个 AI Agent — 50 行代码实战

本系列路线图

MCP 协议系列共 6 篇文章，从概念到生产落地：

1. ← 你在这里：MCP 协议入门 — 概念、架构、对比
2. 构建你的第一个 MCP Server — 50 行 Python 实现天气查询工具
3. 深入 MCP 三大原语 — Tools/Resources/Prompts 完整实战
4. MCP 传输层详解 — stdio vs Streamable HTTP，何时用哪个
5. MCP 高级特性 — 让 Server 反向调用 LLM、请求用户输入、支持异步长任务
6. MCP 生产部署 — OAuth 2.1 认证、Gateway 代理、审计追踪与 Registry 发布

📖 下一篇：构建你的第一个 MCP Server — 用 50 行 Python 代码实现天气查询工具