MCP(Model Context Protocol )协议

最新推荐文章于 2025-10-15 11:40:52 发布

原创最新推荐文章于 2025-10-15 11:40:52 发布 · 875 阅读

14 ·

CC 4.0 BY-SA版权

文章标签：

#人工智能 #AI

人工智能专栏收录该内容

5 篇文章

订阅专栏

MCP（Model Context Protocol ）介绍

Model Context Protocol 是一种开放标准，使开发人员能够在其数据源和 AI 驱动的工具之间构建安全的双向连接。架构很简单：开发人员可以通过 MCP 服务器公开他们的数据，也可以构建连接到这些服务器的 AI 应用程序（MCP 客户端）。

MCP介绍
 MCP使用

MCP 是一种开放协议，它对应用程序向大语言模型提供上下文的方式进行了标准化。可以将 MCP 想象成AI应用程序的 USB-C 接口。就像 USB-C 为将设备连接到各种外部设备和配件提供了一种标准化方式一样，MCP 为将AI模型连接到不同的数据源和工具提供了一种标准化方式。

1. 为何选择 MCP

MCP 帮助你在LLM(大语言模型)之上构建agent(代理)和复杂的工作流程。LLM经常需要与数据和工具集成，而 MCP 提供：

越来越多的预构建集成，你的LLM(大语言模型)可以直接接入这些集成。
在LLM(大语言模型)提供商和供应商之间进行灵活的切换
在基础架构中保护数据的最佳实践

2. 总体架构

本质上MCP 遵循Client-Server(客户端 - 服务器)架构，在这种架构中，主机应用程序可以连接到多个服务器：
在这里插入图片描述

MCP Hosts: 类似Claude 桌面应用程序、集成开发环境（IDEs），或者想要通过 MCP 访问数据的人工智能工具
MCP Clients: 与服务器保持 1对1 连接的协议客户端
MCP Servers: 轻量级程序，每个程序都通过标准化的模型上下文协议公开特定功能
Local Data Sources: MCP 服务器可以安全访问的您计算机的文件、数据库和服务
Remote Services: MCP 服务器可以连接到的互联网（例如，通过 API）提供的外部系统

3. MCP 的核心概念和功能

3.1 核心架构

了解 MCP 如何连接客户端、服务器和 LLM。
模型上下文协议（MCP）建立在灵活、可扩展的架构之上，可实现 LLM 应用程序和各种集成之间的无缝通信。

MCP 遵循客户端-服务器架构：

Hosts：启动连接的 LLM 应用程序（如 Claude Desktop 或 IDE）
Clients：在主机应用程序内与服务器保持 1对1 连接
Servers：向客户端提供上下文、工具和提示

在这里插入图片描述

3.1.1 核心组件

Protocol layer（协议层）

协议层处理消息帧、请求/响应链接和高级通信模式。
主要类包括：Protocol、Client、Server

Transport layer（传输层）

传输层负责处理客户端与服务器之间的实际通信。
所有传输都使用 JSON-RPC 2.0 进行消息交换。

MCP 支持多种传输机制：

Stdio transport：标准输入输出传输
使用标准输入 / 输出进行通信，非常适合本地进程
HTTP with SSE transport：采用服务器发送事件（SSE）传输的超文本传输协议（HTTP）
使用服务器发送事件来实现服务器到客户端的消息传递
使用 HTTP POST 来实现客户端到服务器的消息传递

传输层选择参考

本地通信

对本地进程使用标准输入输出传输
对于同一机器内的通信而言效率很高
简单的进程管理

远程通信

对于需要 HTTP 兼容性的场景，使用服务器发送事件（SSE）
考虑安全影响，包括身份验证和授权

Message types（消息类型）

MCP 包含以下主要类型的消息：
Requests 请求需要来自另一端的响应

interface Request {
  method: string;
  params?: { ... };
}

Results 结果是对请求的成功响应

interface Result {
  [key: string]: unknown;
}

Errors 错误指示请求失败

interface Error {
  code: number;
  message: string;
  data?: unknown;
}

Notifications 通知是不需要响应的单向消息

interface Notification {
  method: string;
  params?: { ... };
}

消息处理方式参考

请求处理

