协议概述与架构
MCP 协议重塑了 AI 与工具集成的范式，让模型能力像乐高一样自由拼装，推动智能应用生态迈向标准化与可组合未来。
本节简要介绍 MCP 协议的整体架构，包括主机、客户端、服务器的角色划分，消息传输方式，以及协议生命周期和核心元素，帮助读者快速理解 MCP 的基本框架和工作原理。
架构示意
下面是一张示意图：描述了用户、AI 代理（MCP 主机及其内置 LLM）与 MCP 服务器之间的通信关系，展示模型决定调用工具并通过 MCP 客户端转发请求到服务器，服务器执行并返回结果的流程。
上图强调了 MCP 的可组合性：同一主机可以同时连接多个服务器（S1、S2），LLM 在得到可用工具信息后，按需调用不同服务器提供的能力。
交互流程（详细步骤）
下图展示了 MCP 的基本架构和交互流程。
从图中可以看出，MCP 的基本架构包括三个角色：主机、客户端和服务器。主机负责运行 LLM，并提供可用的 MCP 工具列表。客户端负责与服务器通信，并将模型的指令转发给服务器。服务器执行实际操作，并将结果返回给客户端，最终由主机生成回答并呈现给用户。
下列交互流程展示了一个完整的使用场景，便于理解 MCP 在实际操作中的工作方式：
- 用户提出请求： 开发者在 IDE 或聊天界面输入问题或指令（例如“请检查本地静态网站主页的样式是否符合设计规范”）。
- AI 代理准备上下文： MCP 主机（如 VS Code + Copilot）将用户请求转交给内部的 LLM，并提供可用的 MCP 工具列表（已连接的服务器功能）作为上下文的一部分。这让模型知道有哪些外部能力可以调用。
- 模型决策并调用工具： LLM 接收用户请求和工具列表后，经过思考决定需要使用哪种工具获取信息。例如，它判断需要打开浏览器检查页面样式，于是发送一个 JSON‑RPC 请求调用 Playwright MCP 服务器的
browser_navigate工具来打开页面。 - MCP 客户端请求服务器： VS Code 中对应的 MCP 客户端收到模型的指令，调用 Playwright MCP 服务器执行
browser_navigate操作，并传递所需参数（如 URL 或本地文件路径）。 - 服务器执行操作： Playwright MCP 服务器用无头浏览器打开页面，加载静态网站内容。如果需要后续操作（如获取页面结构），模型可能继续调用
browser_snapshot或其他工具。每次调用都经由 JSON‑RPC 请求由服务器执行实际动作，服务器完成后将结果通过 JSON‑RPC 响应返回。 - 结果返回模型： MCP 客户端收到服务器响应的数据，例如页面的结构化快照或元素样式信息，并将此数据提供给 LLM。模型将该数据整合进自己的上下文中。
- 模型生成回答： LLM 基于用户最初的问题和通过 MCP 获取的最新上下文（页面内容、样式等），生成解答或者后续的测试代码。这个最终结果再由 MCP 主机呈现给用户。
在多步任务中，LLM 可以多次调用不同的 MCP 工具，并在每一步获取新的信息后调整策略，直至完成任务。MCP 协议确保了每一步调用都有明确的接口和返回值，有助于可观测性和调试。
基本定义
Model Context Protocol 是一种开放协议，使 LLM 应用能够标准化地共享上下文、暴露工具并构建可组合的集成。协议通过 JSON‑RPC 消息在主机（Host）、客户端（Client）和服务器（Server）之间传递数据。其中：
- 主机（Host）：运行 LLM 的应用，例如 Claude Desktop 或集成 MCP 的 IDE。
- 客户端（Client）：嵌入在主机中的连接器，负责与 MCP 服务器通信和翻译消息。
- 服务器（Server）：暴露特定工具、资源或提示以供模型调用。每个服务器通常专注于一个系统，如 Git、数据库或 Slack。
- 传输层：目前支持两种标准传输方式：
stdio（标准输入/输出）和HTTP流（SSE）。客户端启动服务器子进程，使用 stdin/stdout 进行通信，或通过 HTTP POST/GET 与远程服务器交互。
生命周期与握手流程
协议规定了连接的完整生命周期，包括初始化、操作和关闭阶段。初始化阶段由客户端发送 initialize 请求，包含协议版本、客户端能力和客户端信息，服务器返回自身能力及版本等信息。随后客户端发送 initialized 通知表示进入正常工作阶段。客户端和服务器在初始化时协商各自支持的能力（如是否支持工具列表变化通知、是否支持订阅资源更新等）。
操作阶段中，客户端可以请求工具列表（tools/list）或调用工具（tools/call）等。服务器也可发送通知，例如当工具列表变化时发送 notifications/tools/list_changed。关闭阶段则由客户端或服务器结束连接，没有专门的关闭消息，通过关闭传输通道实现。
传输层细节
stdio 传输：客户端以子进程启动服务器，通过标准输入输出传递 JSON‑RPC 消息。消息用换行符分隔，服务器不得在 stdout 输出非 MCP 消息。
Streamable HTTP：服务器作为独立进程提供 HTTP 端点，客户端通过 POST 发送 JSON‑RPC 消息，服务器返回 text/event-stream 进行 SSE 流式传输。客户端还可以通过 GET 打开 SSE 流获取服务器通知。由于 HTTP 传输存在安全风险，规范建议服务器验证 Origin 头、绑定到 localhost 以及实现适当的认证机制。
核心元素：工具、资源与提示
MCP 服务器通过 工具（tools）、资源（resources） 和 提示（prompts） 向模型提供功能和数据。
工具 用于执行操作，例如查询数据库、调用外部 API 或执行计算。服务器声明支持工具能力并暴露每个工具的名称、描述、输入参数模式和输出结构。模型通过 tools/list 获取可用工具，然后用 tools/call 调用。
资源 提供只读数据，如文件内容或数据库结果集，模型可以订阅或查询资源。
提示 是预定义的消息模板或工作流脚本，用于指导模型生成一致的输出。
为什么需要 MCP
在引入 MCP 之前，AI 应用与外部工具/数据源之间的对接通常是“点对点”的：每个模型或应用需要为每个外部系统实现单独的集成。若有 M 个 AI 应用和 N 个工具，就可能产生 M × N 个适配器，这既费时又难以维护（也就是常说的 M×N 集成问题）。
MCP 的价值在于把中间层标准化：每个模型实现一次 MCP 客户端，每个工具实现一次 MCP 服务器，双方通过统一协议互通。这样新增一个模型或工具时，只需实现一次 MCP 接口，整体工作量从 M×N 降到 M + N，从而大幅降低集成复杂度并促进生态互操作性。
主要优势
- 降低集成复杂度：标准化协议解决“模型 × 系统”集成问题，减少重复开发工作量。
- 跨平台与模型可替换性：MCP 支持多种传输（stdio、HTTP+SSE）和多种语言/模型实现，使 Host 与 Server 更容易互换。
- 促进生态繁荣：开放的协议便于社区和第三方发布各类 MCP 服务器（工具、资源、提示模板），形成可组合的能力市场。
- 安全与可控：通过细粒度权限描述、用户授权与本地部署等机制，Host 可以限制模型访问的工具与数据，降低越权风险。
客户端特性
MCP 客户端不仅转发消息，还可提供附加功能：
- Roots：允许服务器查询主机的文件系统根目录和权限范围，用于浏览和读写文件。
- Sampling：支持服务器主动请求模型采样，进行递归的 LLM 调用，此功能用于多模态协作或需要模型继续生成内容的场景。
- Elicitation：服务器可以向用户请求额外信息，以便模型完善回答或操作。
这些特性需要在初始化阶段协商开通。
安全与隐私
MCP 提供强大的能力，但也带来安全风险。规范强调用户必须拥有明确的授权控制权：
- 用户同意与控制：主机必须提供直观的界面，让用户明确知道正在授权哪些工具或数据。
- 数据隐私：主机在向服务器发送用户数据前必须征求用户同意，不得擅自传输敏感信息。
- 工具安全：工具代表着任意代码执行，必须确保来源可信，并在调用前征求用户确认。
- LLM 采样控制：如服务器请求模型采样，用户需明确批准所发送的提示内容及回显结果。
- 传输安全：实现者应遵循 OAuth 2.1 等认证规范，防止重定向攻击、令牌泄露等。