MCP（模型上下文协议）

1.1 MCP 是什么？

MCP（Model Context Protocol，模型上下文协议） 是一个开放标准协议，用于标准化大语言模型（LLM）与外部数据源、工具和服务之间的交互方式。它由 Anthropic 于 2024 年 11 月 开源发布，被业界广泛比喻为 "AI 应用的 USB-C 接口"——提供统一的即插即用集成方式，让任何 AI 模型都能以标准化的方式访问外部世界。

1.2 要解决的核心问题：M × N 集成困境

在 MCP 出现之前，AI 应用与外部工具的集成面临一个经典的 "M × N 问题"：

• 如果有 M 个 AI 应用（Claude、ChatGPT、Gemini、Cursor 等）
• 有 N 个外部工具/数据源（GitHub、PostgreSQL、Slack、文件系统等）
• 每个组合都需要定制开发一套连接器，总复杂度为 O(M × N)

MCP 的解决方案是将这个问题转化为 "M + N 问题"：

• 每个数据源/工具只需要构建一个 MCP Server
• 每个 AI 应用只需要实现一个 MCP Client
• 任何 Client 都可以连接任何 Server，总复杂度降为 O(M + N)

传统模式：M 个应用 × N 个工具 = M×N 个定制集成
┌─────┐    ┌─────┐    ┌─────┐
│App 1│───→│Tool 1│    │Tool 2│
│App 2│───→│Tool 1│    │Tool 2│
│App 3│───→│Tool 1│    │Tool 2│
└─────┘    └─────┘    └─────┘
  6 条定制连接

MCP 模式：M 个 Client + N 个 Server = M+N 个标准连接
┌─────┐              ┌─────┐
│App 1│──┐        ┌──│Tool 1│
│App 2│──┤ MCP   ├──│Tool 2│
│App 3│──┘        └──│Tool 3│
└─────┘              └─────┘
  统一的协议层，任意组合

1.3 发展历程

2.1 三层角色模型：Host-Client-Server

MCP 采用 Host-Client-Server 三层架构，职责高度分离：

┌───────────────────────────────────────────────┐
│                  MCP Host（主机）               │
│  ┌─────────────────────────────────────────┐  │
│  │          AI 模型（LLM）                   │  │
│  └─────────────────────────────────────────┘  │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐    │
│  │Client #1 │  │Client #2 │  │Client #3 │    │
│  │(1:1连接) │  │(1:1连接) │  │(1:1连接) │    │
│  └────┬─────┘  └────┬─────┘  └────┬─────┘    │
└───────┼──────────────┼──────────────┼─────────┘
        │              │              │
   ┌────▼─────┐  ┌─────▼────┐  ┌─────▼────┐
   │Server #1 │  │Server #2 │  │Server #3 │
   │(文件系统) │  │(数据库)   │  │(GitHub)  │
   └──────────┘  └──────────┘  └──────────┘

MCP Host（主机）

Host 是运行 AI 模型的顶层应用，是唯一可以接触完整对话上下文和用户交互的实体。典型例子：Claude Desktop、Cursor、VS Code、Continue.dev。

核心职责：

• 创建和管理多个 MCP Client 实例
• 执行安全策略和用户授权决策（例如：高风险工具操作需用户显式批准）
• 协调 LLM 推理与上下文聚合
• 管理 Server 的生命周期（启动、监控、关闭）
• 安全边界守护者：Server 之间彼此隔离，不能互相"看到"

MCP Client（客户端）

Client 由 Host 创建，与一个 MCP Server 维持 1:1 的长连接。

核心职责：

• 处理协议协商和能力交换（capability negotiation）
• 双向路由 JSON-RPC 消息（转发 LLM 的工具调用请求、回传 Server 的执行结果）
• 维护 Server 之间的安全隔离
• 管理传输层连接（stdio 子进程或 HTTP 连接）

MCP Server（服务器）

Server 是暴露具体能力的轻量级服务，是 MCP 生态中最核心的可组合单元。

核心职责：

