MCP（Model Context Protocol，模型上下文协议）是一项连接 AI 应用与外部系统的开放标准。它统一了应用发现上下文、调用工具和交换消息的方式，让本地文件、数据库、业务 API 与远程服务可以通过相同的协议接入 AI 应用。

可以把 MCP 理解为 AI 应用的“标准扩展接口”：它规范连接与消息交换，但不替代模型推理，也不自动授予任何外部权限。

一、MCP 解决什么问题

没有统一协议时，每个 AI 应用都要为每种数据源或工具单独开发适配层。MCP 把连接方式、能力描述、调用格式和生命周期统一起来，使 Host 与 Server 可以独立演进。

  • 降低集成成本：Server 按统一规范暴露能力，Host 通过通用 Client 接入。
  • 隔离安全边界：Host 负责用户授权、上下文聚合和跨 Server 协调。
  • 支持渐进扩展：双方在初始化阶段声明能力，只使用本次会话协商成功的功能。

二、核心架构：Host、Client 与 Server

Host：应用容器与决策中心

Host 是用户直接使用的 AI 应用。它负责管理模型、创建 MCP Client、聚合上下文、执行安全策略，并决定何时向用户请求授权。

Client：一条隔离的协议连接

Host 通常为每个 Server 创建一个独立 Client。每个 Client 与一个 Server 保持一对一的有状态会话，负责初始化协商、双向消息路由、订阅与通知。

Server：能力提供方

Server 可以是 Host 启动的本地进程，也可以是独立部署的远程服务。它暴露聚焦且可组合的能力，但只能看到 Host 明确发送给它的信息，不应默认获得完整对话或其他 Server 的上下文。

三、三类核心能力

Tools：可执行操作

Tools 是可被模型选择调用的函数，例如查询订单、读取允许范围内的文件或生成报表。Server 通过 tools/list 描述工具，通过 tools/call 接收调用。工具名称与参数由 Server 定义，并不存在 mcp/file/read 这类统一业务接口。

Resources：可读取的上下文

Resources 用 URI 标识文件内容、数据库结构、Git 历史等数据。它们通常由应用选择并加入上下文，适合“读取信息”，不等同于执行有副作用的操作。

Prompts：可复用交互模板

Prompts 是 Server 提供的参数化提示模板，通常由用户主动选择，例如“根据销售数据生成周报”。它们帮助应用复用工作流，但最终如何展示和执行仍由 Host 决定。

控制关系可以简记为：Prompts 偏用户选择，Resources 偏应用管理，Tools 偏模型调用；Host 始终负责最终的安全与交互策略。

四、协议层：JSON-RPC 与生命周期

MCP 使用 JSON-RPC 2.0 编码请求、响应与通知。连接建立后，Client 先发送 initialize，双方交换协议版本、实现信息和能力声明；随后 Client 发送 notifications/initialized，进入正常通信阶段。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {},
    "clientInfo": { "name": "example-host", "version": "1.0.0" }
  }
}
  1. 初始化：协商协议版本与双方能力。
  2. 发现能力：调用 tools/list、resources/list 或 prompts/list。
  3. 执行交互：读取资源、获取提示或调用工具。
  4. 接收通知：处理能力列表变化、资源更新或进度消息。
  5. 关闭会话：按传输方式终止进程、连接或 HTTP 会话。

五、标准传输方式

stdio：本地进程通信

Client 启动 Server 子进程，通过标准输入发送消息、标准输出接收消息。stdout 只能输出合法 MCP 消息；日志应写入 stderr。它适合本地工具和桌面开发场景。

Streamable HTTP：远程服务通信

Server 提供一个同时支持 POST 与 GET 的 MCP 端点；GET 可以建立 SSE 流，POST 用于发送消息。Server 可在初始化响应中分配 Mcp-Session-Id，后续请求需携带该会话标识。

旧版 HTTP+SSE 传输已被 Streamable HTTP 替代。是否兼容旧传输取决于具体 Client 与 Server，不能假设自动兼容。

六、工具调用示例

假设销售分析 Server 声明了 analyze_sales 工具，Client 可以先查询工具清单，再按工具提供的 JSON Schema 构造调用：

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "analyze_sales",
    "arguments": {
      "file": "sales.xlsx",
      "groupBy": "category"
    }
  }
}

Server 返回结构化结果或文本、图片、资源链接等内容。业务执行失败通常通过工具结果中的 isError 表达；JSON-RPC 错误则用于方法不存在、参数非法等协议层问题。

七、电商周报场景：各组件如何协作

  1. 用户在 Host 中选择销售文件并提出“按品类分析并生成周报”的需求。
  2. Host 根据用户授权，把必要文件或资源范围提供给对应 Client。
  3. Client 从文件 Server 和分析 Server 获取可用 Tools、Resources 与参数结构。
  4. 模型在 Host 的编排下选择工具；Host 在敏感操作前执行授权或确认策略。
  5. Client 调用读取、分析、绘图和保存工具，各 Server 只处理自己收到的必要数据。
  6. Host 汇总结果，让模型生成周报，并向用户展示文本、图表和输出文件。
MCP 统一的是通信协议，不保证 Server 自动发现、工具绝对兼容或任务一定成功。这些体验仍取决于 Host、Server、模型和权限配置。

八、安全与授权

  • 最小权限：只暴露完成任务所需的目录、数据和操作。
  • 用户确认：写文件、发送消息、删除数据等高影响操作应提供清晰确认。
  • 远程授权：HTTP 场景按规范使用 OAuth，并将访问令牌放入 Authorization 请求头，不能放在 URL 查询参数中。
  • 输入校验：Server 必须校验参数、路径和资源归属，不能把模型输出直接当作可信指令。
  • 连接隔离：Host 不应在不同 Server 之间无条件共享完整对话或敏感上下文。

九、总结

MCP 的核心价值不是“让模型无所不能”，而是为 AI 应用与外部系统提供一套可协商、可隔离、可扩展的连接规范。理解 Host、Client、Server、三类核心能力、生命周期与传输层，就抓住了 MCP 的主干。