MCP 简介

MCP 的起源

模型上下文协议（Model Context Protocol，简称 MCP）旨在解决人工智能模型，特别是大型语言模型（LLM），在访问和交互来自各种来源的上下文信息时日益增长的标准化需求。随着 AI 应用变得越来越复杂，它们需要更深入地理解用户的环境、数据和可用工具。MCP 旨在为此类交互提供一个结构化、安全的协议，从而超越为每个应用和数据源进行定制集成的方式。

核心概念

MCP 围绕几个核心概念构建，这些概念定义了其架构和运作方式：

宿主（Hosts）：这些是用户与 AI 或 LLM 交互的应用程序或环境。例子包括集成开发环境（IDE，如 VSCode、Cursor）、桌面应用程序（如 Claude Desktop）或网络应用程序。宿主负责协调用户、LLM 和 MCP 服务器之间的通信。
客户端（Clients）：MCP 客户端是嵌入在宿主中或代表宿主操作的库或代理。它们实现了 MCP 协议的客户端部分，使宿主能够发现并与 MCP 服务器交互，请求上下文，并向 LLM 提供信息或工具。
服务器（Servers）：MCP 服务器向 MCP 客户端公开上下文信息（Resources，资源）、预定义操作（Prompts，提示）和可执行函数（Tools，工具）。它们充当底层数据源或服务的网关，以结构化的方式使 LLM 能够访问这些资源。
LLM（大型语言模型）：尽管 LLM 并非 MCP 的严格组成部分，但它们是通过 MCP 提供的上下文的主要消费者。该协议旨在使 LLM 更容易接收相关信息并有效地利用外部工具。

目标

MCP 的主要目标是：

标准化上下文交换：为 AI 模型请求和接收上下文信息提供通用语言和协议。
增强 LLM 能力：使 LLM 能够访问更广泛的信息和工具，使其更强大、更通用。
提升开发者体验：简化 LLM 与各种数据源和应用程序功能集成的过程。
促进安全与信任：提供安全通信、数据隐私和用户控制信息和工具暴露的机制。
培育生态系统：鼓励在不同平台和服务之间开发可互操作的 MCP 服务器和客户端。

特性

MCP 提供了几个关键特性：

有状态连接：与典型的无状态 HTTP API 不同，MCP 通常依赖有状态连接（例如，通过 WebSockets），以实现持续的双向通信和上下文感知。
服务发现：客户端可以发现可用的服务器及其提供的能力（资源、提示、工具）。
结构化数据交换：使用定义良好的 Schema（模式），通常基于 JSON-RPC，用于请求和响应。
能力协商：允许客户端和服务器就支持的功能和数据格式达成一致。
可扩展性：旨在适应各种类型的数据源和工具。

MCP 与 Restful API 对比

虽然 Restful API 在 Web 服务中普遍存在，但 MCP 是为 AI 上下文交换的特定需求量身定制的，两者在以下几个方面有所不同：

方面	MCP	Restful API
主要用例	AI/LLM 的动态上下文信息交换	通用 Web 服务通信
状态管理	通常是有状态的、持久连接（例如，WebSockets）	通常是无状态的、请求-响应
通信方式	双向，可能涉及流式传输或推送更新	主要由客户端发起的请求-响应
发现机制	内置的发现能力机制（资源、提示、工具）	依赖 API 文档（例如，OpenAPI）和固定端点
交互模型	面向持续交互和上下文构建	离散事务

整体架构

MCP 生态系统包含几个相互作用的组件：

宿主：用户或 LLM 操作的应用程序（例如，IDE、聊天界面）。
客户端（MCP Client SDKs）：驻留在宿主内部或与其并行，管理与 MCP 服务器的通信。
服务器（MCP Servers）：从底层源公开数据和能力。
本地数据源：MCP 服务器在用户本地机器或私有网络上可访问的文件、数据库或应用程序状态（例如，项目文件、本地数据库）。
远程服务：MCP 服务器可以中介访问的外部 API 和服务（例如，云存储、SaaS 平台、公共 API）。

一个简化的交互流程可能如下所示：

用户与宿主应用程序（例如，IDE）交互
  |
  v
宿主应用程序（包含 MCP 客户端）
  | （基于 JSON-RPC 的 MCP 协议）
  v
MCP Server
  / | \
 /  |  \
 v  v   v
LLM  本地数据源  远程服务
（消费上下文，（例如，项目文件） （例如，GitHub API）
 可能请求工具执行）