Model Context Protocol (MCP) 简单介绍

法号：行颠

273人浏览 · 2026-06-05 14:34:13

法号：行颠 · 2026-06-05 14:34:13 发布

Model Context Protocol (MCP) 简单介绍

1. 概述

Model Context Protocol (MCP) 是一个开放协议，旨在标准化应用程序向大型语言模型（LLM）提供上下文的方式。可以将其视为 AI 应用的 USB-C 接口：它为 AI 助手（如 Claude Desktop、Claude Code）提供了连接各种数据源和工具的标准化方式。

MCP 的核心目标是解决 AI 模型与外部世界（数据、工具、API）交互时的碎片化问题。通过 MCP，开发者无需为每个数据源编写定制的集成代码，即可让 AI 应用安全、统一地访问文件、数据库、API 等多种资源。

MCP 项目范围

MCP 项目包括以下组成部分：

MCP 规范：定义客户端和服务器实现要求的详细规范
MCP SDKs：多种编程语言的官方 SDK（如 Python、TypeScript、Kotlin）
MCP 开发工具：用于开发和调试的辅助工具（如 MCP Inspector）
MCP 参考服务器实现：官方提供的参考示例

MCP 聚焦于上下文交换协议本身，并不规定 AI 应用如何使用 LLM 或管理获取的上下文。

2. 核心架构

MCP 采用经典的客户端-服务器架构。

2.1 核心参与者

参与者	角色说明
MCP 主机 (Host)	发起连接的 AI 应用，如 Claude Desktop、Claude Code 或自定义的 AI 工具。它负责协调和管理多个 MCP 客户端。
MCP 客户端 (Client)	与单个 MCP 服务器保持一对一连接的组件。主机为每个服务器创建一个专用客户端。
MCP 服务器 (Server)	提供上下文数据的轻量级程序。服务器可以暴露工具、资源和提示。它们可以运行在本地（如通过 stdio）或远程服务器上（如通过 HTTP）。

2.2 部署模式

本地服务器：通过 stdio 传输，与客户端运行在同一台机器上，通常服务于单个客户端，性能最优。
远程服务器：通过 Streamable HTTP 传输，运行在远程平台，可同时服务多个客户端，支持标准的 Web 认证机制（如 OAuth）。

3. 协议分层

MCP 协议由两个核心层构成：

3.1 数据层

数据层定义了基于 JSON-RPC 2.0 的消息交换格式和协议语义，是开发者最需要关注的部分。

生命周期管理：处理连接初始化、协议版本协商、能力协商和连接终止。
服务器功能：定义服务器可暴露的核心原语（工具、资源、提示）。
客户端功能：定义客户端可向服务器提供的功能（如采样、用户启发、日志）。
通知与进度跟踪：支持实时通知和长时间运行操作的进度上报。

3.2 传输层

传输层负责处理客户端和服务器之间的实际通信渠道和认证。

传输机制	通信方式	主要特点	适用场景
标准 I/O (stdio)	通过标准输入/输出流进行进程通信	性能高、无网络开销	本地进程间通信
可流式 HTTP	HTTP POST + 可选的 SSE 流	支持远程通信、标准 HTTP 认证、可扩展	远程服务器、微服务架构

4. 核心原语

原语是 MCP 中最重要的概念，定义了具体的交互能力。

4.1 服务器端原语（主要能力）

原语	用途	说明	方法示例
工具 (Tools)	执行操作	AI 模型可调用的可执行函数，通常具有副作用，如文件操作、API 调用、数据库查询。	`tools/list` `tools/call`
资源 (Resources)	提供数据	向 AI 应用提供上下文数据，通常无副作用，如文件内容、数据库记录、API 响应。	`resources/list` `resources/read`
提示 (Prompts)	引导交互	可复用的模板，用于指导 AI 模型的行为，如系统提示、少样本示例。	`prompts/list` `prompts/get`

三者对比：

工具：动词，做某事（写操作）
资源：名词，读数据（读操作）
提示：形容词/模板，影响如何回复

4.2 客户端原语（高级交互）

