MCP协议深度解析：AI Agent的标准化连接方案

如果你正在开发AI Agent，一定遇到过这样的困境：每接入一个新工具，就要写一套新的集成代码、新的认证逻辑。工具越多，集成数量呈平方级增长。Model Context Protocol（MCP）正是为解决这一问题而生的开放协议。

本文基于技术频道LearnTech的深度讲解，从架构设计、协议消息、传输机制到生产实践，系统拆解MCP的完整技术图景。

为什么需要MCP：从M×N到M+N

假设你有M个AI应用和N个工具，传统方式下每对组合都需要单独集成，总共需要M×N套集成方案。MCP将这一复杂度降为M+N：每个应用只需实现一次MCP Client，每个工具只需实现一次MCP Server。

这个设计思路并非凭空而来。Language Server Protocol（LSP）曾用同样的方式解决了代码编辑器与编程语言之间的适配问题——在LSP之前，每个编辑器都要为每种语言单独编写支持。MCP正是从LSP的成功中汲取了灵感。

三层架构：Host、Client与Server

MCP的架构由三个角色构成。Host是用户直接运行的应用程序，比如Claude Desktop、Cursor这类代码编辑器，或者你自己构建的Agent应用。Client位于Host内部，每个Client与一个Server保持一对一连接。Server则是轻量级程序，负责暴露特定系统的能力——GitHub、PostgreSQL数据库、Slack，或公司内部API。

Host中运行的模型决定将哪些Server的权限授予Agent。如果Host连接了三个Server，内部就运行着三个独立的Client。这种一对一设计带来的关键优势是隔离性：一个Server无法窥探另一个Server的交互内容。

协议层：JSON-RPC 2.0与能力协商

MCP的所有消息都采用JSON-RPC 2.0格式，包含三种消息类型：Request（有响应的请求）、Response（请求的响应）和Notification（无需响应的通知）。

每个连接都经历一个生命周期。Client首先发送initialize请求，声明自己的协议版本和能力；Server在响应中说明自己支持的能力——是否提供Tools、Resources或Prompts；随后Client发送initialized通知，连接正式建立。这个过程被称为能力协商（Capability Negotiation），双方只使用彼此都同意支持的功能。

JSON-RPC 2.0是一种轻量级的远程过程调用协议，使用JSON作为数据交换格式。它的消息结构非常简单：请求包含jsonrpc: "2.0"、method（方法名）、params（参数）和id（请求标识）；成功响应包含result，错误响应包含error对象（含错误码、消息和数据）；通知则省略id字段，表示不需要响应。相比REST，JSON-RPC的语义更接近函数调用，天然适合需要双向交互和状态管理的场景。MCP选择JSON-RPC 2.0，是因为它能以统一格式表达请求、响应和通知三种消息，并且与传输层解耦——同一套消息格式既可跑在STDIO上，也可跑在HTTP上，便于实现和调试。

传输机制：STDIO与Streamable HTTP

消息如何在两端之间传递？MCP定义了两套标准传输方式。

STDIO适用于Server运行在本地机器上的场景，Host将其作为子进程启动，通过标准输入输出通信。Streamable HTTP则面向远程Server，Client通过HTTP POST发送消息，Server可按需通过流式响应返回结果和更新。后者取代了早期的HTTP+SSE方案。

早期的MCP远程传输方案是HTTP+SSE：Client通过HTTP POST发送消息，Server通过一个长期保持的Server-Sent Events（SSE）连接向Client推送消息。这种方案存在明显缺陷——需要维护两条独立连接，且在断线重连、负载均衡和多实例部署时容易出问题，部分基础设施还会缓冲或中断长连接。Streamable HTTP对此做了改进：Client统一通过HTTP POST发送消息，Server可以直接返回普通HTTP响应，也可以在需要流式输出时返回一个SSE流，并且支持通过会话ID在多次请求之间保持状态、支持断线后恢复。它把“长连接”从必选项变成了可选项，从而更好地兼容现有的HTTP基础设施（如CDN、API网关），也更适合无服务器部署。

服务端三原语：Tools、Resources与Prompts

MCP Server提供三类核心能力，每种的控制权归属不同。

Tools由模型控制。 模型自行决定何时调用哪个工具。每个工具包含名称、描述和输入参数schema。

Resources由Host控制。 这些是通过URI标识的数据，比如文件路径或数据库表。Host决定将哪些Resource放入模型的上下文中。

Prompts由用户控制。 这些是预置模板，由用户主动选择使用。

客户端侧能力：Sampling、Elicitation与通知

MCP并非单向通道。Client同样向Server提供几项能力。Sampling允许Server请求Client用其模型生成补全内容，这样Server无需自建AI能力。Elicitation让Server可以在交互过程中向用户索取信息，比如确认操作或补充缺失的细节。此外，当Server的工具列表发生变化时，会发送list changed通知，让Client即时感知。

完整调用流程：一个GitHub场景

用户说：“帮我总结这个仓库里所有open状态的issue。”Host中的模型判断需要调用GitHub相关工具，Host先向用户请求授权，随后Client发送tools/call请求并携带参数。Server调用GitHub API，将结果返回给Client，结果进入模型上下文，模型据此生成摘要。

整个过程中，模型从未直接接触GitHub API，凭证始终留在Server端。这正是MCP设计的精妙之处——能力暴露与凭证管理彻底解耦。

OAuth 2.1是MCP远程Server授权的安全基础。与早期版本相比，OAuth 2.1强制要求使用PKCE（Proof Key for Code Exchange），禁止隐式授权流程，并要求重定向URI精确匹配，以降低授权码被截获的风险。在MCP场景中，Client需要先通过授权服务器获取访问令牌，再在调用Server时携带该令牌；Server则负责验证令牌并据此决定可访问的资源范围。关键约束在于令牌的受众（audience）绑定：Server拿到的令牌只能用于自身，绝不能将其转发给下游API——否则一旦下游被攻破，令牌就会横向泄露。这正是文中“Server绝不能将Client的token转发给其他API”背后的协议依据。

用Python快速构建MCP Server

构建一个MCP Server的门槛并不高。Python官方SDK提供了FastMCP方式：创建一个Server对象，编写普通Python函数，加上@mcp.tool装饰器即可。函数名成为工具名，docstring成为工具描述，类型注解自动生成输入schema。测试时可用MCP Inspector工具，在浏览器中直接调用和检查Server的Tools、Resources和Prompts。

生产环境的三条设计准则

写好工具描述。 模型看不到你的代码，只读描述。描述的质量直接决定工具调用的准确性。

控制工具数量。 每个工具的定义都占用模型的上下文窗口。十个精心设计的工具优于五十个琐碎工具。

清晰返回错误。 用明确的语言回传错误信息，让模型有机会自行纠正。

安全风险：提示注入与工具投毒

最需要警惕的安全威胁是Prompt Injection。当工具返回的结果来自网页或邮件时，其中隐藏的指令可能误导模型。工具投毒（Tool Poisoning）则是恶意Server在工具描述中植入隐蔽指令。应对措施包括：只安装可信来源的Server，审查其源码。

远程Server的授权基于OAuth 2.1。Server绝不能将Client的token转发给其他API。遵循最小权限原则，对删除数据、支付等危险操作始终要求用户确认。

总结

MCP不只是一个连接器，它为AI Agent提供了一套完整协议：架构、生命周期、传输、原语和安全模型全部标准化。理解这套协议的设计逻辑，是构建可靠Agent系统的基础。