• 通过三大原语暴露能力：Resources（资源）、Tools（工具）、Prompts（提示模板）
• 职责高度集中、单一——"做好一件事"
• 可运行在本地进程（stdio）或远程服务（HTTP）
• 不知道对话上下文，也看不到其他 Server 的存在——这是安全隔离的核心设计

2.2 传输层

MCP 支持多种传输机制，适应不同的部署场景：

2.3 设计原则

MCP 的设计遵循以下核心原则，理解这些原则有助于把握协议的整体哲学：

1. Server 极简化：Server 只需专注单一功能，所有复杂的编排、安全、用户交互逻辑由 Host 承担。构建一个 MCP Server 的门槛极低。
2. 高度可组合：多个 Server 可以无缝组合，LLM 在一次对话中可以同时使用文件系统 Server、数据库 Server 和 GitHub Server。
3. 安全隔离：Server 之间完全隔离，一个 Server 不能读取对话历史，也不能"看到"其他 Server 的存在。这从根本上防止了权限横向扩散。
4. 渐进式功能扩展：核心协议保持最小化，高级功能通过能力协商按需启用，确保良好的向后兼容性。
5. 模型无关：MCP 不绑定任何特定 LLM 或 AI 厂商，任何支持工具调用的模型都可以通过 MCP Client 消费 MCP Server。

MCP 定义了三个 Server 端的核心原语（Primitives）和多个补充特性，构成了协议的能力体系。

3.1 Resources（资源）—— "模型可以读取什么"

Resources 是只读的上下文数据，代表模型可以消费的信息。类似于 REST 中的 GET 操作——提供信息而不产生副作用。

核心特征：

• 通过 URI 标识（如 file:///path/to/doc、postgres://localhost/users、weather://current/sf）
• 包含 MIME 类型（text/markdown、application/json、image/png）
• 支持静态资源（固定文件）和动态资源（带路径参数的实时数据，如 users://{userId}/profile）
• 应用控制——通常呈现给用户选择，确认后再注入 LLM 上下文
• 支持订阅机制：Client 可以订阅资源变更通知（listChanged），当文件被修改或数据更新时自动通知 Host

API 接口：

• resources/list — 发现可用的 Resources
• resources/read — 读取指定 Resource
• resources/subscribe — 订阅 Resource 变更
• notifications/resources/list_changed — Server 推送变更通知

3.2 Tools（工具）—— "模型可以做什么"

Tools 是模型可以调用的可执行函数，用于执行有副作用的操作。类似于 REST 中的 POST/PUT/DELETE——操作会改变外部系统状态。

核心特征：

• 每个 Tool 定义名称、描述、输入 Schema（JSON Schema）
• LLM 根据用户意图自主决定调用哪个 Tool（模型控制）
• 实际执行前通常需要用户批准（Host 负责权限控制）
• 运行时动态发现——Client 通过 tools/list 实时获取当前可用的 Tool 列表
• Server 可以通过 notifications/tools/list_changed 推送变更

Tool 的 JSON Schema 定义示例：

{
  "name": "create_github_issue",
  "description": "在指定仓库中创建一个新的 GitHub Issue",
  "inputSchema": {
    "type": "object",
    "properties": {
      "repo": {
        "type": "string",
        "description": "仓库全名，格式为 owner/repo"
      },
      "title": {
        "type": "string",
        "description": "Issue 标题"
      },
      "body": {
        "type": "string",
        "description": "Issue 正文（Markdown 格式）"
      },
      "labels": {
        "type": "array",
        "items": { "type": "string" },
        "description": "要添加的标签列表"
      }
    },
    "required": ["repo", "title"]
  }
}

API 接口：

• tools/list — 发现可用的 Tools
• tools/call — 调用指定 Tool（传入参数，获取结果）

3.3 Prompts（提示模板）—— "对话如何开始"

Prompts 是可复用的参数化对话模板，用于编码专家知识和标准化交互流程。它不像 Tool 那样由模型自主调用，而是由用户控制——通常以斜杠命令或 UI 选项的形式呈现。

核心特征：

• 接受可选的参数化输入（如 analyze-table 提示接受一个表名参数）
• 用户控制——用户通过 UI 或命令显式调用
• 整合了领域最佳实践（如代码审查规范、Kubernetes 故障排查流程）
• 不是让模型调用的，而是给用户提供的结构化交互起点