全面验证输入内容
使用类型安全的模式
优雅地处理错误
实现超时设置

进度报告

对长时间运行的操作使用进度令牌(tokens)
逐步汇报进展情况
在已知时纳入总体进展情况

错误管理

使用适当的错误代码
包含有用的错误信息
出错时清理资源

3.1.2 连接生命周期

1. Initialization 初始化

(1) 客户端发送带有协议版本和功能的初始化请求
(2) 服务器会响应其协议版本和功能
(3) 客户端发送已初始化通知作为确认
(4) 正常的消息交换开始
在这里插入图片描述
2. Message exchange 消息交换
初始化后，支持如下模式：
(1) Request-Response(请求-响应): 客户端或服务器发送请求，另一方做出响应
(2) Notifications(通知): 任何一方都发送单向消息

3.Termination 终止
任何一方都可以终止连接：
(1) 通过 close () 进行干净关闭
(2) 传输断开连接
(3) 错误情况

3.1.3 错误处理

MCP 定义了这些标准错误代码：

enum ErrorCode {
  // Standard JSON-RPC error codes
  ParseError = -32700,
  InvalidRequest = -32600,
  MethodNotFound = -32601,
  InvalidParams = -32602,
  InternalError = -32603
}

软件开发工具包（SDKs）和应用程序可以在 -32000 以上定义自己的错误代码。
错误通过以下方式传播:
(1) 请求的错误响应
(2) 传输上的错误事件
(3) 协议级错误处理程序

3.2 Resources 资源

将您服务器中的数据和内容提供给大语言模型

资源是模型上下文协议（MCP）中的核心基本要素，它允许服务器公开可由客户端读取的数据和内容，并将其用作大语言模型（LLM）交互的上下文。
资源旨在由应用程序控制，这意味着客户端应用程序可以决定如何以及何时使用它们。不同的 MCP 客户端处理资源的方式可能有所不同。

3.2.1 资源介绍

资源代表 MCP 服务器希望向客户端提供的任何类型的数据。这可能包括：

文件内容
数据库记录
API 响应
实时系统数据
屏幕截图和图像
日志文件
其他

每个资源都由唯一的统一资源标识符（URI）标识，并且可以包含文本数据或二进制数据。

3.2.2 Resource URIs 资源统一资源标识符

资源使用遵循以下格式的统一资源标识符 (URI) 进行标识：

[protocol]://[host]/[path]

例如:

file:///home/user/documents/report.pdf
postgres://database/customers/schema
screen://localhost/display1

协议和路径结构由 MCP 服务器实现定义。服务器可以定义自己的自定义 URI 方案。

3.2.3 Resource types 资源类型

资源可以包含两种类型的内容：

文本资源

文本资源包含UTF-8 编码的文本数据。
这些适用于：源代码、配置文件、日志文件、JSON/XML 数据、纯文本

二进制资源

二进制资源包含以 Base64 编码的原始二进制数据。这些适用于
图像、PDF 文件、音频文件、视频文件、其他非文本格式

3.2.4 Resource discovery 资源发现

客户端可以通过两种主要方法发现可用资源：

直接资源

服务器通过 resources/list 端点公开具体资源列表。每个资源包括：

{
  uri: string;           // Unique identifier for the resource
  name: string;          // Human-readable name
  description?: string;  // Optional description
  mimeType?: string;     // Optional MIME type
}

资源模板

对于动态资源，服务器可以公开 URI 模板，客户端可以使用这些模板来构建有效的资源 URI。

{
  uriTemplate: string;   // URI template following RFC 6570
  name: string;          // Human-readable name for this type
  description?: string;  // Optional description
  mimeType?: string;     // Optional MIME type for all matching resources
}

3.2.5 Reading resources 阅读资源

要读取资源，客户端使用资源统一资源标识符（URI）发出 resources/read 请求。服务器会以资源内容列表作为响应：
服务器可能会针对一个资源 / 读取请求返回多个资源。例如，当读取一个目录时，这可用于返回该目录内的文件列表。

{
  contents: [
    {
      uri: string;        // The URI of the resource
      mimeType?: string;  // Optional MIME type

      // One of:
      text?: string;      // For text resources
      blob?: string;      // For binary resources (base64 encoded)
    }
  ]
}