MCP 核心架构

理解 MCP 的连接：客户端、服务器与大型语言模型

MCP 促进了客户端（代表用户或宿主应用程序操作）、服务器（提供上下文和能力访问）和 LLM（大型语言模型，消费上下文并驱动交互）之间精妙的协作。核心思想是创建一个结构化的通信通道，使 LLM 可以通过客户端动态查询相关信息或调用服务器公开的工具。这不同于简单地将大量静态文本塞入提示中；相反，MCP 使 LLM 能够以更具交互性和目标性的方式，在需要时获取所需信息。

例如，一个 LLM 试图帮助开发者在集成开发环境（IDE，即宿主应用）中调试代码时，可能会使用 MCP 客户端向 MCP 服务器查询特定文件的内容、编译器错误列表（资源），或者请求执行测试脚本（工具）。

基于 JSON-RPC 的协议

MCP 利用 JSON-RPC 2.0 作为其基础消息协议。JSON-RPC 是一种轻量级远程过程调用协议，使用 JSON 作为其数据格式。这一选择提供了多项优势：

简洁性与可读性：JSON 易于人类阅读，也方便机器解析。
广泛支持：各种编程语言中存在大量 JSON 和 JSON-RPC 库，简化了实现过程。
清晰规范：JSON-RPC 对请求、响应、通知和错误处理有明确的定义结构。
传输无关性：尽管 MCP 通常使用 WebSockets，但 JSON-RPC 也可以通过其他机制传输，例如 HTTP 或 IPC（进程间通信）通道。

在 MCP 中，客户端请求列出资源、获取提示建议或执行工具，以及服务器的回复，均格式化为 JSON-RPC 消息。

有状态连接

MCP 的一个关键架构特性是其对有状态连接的强调。这意味着一旦客户端连接到服务器，该连接通常在整个交互会话期间保持。这通常通过 WebSockets 实现。

有状态性至关重要，原因如下：

降低延迟：消除了每次请求都建立新连接的开销。
高效上下文管理：服务器可以维护关于客户端或当前任务的会话特定上下文，从而提供更智能的响应和建议。
双向通信：服务器可以主动向客户端发送更新或通知（例如，文件已更改，长时间运行的工具已完成）。这在使用传统的无状态请求-响应模型（如 HTTP）时难以高效实现。
流式传输：促进数据流式传输，这对于大型资源或持续更新非常有用。

服务器与客户端能力协商

MCP 包含服务器与客户端之间进行能力协商的机制。这很重要，因为并非所有客户端都支持服务器提供的所有功能，反之亦然。此外，协议的新版本或特定扩展可能引入新的能力。

在初始握手或特定的交互点，客户端和服务器可以交换关于以下信息：

支持的 MCP 协议版本。
可用的方法（例如，针对资源、提示、工具）。
它们可以处理的数据格式或模式（schemas）。
支持的安全协议或认证机制。

这种协商确保了更顺畅的互操作性，并允许生态系统发展。例如，服务器可能会声明它支持特定版本的“代码索引”工具，然后客户端可以根据自身能力决定是否以及如何使用它。