API 接口：

• prompts/list — 列出可用的提示模板
• prompts/get — 获取指定提示模板的内容（含参数渲染）

3.4 Sampling（采样）—— "Server 也可以请求 LLM"

Sampling 是 MCP 中最强大的"反向调用"机制：它允许 Server 主动请求 Host 的 LLM 进行推理，而不是像通常那样只能被动等待 Client 调用。这反转了传统的调用方向，使得 Server 可以发起智能体（Agentic）行为。

典型应用场景：

• 多智能体协调：一个 Server 将复杂推理委托给主 LLM
• 子智能体委派：数据查询 Server 需要 LLM 帮助解析用户的自然语言查询意图
• 递归智能体工作流：Server A 执行任务过程中，需要 LLM 评估中间结果并决定下一步

3.5 Roots（根目录）—— 定义 Server 的访问边界

Roots 是 Client 向 Server 声明的文件系统边界，定义了 Server 可以访问的目录范围。这为文件系统操作提供了最小权限的安全约束。

3.6 Elicitation（用户询问）—— Server 可以向用户请求信息

Elicitation 是 v2025-06-18 规范新增的功能：Server 在执行过程中可以向用户请求额外输入（例如通过表单），而不需要中断连接或通过 LLM 来回传递信息。这解决了"Server 需要用户输入，但无法直接交互"的痛点。

3.7 结构化输出（Structured Output）

同样是 v2025-06-18 新增：Tool 的返回结果可以包含 structuredContent 字段，附带 JSON Schema 进行结构验证。这使得 Tool 结果可以被可靠地解析和联动，而不是只能返回非结构化文本。

4.1 JSON-RPC 2.0 基础

MCP 完全基于 JSON-RPC 2.0 协议。所有消息都是 JSON 格式，分为三种类型：

JSON-RPC 消息格式示例：

// Request（请求）
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "create_github_issue",
    "arguments": {
      "repo": "my-org/my-repo",
      "title": "修复登录页面 Bug"
    }
  }
}

// Response - 成功（响应）
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      { "type": "text", "text": "Issue #42 已创建" }
    ]
  }
}

// Response - 错误（响应）
{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32602,
    "message": "Invalid params",
    "data": { "reason": "缺少必填字段 'repo'" }
  }
}

// Notification（通知，无 id，无响应）
{
  "jsonrpc": "2.0",
  "method": "notifications/tools/list_changed"
}

4.2 协议版本控制

MCP 在应用层实现了严格的协议版本协商机制：

• 每个请求的 _meta 字段携带协议版本号
• HTTP 请求必须包含 MCP-Protocol-Version 请求头
• Server 可通过 server/discover 端点宣告自身支持的版本列表
• 当前最新版本为 2025-11-25

4.3 初始化握手流程

MCP 的连接生命周期分为三个严格有序的阶段：

阶段                消息流
────────────────────────────────────────
初始化（Initialization）
                     Client ──initialize──► Server
                     Client ◄──response─── Server
                     Client ──initialized─► Server  (通知，无响应)
────────────────────────────────────────
运行（Operation）
                     双方可以正常通信
────────────────────────────────────────
关闭（Shutdown）
                     传输层断开 → 连接终止

第一步：Client 发送 initialize 请求

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "roots": { "listChanged": true },
      "sampling": {}
    },
    "clientInfo": {
      "name": "ClaudeDesktop",
      "version": "2.0.0"
    }
  }
}

第二步：Server 返回能力声明

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "logging": {},
      "prompts": { "listChanged": true },
      "resources": { "subscribe": true, "listChanged": true },
      "tools": { "listChanged": true }
    },
    "serverInfo": {
      "name": "GitHubServer",
      "version": "3.1.0"
    }
  }
}

第三步：Client 发送 notifications/initialized 通知

{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}

关键时序约束：

• Client 在收到 initialize 响应之前，不得发送任何非 ping 的请求
• Server 在收到 notifications/initialized 之前，不得发送任何非 ping 和 logging 的请求
• 违反时序约束的请求将被拒绝

