LV005-MCP简介
一、MCP 概述
1. MCP 是什么？
模型上下文协议（MCP, Model Context Protocol） 是一种为 AI 模型设计的通用上下文通信协议。它让模型与外部工具、数据资源和运行环境之间建立一个统一、安全、可扩展的接口。
可以把 MCP 理解为“AI 世界的 USB-C” —— 用一条标准化通道，让模型与一切外部系统互联。
2. 为什么要有MCP？
2.1 N×M 问题：模型与工具的碎片化集成
在早期的 AI 系统中，每个模型与外部系统都需要编写独立的适配层，形成所谓的 N×M 问题。当模型数量（N）和工具数量（M）增加时，开发复杂度呈指数级上升。下表总结了碎片化集成带来的典型症状：
| 症状 | 描述 |
|---|---|
| 重复开发 | 每新增一个工具或模型都需重新集成 |
| 难以复用 | 不同厂商的接口规范互不兼容 |
| 上下文割裂 | 模型无法直接访问实时数据或系统状态 |
结果：AI 助手被困于“信息孤岛”，用户需频繁手动粘贴数据以弥补接口缺口。
下方流程图展示了传统集成模型的结构：
2.2 从 N×M 到 M+N
为解决上述复杂性，Model Context Protocol（MCP, Model Context Protocol）引入统一的“翻译层”，作为模型与工具之间的协议桥梁。每个模型和工具只需实现一次 MCP 接口，即可互操作。
下方流程图展示了统一接口模型的结构：
这种结构使系统复杂度从 N×M 降至 N+M，大幅降低开发与维护成本。协议借鉴了 语言服务器协议（LSP, Language Server Protocol） 的成功经验，强调以下特性：
- 可发现性：客户端可动态查询可用工具；
- 能力声明：每端声明自身支持的功能；
- 生命周期管理：连接与资源动态加载与释放；
- 通知机制：服务端主动推送变化事件。
2.3 Function Calling 的局限
OpenAI、Anthropic 等厂商早期的 函数调用（Function Calling） 能力，使模型可调用 API，但各厂商实现不一致，开发者需维护多套 JSON Schema 与调用逻辑。
下表总结了 Function Calling 模式的主要局限：
| 局限 | 说明 |
|---|---|
| 无标准化 | 不同模型的函数定义与参数格式不兼容 |
| 扩展性差 | 每新增函数需重新注册与解析 |
| 维护成本高 | 工具与模型紧耦合，难以复用 |
随着模型和工具数量的增加，传统 Function Calling 模式在生态扩展性上逐渐失效。
2.4 MCP 的提出：通用上下文协议
为根治上述问题，Anthropic 于 2024 年 11 月发布 Model Context Protocol（MCP, Model Context Protocol），并在 2025 年 6 月推出更新规范。MCP 建立了统一的三层结构：
| 层级 | 角色 | 主要职责 |
|---|---|---|
| Host | 模型运行宿主，如 IDE、桌面客户端 | 主机进程是 MCP 协议的核心协调者。它负责管理客户端实例的生命周期，控制连接权限，并执行安全策略。主机还负责协调 AI/LLM 集成，确保整个系统的平稳运行。 |
| Client | 协议适配层 | 客户端由主机创建，用于维护与服务器的独立连接。每个客户端都与一个服务器保持 1:1 的关系，确保连接的隔离性和安全性。 |
| Server | 外部工具或数据源 | 服务器负责公开资源和工具，可以独立运行并通过客户端请求采样。服务器可以是本地的也可以是远程的，为系统提供各种功能。 |
MCP Hosts: 如 Claude Desktop、IDE 或 AI 工具，希望通过 MCP 访问数据的程序
MCP Clients: 维护与服务器一对一连接的协议客户端
MCP Servers: 轻量级程序，通过标准的 Model Context Protocol 提供特定能力
本地数据源: MCP 服务器可安全访问的计算机文件、数据库和服务
远程服务: MCP 服务器可连接的互联网上的外部系统（如通过 APIs）
MCP 使用 JSON-RPC 2.0 作为消息格式，核心字段如下：
| 字段 | 含义 |
|---|---|
method | 方法名称（如 tools/list、resources/get） |
params | 参数对象 |
id | 请求标识符 |
result / error | 响应结果或错误描述 |
3. MCP 的发展历程
| 时间 | 事件 | 影响 |
|---|---|---|
| 2024-11 | Anthropic 发布 MCP 规范与参考实现 | 统一模型与外部系统集成标准 |
| 2024-12 | Block、Apollo、Zed、Replit 等早期接入 | 开发者生态启动 |
| 2025-02 | 开源社区贡献超 1000 个服务器与连接器 | 生态快速增长 |
| 2025-03 | GPT-5 / ChatGPT 全面兼容 MCP | 成为主流标准 |
| 2025-05 | Google A2A 协议兼容 MCP | 实现跨厂商互操作 |
| 2025-07 | IDE 工具普及 MCP 客户端 | 用户可配置多源工具调用 |
4. 小结
MCP 的出现，使模型具备了“即插即用”的外部访问能力。它统一了工具调用、资源访问与上下文交互的协议层，为 AI 系统提供了类似 USB-C 的标准接口。
二、架构与角色
前面其实已经提到过了，主要实现下面三个角色，这里再简单总结一下：
| 角色 | 描述 | 主要职责 |
|---|---|---|
| Host（主机） | 模型运行的宿主环境，如 IDE、桌面应用或 CLI | 启动模型进程并建立客户端连接 |
| Client（客户端） | 代理层，位于模型与外部系统之间 | 转发消息、维护上下文、缓存资源元数据 |
| Server（服务器） | 提供具体功能或数据接口 | 实现 MCP 规范，暴露工具、资源与提示模板 |
下方流程图展示了 MCP 的典型交互结构：
运行机制说明
模型通过 Client 向 Server 发现可用能力，Server 响应可调用的工具（Tools）、资源（Resources）和提示模板（Prompts）。Client 负责中继、缓存与权限控制，所有通信通过 JSON-RPC 请求/响应完成，确保安全与一致性。
三、协议原语（Primitives）
MCP 的核心由三类原语（Primitive）构成，分别定义了模型可访问的能力类型。下表总结了三类原语及其典型用途：
| 原语 | 说明 | 示例 |
|---|---|---|
| Tools（工具） | 模型可调用的具体函数或操作 | 创建事件、查询数据库、发送邮件 |
| Resources（资源） | 模型可访问的数据对象 | 文件、文档、数据库表、API 响应 |
| Prompts（提示模板） | 定义任务上下文的文本模板 | 不同任务场景下的系统提示 |
这些原语共同描述了 MCP Server 能向模型提供的能力清单。模型可通过 tools/list、resources/list 等方法动态发现，再按需调用，实现灵活扩展。