MCP 协议详解：工具调用的行业新标准

1.1 没有 MCP 之前：碎片化的工具调用

2024 年之前，AI 工具调用领域长期处于碎片化状态。

每个 AI 框架都有自己的工具调用接口：LangChain 有 @tool 装饰器，AutoGen 有自己的函数注册方式，直接调用 OpenAI API 又是另一套 JSON Schema 格式，LlamaIndex 又有不同的工具协议。同一个"查询数据库"功能，在四个框架里要写四遍，格式各不相同，完全不能复用。

更严重的问题是生态无法积累：一个开发者写了一套优秀的内部工具，只能在自己的框架里用。换个同事用不同框架，要从头重写。企业投入精力写好的工具集，换了 AI 应用就成了废代码。

这不是技术问题，是标准缺失问题。

2024 年 11 月，Anthropic 发布了 MCP（Model Context Protocol，模型上下文协议），提出了一个开放标准，试图从根本上解决这个碎片化问题。

1.2 MCP 是什么：AI 工具调用的 USB 接口

MCP 协议架构图
MCP 三层架构——Host（用户应用）通过内嵌的 Client 以 stdio 或 Streamable HTTP 连接各类 MCP Server

最直白的类比：MCP 是 AI 工具调用领域的 USB 接口。

USB 出现之前，每个外设都有不同的接口，鼠标、键盘、打印机、摄像头——换台电脑可能什么外设都得换。USB 出现之后，一个接口搞定所有外设，标准化让整个生态爆发式增长。

MCP 想做的事情完全类似：定义一套标准通信协议，工具提供方按照这个标准实现一次，所有支持 MCP 的 AI 应用都能使用。一次实现，到处使用。

具体来说：

GitHub 实现了一个 MCP Server（工具服务器），任何支持 MCP 的 AI 都能用来操作 GitHub
你实现了一个连接公司数据库的 MCP Server，不管是 Claude 桌面版、Cursor 编辑器还是你自己写的 AI 应用，都能用

1.3 MCP 的三层架构

MCP 的架构分为三个角色，理解这三个角色是理解 MCP 的关键：

MCP Host 是最终用户使用的应用。Claude 桌面版、Cursor 编辑器，或者你自己开发的 AI 应用，都是 Host。Host 是 AI 对话发生的地方，也是工具调用请求的发起方。

MCP Client 是内嵌在 Host 里的协议客户端，负责和 MCP Server 建立连接、发送请求、接收结果。用户一般感知不到 Client 的存在，它是 Host 和 Server 之间的"翻译官"。一个 Host 可以同时连接多个 MCP Server，每个连接对应一个 Client 实例。

MCP Server 是实际提供工具能力的一方。它可以是本地进程（通过标准输入输出通信），也可以是远程服务（通过 HTTP 通信）。Server 告诉 Client：我有哪些工具，参数是什么，怎么调用。

关键理解：MCP Server 和你日常说的"Web 服务器"不是一回事。MCP Server 更像是一个工具提供者——它的职责是把工具的能力以标准化格式暴露出来，等待 MCP Client 来调用，而不是直接面向用户提供网页服务。

1.4 MCP Server 能提供三类能力

MCP Server 可以向 Client 暴露三种类型的能力：

Tools（工具）：AI 可以调用的函数。"搜索网页"、"执行 SQL"、"发送邮件"、"创建文件"——这类能做实际操作的能力，用 Tool 来表达。这是 MCP 最核心的能力，也是最常用的。

Resources（资源）：AI 可以读取的数据。文件内容、数据库记录、API 返回的数据，都可以以 Resource 的形式暴露。资源是只读的——AI 请求读取，Server 返回内容，适合提供上下文信息。

Prompts（提示模板）：预定义好的 Prompt 模板，可以带参数。比如一个"代码审查"模板，传入代码文件路径，自动读取文件内容并构建标准化的审查 Prompt。这让 Prompt 工程的成果可以复用和共享。

1.5 通信方式：本地 vs 远程

MCP 支持两种主要传输方式，适合不同的部署场景：

stdio（标准输入输出）

Server 作为本地子进程运行，Host 通过标准输入输出（进程间通信最基本的方式，就像 pipe 管道）与它交换数据。