4.4 能力协商（Capability Negotiation）

MCP 使用基于能力声明的协商系统，在初始化阶段确定会话期间可用的功能集：

Client 端可声明的能力：

Server 端可声明的能力：

能力声明的核心原则是 "少即是多"——只声明你实际支持的功能。如果 Server 声明了 tools 能力但没有列出工具，Client 应该能正常处理。

4.5 连接关闭

MCP 没有专门的关闭消息。关闭通过底层传输机制实现：

• stdio 模式：Client 关闭子进程的输入流；必要时逐步升级至 SIGTERM → SIGKILL
• HTTP 模式：关闭 HTTP 连接即表示会话终止

MCP 与各 LLM 厂商的 Function Calling（或 Tool Use）机制并不是竞争关系，而是解决不同层次的问题。

5.1 本质区别

Function Calling / Tool Use（厂商级工具调用）
  ── 是模型的"输出格式"
  ── 让 LLM 输出结构化的工具调用意图
  ── 属于单模型、单应用的范畴

MCP（模型上下文协议）
  ── 是工具调用的"基础设施标准"
  ── 定义工具如何被发现、管理、调用和治理
  ── 属于跨模型、跨应用的架构层面

类比理解：Function Calling 是"锤子怎么用"（单个工具的使用方式），MCP 是"工具箱的标准接规范"（所有工具如何对接和组织）。

5.2 详细对比

5.3 各自的优势场景

Function Calling 更适合：

• 快速原型验证
• 工具数量少（< 5 个）、单模型、单应用的场景
• 对延迟敏感的实时交互

MCP 更适合：

• 多智能体共享同一套后端工具
• 企业级多模型、多应用架构
• 需要审计、权限管控的受监管环境
• 工具生态需要持续演进和独立维护的场景

5.4 协同工作的混合架构

在实际生产系统中，二者通常协同使用：

用户输入
  ↓
LLM（使用 Function Calling 格式）→ 输出结构化的工具调用意图
  ↓
MCP Client → 将意图路由到对应的 MCP Server
  ↓
MCP Server → 执行实际操作（带认证、限流、审计）
  ↓
结果通过 MCP 返回 → 注入 LLM 上下文

结论：Function Calling 回答"模型想做什么"，MCP 回答"工具应该如何组织、管理和治理"。它们是互补关系，而非替代关系。

6.1 生态规模（截至 2026 年 Q1）

6.2 主流 MCP Server

官方参考实现

企业级集成

社区热门

6.3 应用 Host 支持矩阵

6.4 典型应用场景

场景一：智能编码助手

用户："帮我检查这个 PR，修复安全漏洞，然后写一份审查报告。"

Claude/Cursor (Host)
  ├── GitHub MCP Server → 读取 PR diff、查看 CI 状态
  ├── Filesystem MCP Server → 写入修复代码
  ├── GitHub MCP Server → 提交修复、发表审查评论
  └── Fetch MCP Server → 查阅 CVE 数据库获取漏洞细节

场景二：企业数据分析

用户："分析上季度销售数据，与去年同期对比，找出下滑最严重的区域。"

ChatGPT (Host)
  ├── Snowflake MCP Server → 执行 SQL 分析查询
  ├── Filesystem MCP Server → 生成 CSV 导出文件
  └── Slack MCP Server → 将报告发送到对应频道

场景三：自动化运维

用户："生产环境 CPU 告警，帮我排查根因并给出修复建议。"

Copilot (Host)
  ├── Docker MCP Server → 检查容器状态和日志
  ├── PostgreSQL MCP Server → 查询慢查询日志
  ├── Cloudflare MCP Server → 检查 CDN 和边缘节点状态
  └── Slack MCP Server → 通知 on-call 团队

7.1 开发语言与 SDK 选择

7.2 构建一个 MCP Server（TypeScript + FastMCP）

最小可运行示例

import { FastMCP } from "fastmcp";
import { z } from "zod";

// 1. 创建 Server 实例
const server = new FastMCP({
  name: "天气查询服务",
  version: "1.0.0",
});

