深入解析 MCP：协议本质、架构与核心能力全解

MCP 是 Anthropic 在 2024 年底推出的开放协议，其核心解决的是「模型接入工具高度碎片化」的问题。在 MCP 出现之前，每接入一个新工具都需要单独编写集成代码、处理认证流程、适配数据格式，且这套代码与具体模型强绑定，更换模型就需要重新开发，流程极为繁琐。

MCP 的核心思路是将该过程标准化：工具提供方按照协议实现一个 Server，任意支持 MCP 的 AI 客户端均可直接接入，实现一次开发、多处复用。协议定义了三类核心能力：Tools 用于执行具备副作用的操作，Resources 为只读数据，Prompts 是提示词模板；底层通信基于 JSON-RPC 2.0 实现。我们可以将 MCP 理解为「AI 接入工具」场景的行业标准协议。

没有 MCP 之前，接工具有多麻烦

想象为 Claude 接入 GitHub 工具的场景：需要手动编写 GitHub API 调用代码、处理认证逻辑（如 OAuth token 的传输方式）、适配各类返回格式、将 API 响应转换为模型可识别的格式。完成对接后，若 Claude 版本升级导致接口变更，对接代码需要同步修改。

更复杂的是，若同时接入十个工具，每个工具都拥有独立的对接代码，格式规范、认证方式、错误处理逻辑均不统一。当产品需要将这套工具适配给 Cursor 使用时，由于 Cursor 与 Claude Desktop 的接入方式完全不同，必须重新编写对接代码。

MCP 的核心思路：制定一套行业标准接口

MCP（Model Context Protocol，模型上下文协议）的设计思路可通过 USB 接口类比理解。在 USB 标准推出前，鼠标、键盘、打印机等外设均使用独立接口，更换设备易出现接口不兼容问题；USB 标准普及后，所有外设统一接口，任意设备可适配任意支持 USB 的电脑，设备厂商仅需完成一次适配，即可兼容全球所有 USB 设备。

MCP 实现了同等价值：为「AI 接入工具」制定统一的协议标准。工具提供方按照 MCP 规范实现 MCP Server，封装所有操作能力；任意支持 MCP 的 AI 客户端均可直接连接该 Server，自动发现并使用内置工具，真正做到工具一次实现、全域复用。

角色架构：Host / Client / Server

MCP 定义了三大核心角色，明确各角色职责是理解整个系统的关键。

MCP 的 Client-Server 架构

Server 是工具的具体实现方。例如 GitHub 官方维护的 GitHub MCP Server，封装了「列出 PR」「创建 Issue」「搜索仓库」「查看 Diff」等核心操作；Client 属于 AI 应用端，连接 Server 后即可自动获取对应的工具能力。

一个 Client 可同时连接多个 Server。例如同时接入文件系统 Server、GitHub Server、PostgreSQL Server，模型即可具备本地文件操作、代码仓库读写、数据库查询的三重能力。整个过程无需编写任何对接代码，仅需在配置文件中添加几行 JSON 配置，重启后 Claude 会自动发现并使用这些工具。

三类核心能力：Tools、Resources、Prompts

Tools（工具）

Tools 是 MCP 最核心的能力，对应 Function Calling 中的「函数」。其本质是具备副作用的操作：执行后会改变外部世界的状态，且操作通常不可逆。创建文件、提交代码、发送 Slack 消息、调用第三方 API 均属于 Tools 范畴。正因如此，Tools 一般需要用户授权确认后才可执行，不支持模型自主调用。

Resources（资源）

Resources 与 Tools 的核心区别为只读：不会修改任何外部状态，仅为模型提供数据读取能力。读取日志文件、查询数据库记录、获取文档内容均属于 Resources 范畴。我们可以将 Resources 理解为工具的「资料室」，模型可查询数据但无法修改内容。由于只读无副作用，Resources 可更宽松地向模型开放。

Prompts（提示模板）

Prompts 是容易被忽略但在团队协作中极具价值的能力。它是带参数占位符的预定义提示词模板，解决「重复手写提示词」的痛点。例如团队拥有固定的代码审查标准 Prompt，支持「编程语言」「代码内容」两个参数，调用时传入参数值即可自动生成完整提示词。将企业积累的优质 Prompt 封装为 MCP Prompts，可实现全员复用、标准统一。

传输协议：JSON-RPC 2.0 + 传输方式

Client 与 Server 之间的通信分为消息格式和传输方式两层，两层相互解耦。

消息格式统一采用 JSON-RPC 2.0，每条消息为标准 JSON 对象。Client 发送请求时需明确「调用方法、请求参数、请求 ID」；Server 返回响应时携带执行结果或错误信息，通过请求 ID 匹配请求与响应。JSON 格式具备易读、易调试、全编程语言兼容的优势。

// Client 向 Server 查询工具列表
{"jsonrpc": "2.0", "id": 1, "method": "tools/list", "params": {}}
// Server 返回工具列表
{"jsonrpc": "2.0", "id": 1, "result": {"tools": [{"name": "read_file", ...}]}}
// Client 请求调用某个工具
{"jsonrpc": "2.0", "id": 2, "method": "tools/call", "params": {"name": "read_file", "arguments": {"path": "/tmp/log.txt"}}}

消息格式确定后，MCP 支持两种传输方式，适配不同部署场景：