MCP 协议详解：AI 连接万物的标准接口

在 AI 应用开发中，有一个越来越突出的痛点：每个 AI 应用都需要为每个外部工具单独编写集成代码。假设你有 5 个 AI 应用（Claude Desktop、Cursor、ChatGPT 等）和 10 个外部工具（数据库、搜索引擎、日历、GitHub 等），理论上你需要编写 5 x 10 = 50 个独立的集成适配器。这就是所谓的 N x M 集成问题——随着 AI 应用和工具数量的增长，集成成本呈乘法式爆炸。

MCP（Model Context Protocol，模型上下文协议）正是为了解决这个问题而诞生的。它由 Anthropic 于 2024 年 11 月开源发布，目标是为 AI 模型与外部数据源、工具之间的通信建立一套开放、统一的标准协议。有了 MCP，AI 应用只需实现一次协议适配，就能连接所有遵循该协议的外部服务；反过来，工具开发者也只需实现一次 MCP Server，就能被所有支持 MCP 的 AI 应用调用。

MCP 的核心思想：AI 的 USB 接口

理解 MCP 最好的类比就是 USB 协议。在 USB 出现之前，每种外设（打印机、键盘、鼠标、相机）都有自己专属的接口和驱动。一台电脑要连接多个外设，需要多种不同的接口。USB 的出现统一了这一切——一个标准接口连接所有外设。

MCP 对 AI 生态做的事情和 USB 完全一样：

图表加载中...

图表加载中...

从 N x M 变成 N + M：AI 应用只需实现 MCP Client（N 次），工具只需实现 MCP Server（M 次），总工作量从乘法降为加法。这正是标准协议的威力。

MCP 的三层架构

MCP 的架构设计清晰简洁，由三个角色构成：

图表加载中...

Host（宿主）：最外层的 AI 应用程序，比如 Claude Desktop、Cursor、Windsurf 等 IDE。Host 是用户直接交互的对象，它内部管理一个或多个 MCP Client 实例。Host 负责管理 Client 的生命周期，控制 Client 与 Server 之间的连接权限，以及协调来自不同 Server 的能力。

Client（客户端）：协议的客户端层，运行在 Host 内部。每个 Client 实例维持与一个 MCP Server 的一对一连接。Client 负责协议协商（能力交换）、消息路由、以及与对应 Server 之间的双向通信。

Server（服务端）：轻量级的服务程序，负责对外暴露特定的能力。每个 Server 通常聚焦于一个领域——比如文件系统 Server 提供文件读写能力，GitHub Server 提供仓库操作能力，数据库 Server 提供查询能力。Server 的设计哲学是保持轻量，一个 Server 做好一件事。

MCP 的关键设计决策是 Client 与 Server 之间的一对一关系。每个 Client 连接一个 Server，Host 通过管理多个 Client 来接入多个 Server。这种设计保证了安全隔离——不同 Server 之间互不感知，一个 Server 的异常不会影响其他 Server。

四大核心原语

MCP 定义了四种核心原语（Primitives），它们是 Server 能够对外暴露的基本能力类型。

Resources（资源）

Resources 是 Server 暴露给 AI 的数据。资源可以是文件内容、数据库记录、API 返回的数据、实时日志等任何可以用文本或二进制表示的内容。资源通过 URI 标识，由 Client 主动拉取（而非 Server 推送），用于为模型提供上下文信息。

{
  "uri": "file:///project/src/main.ts",
  "name": "项目入口文件",
  "mimeType": "text/typescript",
  "description": "TypeScript 项目的主入口文件"
}

资源的典型用法是让 AI 在回答问题前先"阅读"相关资料。比如用户问"这个项目的架构是什么"，Client 可以先从文件系统 Server 拉取项目的关键文件作为上下文，再交给模型分析。

Tools（工具）

Tools 是 Server 暴露给 AI 的可执行操作。与 Resources 的只读性质不同，Tools 代表可以产生副作用的行为——发送邮件、创建 GitHub Issue、执行 SQL 查询、调用第三方 API 等。Tools 由模型发起调用请求，经 Host 应用的权限审批后执行。

{
  "name": "query_database",
  "description": "在 PostgreSQL 数据库中执行 SQL 查询",
  "inputSchema": {
    "type": "object",
    "properties": {
      "sql": {
        "type": "string",
        "description": "要执行的 SQL 查询语句"
      },
      "database": {
        "type": "string",
        "description": "目标数据库名称"
      }
    },
    "required": ["sql"]
  }
}

Tools 的调用遵循"人在回路"（Human-in-the-Loop）原则：模型决定调用什么工具、传什么参数，但最终执行前需要经过 Host 应用的确认。这确保了安全性——AI 不会在用户不知情的情况下执行危险操作。

Prompts（提示模板）

Prompts 是 Server 预定义的可复用提示模板。Server 可以暴露一组经过精心设计的 Prompt 模板，Client 可以检索并使用这些模板。模板支持参数化——定义占位符，由用户在使用时填入具体值。

{
  "name": "code_review",
  "description": "对代码进行专业评审",
  "arguments": [
    {
      "name": "code",
      "description": "需要评审的代码",
      "required": true
    },
    {
      "name": "language",
      "description": "编程语言",
      "required": false
    }
  ]
}

Prompts 让领域专家可以将最佳实践沉淀为可复用的模板。比如数据库 Server 可以提供"SQL 优化建议"模板，安全审计 Server 可以提供"代码安全审查"模板。

Sampling（采样）