原语	方向	说明
采样 (Sampling)	服务器 → 客户端	服务器请求客户端的主机 AI 模型生成文本补全，使服务器无需自带模型能力。
启发 (Elicitation)	服务器 → 客户端	服务器主动向用户询问额外信息或确认操作。
日志 (Logging)	服务器 → 客户端	服务器将调试或状态信息发送给客户端。
任务 (Tasks)	双向	[实验性] 用于长时间运行或分批处理的耐久性执行包装器。

4.3 通知系统

协议支持 JSON-RPC 2.0 格式的通知（无 id 字段），用于实时状态同步。例如，当服务器的工具列表发生变化时，可以发送 notifications/tools/list_changed 让客户端及时刷新。

5. 完整交互示例：天气查询

下面通过一个完整的天气查询示例，展示 MCP 协议的实际运行流程。

场景描述

用户在一个 MCP 启用的 AI 应用中输入：“北京今天天气怎么样？”

步骤 1：连接与初始化

AI 应用（主机）启动，其 MCP 客户端与天气服务器建立连接（例如通过 stdio），并完成能力协商。

客户端发送 initialize 请求：

json

{
  “jsonrpc”: “2.0”，
  “id”: 1，
  “method”: “initialize”，
  “params”: {
    “protocolVersion”: “2025-06-18”，
    “capabilities”: { “elicitation”: {} }，
    “clientInfo”: { “name”: “my-ai-app”， “version”: “1.0.0” }
  }
}

服务器回复能力：

json

{
  “jsonrpc”: “2.0”，
  “id”: 1，
  “result”: {
    “protocolVersion”: “2025-06-18”，
    “capabilities”: { “tools”: { “listChanged”: true } }，
    “serverInfo”: { “name”: “weather-server”， “version”: “1.0.0” }
  }
}

客户端发送初始化完成通知：

json

{
  “jsonrpc”: “2.0”，
  “method”: “notifications/initialized”
}

步骤 2：发现可用工具

客户端询问服务器可用的工具。

请求：

json

{
  “jsonrpc”: “2.0”，
  “id”: 2，
  “method”: “tools/list”
}

响应（服务器返回 get_current_weather 工具的定义）：

json

{
  “jsonrpc”: “2.0”，
  “id”: 2，
  “result”: {
    “tools”: [
      {
        “name”: “get_current_weather”，
        “description”: “获取指定城市的当前天气”，
        “inputSchema”: {
          “type”: “object”，
          “properties”: {
            “location”: { “type”: “string”， “description”: “城市名称” }，
            “unit”: { “type”: “string”， “enum”: [“celsius”， “fahrenheit”] }
          },
          “required”: [“location”]
        }
      }
    ]
  }
}

步骤 3：AI 决策与工具调用

AI 模型识别用户意图，决定调用工具。客户端发送执行请求。

请求：

json

{
  “jsonrpc”: “2.0”，
  “id”: 3，
  “method”: “tools/call”，
  “params”: {
    “name”: “get_current_weather”，
    “arguments”: { “location”: “北京”， “unit”: “celsius” }
  }
}

响应（服务器返回天气数据）：

json

{
  “jsonrpc”: “2.0”，
  “id”: 3，
  “result”: {
    “content”: [
      {
        “type”: “text”，
        “text”: “北京当前天气：晴朗，温度 25°C，湿度 45%。”
      }
    ]
  }
}

步骤 4：生成最终回复

AI 应用将天气信息作为上下文返回给模型，模型生成最终回复给用户：“北京今天天气晴朗，温度 25°C，湿度 45%，适合户外活动。”

步骤 5：动态更新（可选）

如果天气服务器后续增加了 get_forecast 工具，它可以主动发送通知。

通知：

json

{
  “jsonrpc”: “2.0”，
  “method”: “notifications/tools/list_changed”
}

客户端收到后，会重新请求 tools/list，刷新工具列表，使 AI 模型能立即使用新功能。

6. 总结与设计理念

6.1 核心优势

优势	说明
标准化	统一的协议，避免为每个数据源编写定制集成
动态发现	客户端可以动态发现服务器提供的工具/资源，无需硬编码
松耦合	服务器无需依赖特定 LLM SDK，通过“采样”功能解耦
安全可控	支持 OAuth 等标准认证，传输层可插拔
实时性	通过通知机制支持动态状态同步
可扩展	支持从本地单客户端到远程多客户端的部署模式