MCP（Model Context Protocol，模型上下文协议） 是一种用于标准化连接 AI Agent、LLM 与外部工具、数据源和服务的开放协议。它最初由 Anthropic 的 David Soria Parra 和 Justin Spahr-Summers 等人提出，并于 2024 年 11 月 25 日正式开源。其核心目标是解决 AI 应用与外部系统之间集成方式碎片化的问题，使模型能够通过统一协议访问工具和上下文。
MCP 可以类比为 AI 应用的 USB-C 接口：USB-C 让不同设备能够通过统一接口连接外设，而 MCP 则试图让不同的 AI 应用通过统一协议连接不同的工具和数据源。
截至 2026 年 7 月，MCP 已发展为面向 AI Agent 工作流的重要基础协议，最新规范为 2026-07-28。该版本进一步引入了无状态协议核心（stateless protocol core）、多轮请求、基于 HTTP Header 的路由、可缓存的列表结果以及更完善的授权和扩展机制。
传统的 AI 应用如果需要调用外部系统，通常需要针对每一个模型、工具和数据源单独编写集成代码。
例如，一个 AI 应用需要访问：
* GitHub * Google Drive * PostgreSQL * Slack * 文件系统 * 搜索引擎 * 浏览器
如果没有统一协议，开发者需要为不同的 AI 应用分别实现这些接口。
可以抽象成：
模型 A → GitHub API 模型 A → 数据库 API 模型 A → 文件系统 API
模型 B → GitHub API 模型 B → 数据库 API 模型 B → 文件系统 API
随着模型和工具数量增加，集成数量迅速增长。
MCP 希望将这种结构变成：
AI 应用 → MCP → GitHub AI 应用 → MCP → 数据库 AI 应用 → MCP → 文件系统 AI 应用 → MCP → 浏览器
因此，工具只需要实现一次 MCP Server，支持 MCP 的 AI 应用就可以使用它。
MCP 最初由 Anthropic 提出。
* 2024 年 11 月 25 日：Anthropic 正式发布并开源 MCP。 * 2025 年：MCP 快速扩展到 Claude、代码编辑器、AI Agent 平台以及各种企业软件。 * 2025 年 7 月：MCP 建立正式治理机制，通过 Specification Enhancement Proposal（SEP）等方式推进协议演化。 * 2025 年 11 月：发布 MCP 2025-11-25 规范，引入任务（Tasks）、更完善的授权、安全机制以及服务器端采样等能力。 * 2026 年 7 月 28 日：发布 MCP 2026-07-28 规范，将协议核心进一步转向无状态请求/响应架构，并加入多轮请求、Header 路由、缓存列表结果、扩展框架等能力。
MCP 后来被捐赠给 Linux Foundation 下的 Agentic AI Foundation（AAIF），使其进一步向中立、开放的行业基础设施发展。
MCP 主要由 Host、Client 和 Server 三类角色组成。
Host
Host 是运行 AI 应用的宿主程序，例如 AI 编程助手、桌面 AI 应用或者其他 AI Agent 平台。
Host 通常负责：
* 管理模型 * 管理 MCP Client * 控制用户权限 * 将 MCP 提供的信息和工具交给模型使用
Client
MCP Client 是 Host 中负责与某个 MCP Server 建立连接的组件。
通常一个 MCP Server 对应一个 MCP Client 连接。
例如：
AI Agent → MCP Client → GitHub MCP Server
Server
MCP Server 是外部能力的提供者。
它可以将某个数据源、API、程序或者服务封装成 MCP 接口。
例如：
GitHub MCP Server 数据库 MCP Server 文件系统 MCP Server 浏览器 MCP Server
因此，MCP Server 并不一定是一个远程服务器，也可以运行在用户本地。
MCP 最重要的能力可以概括为：
Tools、Resources、Prompts。
Tool（工具） 是 MCP Server 提供给 AI 应用调用的可执行能力。
例如：
* 查询数据库 * 搜索 GitHub * 创建文件 * 修改代码 * 发送消息 * 执行程序 * 调用第三方 API
模型可以根据 Tool 的描述决定是否调用它。
例如，一个 MCP Server 可以提供：
search_code(query)
模型首先理解用户任务，然后决定：
理解任务 → 发现可用 Tool → 选择 Tool → 生成参数 → 调用 Tool → 获取结果 → 继续推理
MCP 本身并不负责决定模型什么时候调用工具；模型或 AI Agent 的上层逻辑负责进行工具选择，而 MCP 负责标准化工具的描述、发现和调用过程。
Resource（资源） 用于向 AI 应用提供上下文数据。
例如：
* 文件 * 数据库记录 * 文档 * 配置 * 项目状态 * API 返回的数据
Resources 更接近“可以被读取的上下文”，而 Tools 更接近“可以执行的操作”。
可以简单理解为：
Tool → 做什么
Resource → 有什么信息
Prompt 是 MCP Server 可以提供的提示模板或交互模板。
它允许服务器向客户端提供结构化的提示内容，从而帮助用户或 AI 应用按照特定方式使用某项能力。
因此，MCP 不只是简单的“工具调用协议”，而是同时定义了工具、资源和提示等能力。
MCP 与 Function Calling 有密切关系，但二者并不是同一个概念。
Function Calling 通常描述：
LLM → 函数名称 + 参数
而 MCP 进一步标准化了：
AI 应用 → MCP Server → Tool Discovery → Tool Call → Tool Result
因此可以认为：
Function Calling 解决“模型如何调用一个函数”，而 MCP 更关注“AI 应用如何以统一协议发现、连接和使用大量外部能力”。
MCP Server 可以向客户端声明自己提供哪些 Tool，以及这些 Tool 所需要的参数结构。
用户：
“帮我分析 GitHub 项目中的 Bug。”
可能发生：
用户请求 → LLM 理解任务 → MCP Client 获取可用 Tools → 模型选择 GitHub Tool → MCP Client 调用 MCP Server → MCP Server 查询 GitHub → 返回结果 → LLM 分析结果 → 输出答案
因此 MCP 本身并不是模型。
它位于：
MCP 的重要意义之一，是它为 AI Agent 提供了统一的“工具层”。
一个 Agent 通常需要：
* 感知环境 * 获取信息 * 调用工具 * 执行动作 * 获取执行结果 * 根据结果继续规划
如果每一个工具都使用不同的 API，那么 Agent 系统会非常复杂。
MCP 将工具接口标准化以后，可以形成：
用户 ↓ AI Agent ↓ LLM ↓ MCP ↓ 工具 / 数据库 / 文件 / API / Web 服务 ↓ 执行结果 ↓ Agent 继续推理
因此 MCP 可以看作现代 Agent 系统中的一种 工具与上下文互操作层。
MCP 与 RAG 也容易混淆。
RAG 主要解决：
如何从外部知识中检索相关信息并提供给模型。
MCP 主要解决：
AI 应用如何以统一协议连接外部数据和工具。
因此 MCP Server 可以提供搜索、数据库查询等能力，从而实现 RAG，但 MCP 本身并不是 RAG 算法。
例如：
用户问题 ↓ MCP Tool：搜索知识库 ↓ 返回相关文档 ↓ LLM 生成答案
这里 MCP 负责连接，RAG 负责检索增强。
MCP 不是 API 的替代品。
传统 API：
AI 应用 → API → 服务
MCP：
AI 应用 → MCP Client → MCP Server → API / 数据库 / 本地程序
因此 MCP 可以作为 API 之上的标准化适配层。
例如，一个 MCP Server 可以把 GitHub API 封装起来，让不同的 AI Agent 使用统一 MCP 接口访问 GitHub。
MCP 的早期实现主要支持本地进程之间的通信以及基于 HTTP 的远程通信。
随着协议发展，其通信模型也不断演化。
2026-07-28 规范的重要变化之一，是将 MCP 核心推进为 stateless protocol core（无状态协议核心），更加适合部署在普通 HTTP 基础设施上。
这使 MCP 更适合：
* 云端部署 * Serverless * 负载均衡 * 多实例部署 * 大规模 Agent 系统
MCP Server 本质上可以看成一个“能力适配器”。
例如：
GitHub API ↓ GitHub MCP Server ↓ 标准化 MCP Tools ↓ AI Agent
数据库：
PostgreSQL ↓ Database MCP Server ↓ 标准化 MCP Tools ↓ AI Agent
因此 MCP 的价值并不主要来自某一个具体工具，而来自 统一接口带来的互操作性。
统一接口
不同 AI 应用可以使用相同的协议连接外部能力。
降低集成成本
工具开发者不需要针对每个 AI 应用分别开发接口。
工具生态
一个 MCP Server 可以被多个 MCP Client 使用。
适合 Agent
Agent 可以动态发现和调用外部工具。
可扩展
MCP 可以通过协议扩展不断加入新的能力。
开放标准
MCP 并不要求使用某一家模型，可以由不同的 AI 应用实现。
MCP 并不会自动解决 Agent 的所有问题。
工具选择问题
当一个 Agent 面对数百甚至数千个 Tool 时，如何选择正确工具仍然是 LLM 的问题。
上下文开销
工具描述和工具返回结果都可能占用模型的 Context Window。
安全问题
MCP Server 可能拥有文件读写、数据库访问、代码执行等高权限能力，因此必须考虑：
* 权限控制 * 身份认证 * 授权 * 输入验证 * 沙箱 * Tool Injection * Prompt Injection
可靠性
外部工具可能失败、超时或返回错误数据，因此 Agent 必须具备错误处理和重试能力。
随着 LLM 从单纯的文本生成模型逐渐发展为能够使用工具、执行任务的 AI Agent，模型本身已经不再是完整系统。
一个现代 Agent 系统通常可以分成：
模型层 → LLM 推理层 → Reasoning 工具层 → MCP 数据层 → RAG / 数据库 执行层 → Computer Use / 代码执行 控制层 → Agent Loop
在这个结构中，MCP 更接近 连接模型与外部世界的基础设施层。
MCP 最重要的意义并不是增加了某一个新的 AI 能力，而是尝试建立一个 AI 与外部世界之间的通用接口标准。
过去：
每个 Agent 都需要自己实现各种工具连接。
MCP：
工具提供者实现 MCP Server → 不同 Agent 可以复用。
因此 MCP 的长期价值类似于其他基础设施协议：
标准化接口 → 降低集成成本 → 形成生态 → 提高互操作性。
随着 AI Agent 成为越来越重要的 AI 软件形态，MCP 逐渐从 Anthropic 的一个开源项目发展成为 Agent 工具与数据连接的重要开放标准。
* AI Agent * LLM * Function Calling * Tool Use * RAG * Context Window * Computer Use * OpenAI
* Anthropic, 2024, Introducing the Model Context Protocol * Model Context Protocol, 2026-07-28 Specification * Model Context Protocol Blog, The 2026-07-28 Specification * Anthropic, Model Context Protocol Documentation * Model Context Protocol Blog, Building to Last: A New Governance Model for MCP