Sampling 是最特殊的原语——它允许 Server 反向请求 LLM 生成内容。前三个原语的方向是 Client 调用 Server，而 Sampling 的方向相反：Server 通过 Client 向 Host 中的 LLM 发起补全请求。

这个能力开启了许多高级场景。比如一个代码分析 Server 在扫描完代码后，可以请求 LLM 对发现的问题生成自然语言的总结报告；一个数据处理 Server 在完成数据转换后，可以请求 LLM 对结果做智能解读。

图表加载中...

Sampling 同样遵循"人在回路"原则。Server 发起的 LLM 调用请求必须经过 Host 的审批和过滤，Host 可以修改请求内容、拒绝请求，或对返回结果做脱敏处理。

四大原语的控制权对比

通信机制

MCP 的通信层基于 JSON-RPC 2.0 协议。所有的消息交换（方法调用、通知、响应）都遵循 JSON-RPC 2.0 的格式规范。这意味着每条消息都是结构化的 JSON 对象，包含方法名、参数、请求 ID 等字段。

一次典型的工具调用通信流程：

图表加载中...

传输层

MCP 将协议层和传输层解耦，目前支持两种传输方式：

stdio（标准输入/输出）：Server 作为本地子进程运行，Client 通过 stdin/stdout 与 Server 通信。这种方式适合本地工具，零网络开销，启动快速。比如 Claude Desktop 中配置的本地 MCP Server 就采用这种方式。

HTTP + SSE（Server-Sent Events）：Client 通过 HTTP POST 发送请求，Server 通过 SSE 推送响应和通知。这种方式适合远程服务部署，支持跨网络调用。

连接生命周期

一个完整的 MCP 连接从初始化到关闭，经历三个阶段：

初始化：Client 发送 initialize 请求，携带自身支持的协议版本和能力列表。Server 返回自己的协议版本和能力列表。双方完成能力协商后，Client 发送 initialized 通知，连接正式建立。

正常通信：Client 和 Server 之间进行双向的 JSON-RPC 消息交换——请求/响应、通知等。

关闭：任一方可以发起关闭。Client 发送 close 请求，或直接断开传输层连接。

实战示例：构建一个 MCP Server

下面用 TypeScript 展示如何构建一个简单的天气查询 MCP Server。这个 Server 暴露一个 get_weather 工具，接收城市名称参数，返回天气信息。

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

// 创建 MCP Server 实例
const server = new McpServer({
  name: "weather-server",
  version: "1.0.0",
});

// 注册工具：查询天气
server.tool(
  "get_weather",
  "查询指定城市的天气信息",
  {
    city: z.string().describe("城市名称，如北京、上海"),
  },
  async ({ city }) => {
    // 实际项目中这里会调用真实的天气 API
    const weatherData = await fetchWeather(city);
    return {
      content: [
        {
          type: "text",
          text: JSON.stringify(weatherData, null, 2),
        },
      ],
    };
  }
);

// 注册资源：暴露支持的城市列表
server.resource(
  "supported-cities",
  "cities://list",
  async (uri) => ({
    contents: [
      {
        uri: uri.href,
        mimeType: "application/json",
        text: JSON.stringify(["北京", "上海", "广州", "深圳"]),
      },
    ],
  })
);

// 使用 stdio 传输层启动 Server
const transport = new StdioServerTransport();
await server.connect(transport);

在 Claude Desktop 中使用这个 Server，只需在配置文件中添加：

{
  "mcpServers": {
    "weather": {
      "command": "node",
      "args": ["path/to/weather-server.js"]
    }
  }
}

配置完成后，Claude 就能在对话中自动识别并调用天气查询工具。当用户问"北京今天天气怎么样"，模型会自动调用 get_weather 工具，拿到结果后组织成自然语言回答。

MCP vs 传统集成方式

MCP 并不是要替代 Function Calling，而是在更高的层面上解决问题。Function Calling 定义的是模型如何调用一个具体的函数，而 MCP 定义的是 AI 应用如何发现、连接和使用外部服务的整套协议。一个 MCP Server 暴露的 Tools，最终仍然是通过 Function Calling 的方式被模型调用的。

生态现状与发展趋势

MCP 协议发布后，已获得行业的广泛认可和快速采纳：

AI 应用端：Claude Desktop 率先原生支持 MCP。随后 Cursor、Windsurf、Cline 等主流 AI IDE 相继接入。连 OpenAI 也在其产品中加入了 MCP 支持，标志着这一协议正在成为行业事实标准。

Server 生态：社区已经涌现出大量开源 MCP Server，覆盖了主流的开发工具和平台。包括文件系统、GitHub、GitLab、Slack、PostgreSQL、MongoDB、Google Drive、Notion 等。开发者可以直接使用这些现成的 Server，也可以参考它们构建自己领域的 Server。

SDK 支持：官方提供了 TypeScript 和 Python 两个主要语言的 SDK，社区也贡献了 Go、Rust、Java 等语言的实现。这大大降低了构建 MCP Server 的门槛。

发展趋势：MCP 目前仍在快速演进中。远程 Server 的标准化、OAuth 认证集成、Server 注册与发现机制等都是社区活跃讨论的方向。可以预见，随着 AI Agent 应用的爆发式增长，MCP 作为 AI 与外部世界交互的标准协议，将扮演越来越重要的基础设施角色。

对于 AI 应用开发者来说，现在是学习和拥抱 MCP 的最佳时机。无论你是想让自己的 AI 产品对接更多工具，还是想让自己的服务被更多 AI 应用使用，MCP 都提供了一条标准化的路径。