MCP基础：主机、客户端、服务器以及JSON-RPC协议格式
了解模型上下文协议存在的缘由，主机、客户端和服务器如何分工协作，JSON-RPC消息的格式是怎样的，以及标准输入输出与HTTP传输方式之间存在哪些差异。
来源: Beyond the Noise: How MCP Unlocks the Real Value of LLMs
语言模型在能够执行操作而不仅仅是回答问题的那一刻，才真正对企业产生价值。难点从来不在模型本身，而在于如何将其与实际处理工作的数据库、API及内部工具相连，并且只需实现一次连接，而无需为每个应用或每个模型供应商都重复操作。模型上下文协议（MCP）正是为标准化这种连接而设计的。本文将阐述MCP解决的问题、其各组件的功能、通过网络传输的内容，以及两种标准传输方式的差异，帮助你了解MCP服务器在自身架构中的定位。
大语言模型创造价值的途径：执行操作
过去，由于软件无法解析结构松散的请求，许多自动化功能根本无法实现。语言模型消除了这一障碍，一旦与各类工具相连，就能驱动那些原本需要人工在多个系统之间切换的多步骤工作流程。
以一个被要求查找并预订从卡萨布兰卡到拉巴特的火车的助手为例。理解请求只是第一步，该助手还需要查询时刻表服务、选择出发时间、调用预订API并确认结果。每一个步骤都对应一次工具调用。当这些工具通过MCP服务器暴露出来后，任何兼容的智能体都能完成整个流程。
其商业价值显而易见：每项任务所需的操作步骤越少，运营成本就越低，处理速度也越快。此外还有用户体验方面的优势。员工通常需要同时操作多个仪表盘和界面，而每个都有各自的逻辑机制。通过将对话式前端与这些后端相连，就可以在单一界面背后隐藏大部分复杂逻辑。
MCP解决的集成问题
工具的使用并非新鲜事。所有主流的LLM SDK都支持这一功能，但它们在声明工具、描述参数以及返回结果的方式上各有不同规范。实际结果是，同一个工具往往会被每个模型提供商实现多次。若要更换模型或同时支持多个模型，就必须重新移植相应的集成代码，这不仅会拖慢团队进度，还会增加产品的扩展难度。
跳过SDK并不能完全解决这个问题。你可以自行编写集成层，将意图映射为操作、调用接口端点、收集参数、处理错误并记录分析数据。这会增加复杂性，但仍在可控范围内。更深层的问题在于，这样的集成层通常只存在于某个应用程序内部。当另一个应用程序需要相同的工具时，团队就必须重新构建同样的集成层。这样一来，集成逻辑就与使用方绑定在一起，而非与拥有相应功能的系统相连接。
MCP是什么
MCP是一项开放标准，为人工智能应用程序提供了一种通用的方式来连接数据源和工具。它并没有实现以前完全不可能的功能，只是让这些连接变得更简单、更一致。modelcontextprotocol.io上的协议文档是权威参考资料。
关键的变化在于工具逻辑的所在位置。在MCP架构中，数据库、API或内部工具等后端服务通过MCP服务器来发布自身的功能。常用的类比是USB-C接口：该服务提供一个标准插槽，任何兼容的应用程序都可以接入其中。AI应用程序不再需要掌握如何使用各个工具的细节，只需遵循相应的协议即可。
架构：主机、客户端与服务器
MCP采用客户端-服务器架构，其中包含三个容易混淆的角色：
- 主机：即AI应用程序本身，例如聊天助手、带有智能代理的集成开发环境，或是你自己的代理服务。它是用户交互的对象，并通过一个或多个MCP服务器与外部世界相连。
主机从不直接与服务器通信。它会为每个服务器创建一个客户端，并将所有通信任务交由该客户端处理，而每个客户端都维持着专用的点对点连接。这种分离在实践中非常有用：当主机同时连接到文件系统服务器、工单处理服务器和CRM服务器时，它会运行三个独立的客户端，这样某个连接出现故障或权限问题就不会影响到其他连接。
三种服务器原语
原语定义了各方能够提供的功能。服务器主要提供三种类型的原语：
- 工具：模型可以执行的操作，例如调用 API 或写入记录。
- 资源：模型可以读取并用作上下文的数据，例如数据库行或文档。
- 提示词：用于指导模型的预定义指令模板，其作用类似于可重复使用的系统提示词。
工具与资源之间的区别对安全性和设计至关重要。读取资源不应产生任何副作用，而调用工具则可能改变现实状态，因此托管平台通常会对二者应用不同的审批规则。
JSON 与 JSON-RPC：消息格式
JSON（JavaScript对象表示法）通过键值对、数组和嵌套对象将结构化数据以文本形式呈现。由于其格式简单且被广泛支持，使用不同语言编写的发送方与接收方能够就消息的含义达成一致。
JSON-RPC在此基础上进一步定义了用于远程过程调用的固定消息结构。请求中会指定方法名称、携带参数并包含一个标识符；只要双方都遵循该结构，客户端就可以以同样可预测的格式请求服务器执行某方法，并获取结果或错误信息。下面的示例是一个JSON-RPC 2.0请求，用于让服务器查询卡萨布兰卡的天气情况。请注意其中的四个字段：协议版本、用于匹配响应的请求id、method名称以及params对象。
{
"jsonrpc": "2.0",
"id": 1,
"method": "get_weather",
"params": {
"city": "Casablanca"
}
}
此示例展示了纯粹的 JSON-RPC 方式。在 MCP 中，工具并不会以对应名称的顶层方法形式被调用。相反，客户端会发送带有 tools/call 方法的请求，并将工具名称及其参数放入 params 中。正是这种间接调用方式使得 MCP 能够定义固定的协议方法集，同时服务器仍可自由地暴露任何它们想要的工具。
发现机制是缺失的一环
JSON-RPC本身存在一个缺陷：客户端必须事先知道服务器提供哪些方法。MCP通过标准化客户端发现功能的方式弥补了这一缺陷。客户端可以请求服务器列出其工具、资源及提示语，从而获取名称、描述和输入格式，再将这些描述传递给模型。MCP还规定了连接如何初始化以及何种传输机制用于传递消息。
传输机制：消息的传递方式
JSON-RPC负责定义术语规范，而传输机制则决定了字节如何在客户端与服务器之间传输。截至撰写本文时，MCP规定了两种标准传输机制。由于该协议仍在不断发展，因此在依赖相关细节之前请查阅最新规范。
用于本地工具的stdio
通过stdio传输方式，客户端会将MCP服务器作为子进程启动。服务器从标准输入读取传入的消息，并将响应写入标准输出。每个进程都会自动从操作系统中获得这些管道，因此无需使用网络套接字或端口。
这使得stdio非常适合在与主机同一台机器上运行的工具，例如在本地文件系统中创建文件夹的服务器。其另一个好处是隔离性：只要主机保持该服务器运行，它就存在，且无法从网络访问。
用于共享远程服务器的Streamable HTTP
通过Streamable HTTP，服务器作为独立的进程以HTTP服务的形式运行，能够同时为多个客户端提供服务。消息通过普通的HTTP请求进行交换。
这种传输方式支持流式传输。服务器无需等待完整响应，就可以逐步发送数据，这对于耗时较长的工具调用非常有用。流式传输是通过服务端推送事件（SSE）实现的，它是一种单向通道，一个长生命周期的HTTP响应会携带一系列由服务器推送的事件。而另一方向的通信仍以客户端发出的普通HTTP请求形式进行。其具体表现取决于实现方式以及所使用的HTTP版本。
一个实用的准则是：如果该工具仅在单个用户的机器上使用，则选择stdio；如果需要在不同用户或团队之间共享功能，并且需要共享服务所要求的身份验证和网络控制机制，则选择可流式传输的HTTP。
为何协议比其他SDK更重要
协议的存在是为了让不同团队使用不同语言、按照不同时间表开发的系统仍能实现可预测的互操作。协议是一套约定的规则，规定了独立组件之间如何通信、解读彼此的消息以及建立信任关系。
标准化工具访问方式的价值主要体现在经济层面。当新模型或新应用的集成成本趋近于零时，实验成本也会随之降低，而低成本的实验则能推动更快速的迭代。拥有该系统的团队只需部署一个MCP服务器，组织内所有当前及未来的AI应用都无需编写专门的适配代码即可使用它。如需了解这在智能体框架中的实现方式，请参阅我们关于利用MCP在LangGraph中实现工具集成标准化的文章。
核心要点
- 当大语言模型能够在真实系统中运行时才能发挥最大价值，而瓶颈在于集成而非智能水平。
- 由于缺乏标准，同一工具需要为不同的模型SDK和应用程序重新实现；MCP则将相关逻辑转移到提供该功能的系统所拥有的服务器上。
- 每台主机为每个服务器运行一个客户端，且每个客户端都保持独立的连接；服务器则提供工具、资源及提示词。
- JSON-RPC负责定义消息格式，而MCP则增加了固定的方法词汇表（如
tools/call）以及能力发现功能。 - 本地单用户工具可使用stdio，而共享的远程服务则适用Streamable HTTP，并需根据当前规范核对传输细节。