// 2. 注册 Tool
server.addTool({
  name: "get_weather",
  description: "查询指定城市的实时天气信息。当用户询问天气时使用此工具。",
  parameters: z.object({
    city: z.string().describe("城市名称，如 '北京'、'上海'"),
    unit: z.enum(["celsius", "fahrenheit"]).default("celsius").describe("温度单位"),
  }),
  execute: async (args) => {
    const weather = await fetchWeatherAPI(args.city, args.unit);
    return `城市：${args.city}\n温度：${weather.temp}°\n天气：${weather.description}\n湿度：${weather.humidity}%`;
  },
});

// 3. 注册 Resource
server.addResource({
  uri: "weather://supported-cities",
  name: "支持的城市列表",
  mimeType: "application/json",
  load: async () => {
    const cities = ["北京", "上海", "广州", "深圳", "杭州"];
    return { text: JSON.stringify(cities, null, 2) };
  },
});

// 4. 启动 Server（stdio 模式）
server.start({ transportType: "stdio" });

Claude Desktop 配置

{
  "mcpServers": {
    "weather": {
      "command": "npx",
      "args": ["tsx", "/path/to/weather-server.ts"]
    }
  }
}

7.3 构建一个 MCP Server（Python）

from mcp.server import Server, FastMCP
from mcp.types import Tool, TextContent

mcp = FastMCP("天气查询服务")

@mcp.tool()
async def get_weather(city: str, unit: str = "celsius") -> str:
    """查询指定城市的实时天气信息。当用户询问天气时使用此工具。"""
    weather = await fetch_weather_api(city, unit)
    return f"城市：{city}\n温度：{weather['temp']}°\n天气：{weather['description']}"

@mcp.resource("weather://supported-cities")
async def supported_cities() -> str:
    """返回支持查询的城市列表"""
    import json
    cities = ["北京", "上海", "广州", "深圳", "杭州"]
    return json.dumps(cities, ensure_ascii=False, indent=2)

if __name__ == "__main__":
    mcp.run(transport="stdio")

7.4 构建一个 MCP Client

import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";

async function main() {
  const client = new Client(
    { name: "my-client", version: "1.0.0" },
    { capabilities: { sampling: {} } }
  );

  const transport = new StdioClientTransport({
    command: "npx",
    args: ["tsx", "./weather-server.ts"],
  });

  await client.connect(transport);

  const { tools } = await client.listTools();
  console.log("可用工具：", tools.map(t => t.name));

  const result = await client.callTool({
    name: "get_weather",
    arguments: { city: "北京", unit: "celsius" },
  });
  console.log("工具结果：", result.content[0].text);

  await client.close();
}

main().catch(console.error);

7.5 开发最佳实践

安全

1. 最小权限原则：每个 Tool 只授予完成其职责所必需的最小权限
2. 输入校验：TypeScript 使用 Zod、Python 使用 Pydantic 做严格的运行时参数校验
3. 认证鉴权：远程 Server 必须实施 OAuth 2.1 / JWT 认证，敏感操作要求用户显式批准
4. 沙箱执行：涉及文件系统和 Shell 的 Server 应在隔离环境中运行
5. Token 绑定：使用 Resource Indicators（RFC 8707）将 Token 绑定到特定 Server，防止横向滥用

Schema 设计

1. 工具命名：使用 snake_case，简短且描述性强（如 get_weather、create_issue）
2. 描述即文档：description 字段要清晰说明何时使用该工具，帮助 LLM 做出正确的调用决策
3. 参数约束：使用 enum、min/max、pattern 约束参数，减少 LLM 调用错误
4. 输出简洁：避免将大量无关文本注入 context window，结果应精炼、结构化

日志

1. stdio 模式下，所有日志必须写入 stderr，绝对不能打印到 stdout
2. 生产环境使用结构化日志（JSON 格式），便于聚合和告警

测试

建议的四步测试策略：

1. 单元测试：独立测试每个 Tool 的业务逻辑
2. MCP Inspector：使用官方调试工具 (npx @modelcontextprotocol/inspector) 手动测试 Server
3. 集成测试：模拟完整的 MCP 消息收发流程
4. 端到端测试：接入真实 LLM，验证工具被发现和正确调用的完整链路