适合本地工具：文件系统操作、本地命令执行、访问本机数据库。启动快，没有网络开销，但只能在同一台机器上用。Claude 桌面版的配置文件就是配置本地 stdio Server。

Streamable HTTP

Server 作为 HTTP 服务运行，Client 通过 HTTP 请求和 Server 通信，支持双向流式通信。这是 MCP 推荐的远程传输方式（2025 年规范升级，取代了早期的 SSE 方式）。

适合远程部署：多个用户共用同一个 MCP Server，企业内部的工具服务集中部署，或者第三方 SaaS 工具的 MCP 接入。

1.6 一个完整的交互流程

当你在 Claude 桌面版里问"帮我查一下 GitHub 上有没有关于 MCP 的最新 issue"，背后发生的事情是：

code

1. Claude（Host）把你的问题发给 LLM
2. LLM 判断：需要查 GitHub，调用 GitHub MCP Server 的 search_issues 工具
3. LLM 返回工具调用请求（这就是第 9 章讲的 Function Calling）
4. MCP Client 把调用请求发给 GitHub MCP Server
5. GitHub MCP Server 真正调用 GitHub API，搜索 issue
6. Server 把搜索结果返回给 Client
7. Client 把结果转交给 LLM
8. LLM 整合结果生成最终回答

注意第 3 步：LLM 层面仍然是 Function Calling 机制，MCP 并没有改变这一点。MCP 解决的是第 4-6 步：工具服务如何以标准化格式暴露、如何被发现、如何传输结果。

1.7 MCP 与 Function Calling：不是竞争，是分层

这是很多人的困惑，需要说清楚。

Function Calling（第 9 章）是 LLM 的底层能力：模型输出结构化的工具调用请求，告诉调用方"我要调哪个工具、传什么参数"。这是模型层面的机制。

MCP 是生态层面的协议：定义工具服务如何被发现（能力列表）、如何调用（请求格式）、如何返回结果（响应格式）。

两者不冲突，而是不同层次：MCP Server 内部实现工具时，底层仍然依赖 Function Calling 机制。但对外暴露的是 MCP 协议接口，这样任何支持 MCP 的 Client 都能调用，而不用关心底层用的是哪个模型的 Function Calling 格式。

维度	Function Calling	MCP
是什么	LLM 输出工具调用意图的机制	工具服务的通信标准
解决什么	模型如何表达"要调用什么"	工具如何被发现和调用
适用场景	单个应用内的工具调用	跨应用、跨框架的工具复用
由谁定义	各 LLM 厂商（OpenAI、Anthropic 等）	Anthropic 发起，已成行业标准

1.8 MCP 生态现状（2026 年 3 月）

MCP 发布短短一年多，生态已经相当成熟：

官方支持的 MCP 客户端：Claude 桌面版（第一个）、Cursor、Windsurf、Continue、VS Code GitHub Copilot。

重要里程碑：OpenAI 在 2025 年宣布支持 MCP——最大的竞争对手也采用这个协议，基本宣告 MCP 成为了行业事实标准，就像 HTTP 之于 Web、REST 之于 API。

官方维护的 MCP Server：文件系统操作、GitHub、Google Drive、Slack、PostgreSQL 数据库、Puppeteer 浏览器自动化、Brave 搜索等。

社区 MCP Server：数千个社区贡献的 Server，覆盖各种数据库（MySQL、MongoDB、Redis）、SaaS 工具（Notion、Jira、Linear）、云服务（AWS、GCP）等。

1.9 为什么 MCP 对 Java 工程师特别重要

对于有 Java 背景的开发者，可以这样理解 MCP 的价值：

MCP 就像是 AI 工具领域的 JDBC（Java 数据库连接标准）。在 JDBC 之前，访问 MySQL 和访问 Oracle 是两套完全不同的 API；有了 JDBC，写一套代码，换个驱动就能连不同数据库。

MCP 做的是同样的事情：写一套工具服务，接入任何 AI 应用。企业把自己的内部系统——ERP、CRM、工单系统——接入 MCP，公司里所有的 AI 工具都能共用这套工具服务，不需要为每个 AI 单独写集成。

这是 AI 基础设施标准化的开始，也是 AI 从"玩具"走向"企业级生产工具"的必要条件。

下一篇：动手写第一个 MCP Server，用 Python 实现，在 Claude 桌面版中验证。