8.1 MCP 的标准化前景

MCP 已经完成了从"公司协议"到"行业标准"的关键转型：

• 2025 年 12 月，Anthropic 将 MCP 捐赠给 Linux 基金会下属的 Agentic AI Foundation（AAIF），Block、OpenAI、Google、Microsoft、Amazon、Bloomberg、Cloudflare 作为联合创始成员加入
• 2026 年 4 月，MCP 1.0 正式发布，统一的语义化注册中心上线，相当于工具领域的 npm 或 Docker Hub
• AAIF 成员覆盖云计算三巨头（AWS、Azure、GCP）、主流 AI 厂商（OpenAI、Anthropic、Google）、企业软件巨头（SAP、Salesforce、Snowflake）

治理架构：

8.2 MCP 的 2026 路线图

AAIF 公开的 2026 年四大优先事项：

8.3 与 A2A 协议的关系

A2A（Agent-to-Agent Protocol） 是 Google 于 2025 年 4 月发布的协议，解决的是智能体之间的协作通信问题。

MCP 与 A2A 的关系——重点不在于竞争，而在于互补：

二者形成完整闭环：

数据源 ──→ MCP（单智能体赋能）──→ A2A（多智能体协作）──→ 最终结果

A2A 也已于 2025 年 6 月捐赠给 Linux 基金会，与 MCP 处于同一治理框架下。这为二者的深度整合提供了制度基础。

8.4 可能的挑战与风险

8.5 总结性判断

MCP 正在成为 AI Agent 时代的"TCP/IP"——它并非因为技术上的不可替代性而胜出，而是因为开放标准 + 社区治理 + 临界规模的网络效应这三者的叠加，形成了自我强化的正反馈循环。2026 年是 MCP 从"早期多数采用者"向"晚期多数"跨越的关键窗口期。对于技术团队而言，现在投资 MCP 不是在赌一个厂商，而是在赌一个已经形成的行业共识。

官方资源

• MCP 官方规范 — 协议规范的权威来源
• MCP 中文文档 — 社区维护的中文翻译
• MCP 官方 GitHub — SDK、Server 示例、讨论区
• MCP Servers 仓库 — 官方参考实现和社区 Server 索引

SDK 与工具

• TypeScript SDK — 官方 TypeScript SDK
• FastMCP (TypeScript) — TypeScript 上层框架
• Python SDK — 官方 Python SDK（内置 FastMCP 风格接口）
• MCP Inspector — 官方调试工具

深度文章

• MCP 2026: From Anthropic Proposal to Industry Standard — MCP 成为行业标准的历程分析
• MCP vs Function Calling: 7 Key Differences & Using Them Together — MCP 与 Function Calling 的深度对比
• A2A v. MCP: Why AI Agents Need Both — ISG Research 对两大协议关系的分析
• MCP vs A2A: Agentic AI protocols take shape — The Register 对协议格局的报道
• The Complete Guide to Model Context Protocol — Machine Learning Mastery 的全面指南

学术论文

• A Study on the MCP × A2A Framework for Enhancing Interoperability of LLM-based Autonomous Agents — MCP 与 A2A 协作框架的学术研究
• From Glue-Code to Protocols: A Critical Analysis of A2A and MCP Integration for Scalable Agent Systems — MCP 与 A2A 集成对可扩展智能体系统的分析

生态探索

• Awesome MCP Servers — 社区维护的 MCP Server 精选列表
• MCP Market — MCP Server 发现平台
• MCP Grep — MCP Server 搜索引擎

相关协议

• Agent-to-Agent Protocol (A2A) — Google 的智能体间通信协议
• AGNTCY — Cisco/LangChain 发起的智能体基础设施框架
• NANDA — MIT 提出的去中心化智能体发现与协调框架

文档生成信息：本文档基于 2026 年 5 月的公开资料研究整理，包含截至 MCP 1.0 发布（2026 年 4 月）的最新信息。协议规范持续演进中，建议以 modelcontextprotocol.io 官方文档为最终参考。