AI工具的标准接口:MCP(Model Context Protocol,模型上下文协议)

在大模型的相关开发中，Agent智能体需要调用工具，才能完成一系列的任务。为了让大模型能更方便的连接外部工具，Anthropic提出了MCP（Model Context Protocol，模型上下文协议）。

一、MCP形成的背景

在MCP出现之前，通常采用的是Function Calling（函数调用）的方式，让大模型调用工具。但后来需要完成的任务越来越复杂，而且需要的工具也是各种各样，原来使用Function Calling的方式就遇到问题：

1.集成问题：每一种大模型在对接每一个工具时，都需要适配。

2.每个大模型厂商对于Function Calling的格式定义都有差别，并不统一。

MCP的出现，就是为了制定一个统一的标准。通过一套通用的协议，让所有支持MCP的AI应用都能对接MCP的服务器，减少工具的重复开发。

二、MCP的主要作用

MCP的主要作用是将AI大模型与外部数据源和工具进行解耦。MCP采用客户端-服务器架构，提供有三种角色：

MCP Host：运行LLM的应用程序
MCP Client：Host内部的连接器，与Server是一对一通信
MCP Server：轻量级程序，对外提供工具/资源/提示词模板等功能

Server对外提供功能包括：

Resources（资源）：让模型能读取数据，包括本地文件，数据库记录等
Tools（工具）：让模型能执行操作，例如调用api，写文件等
Prompts（提示模板）：预定义的对话模板

三、应用实战

MCP 基于JSON-RPC 2.0构建。为了说明它的运行机制，我们用一个最常见的场景：“查询北京今天的天气”，来分析MCP中的JSON-RPC数据流向。

注：2026年7月，Anthropic发布了最新的MCP规范，下面以新规范来做说明。

（一）数据流向说明

1.直接调用(无需握手)

旧版MCP，在Host启动之后，连接MCP Server，发送initialize请求。

新版删除了强制握手，Host可以直接发送业务请求。

2.发现工具(可选)

Host可以发送server/discover 来了解Server的能力，但这不再是必要的步骤了。

3.模型决策

Host将用户的问题("北京今天天气如何？")发送给大模型，大模型推理之后，决定调用get_weather。

4.调用工具

Host向Server发送 tools/call请求。注意，这个请求中包含了HTTP Header和_meta字段，不再依赖会话ID。

5.执行与返回

Server执行逻辑，返回结果。在新版中，要求必须标注 resultType。

（二）详细的JSON-RPC数据结构说明

1.Host发送给Server的请求

新版中的请求，包括 HTTP Header 和 JSON Body 两个部分。

HTTP Header部分（新增）：

POST /mcp HTTP/1.1Host: weather.example.comContent-Type: application/jsonMCP-Protocol-Version: 2026-07-28Mcp-Method: tools/callMcp-Name: get_weather

HTTP Header数据项说明：

MCP-Protocol-Version：声明协议版本
Mcp-Method：对应JSON-RPC中的method项，这里有了method之后，网关不需要解析json就可以知道请求的意图。
Mcp-Name：具体资源或工具名。

JSON Body：

{  "jsonrpc": "2.0",  "id": 101,  "method": "tools/call",  "params": {    "name": "get_weather",    "arguments": {      "location": "北京",      "unit": "celsius"    },    "_meta": {      "io.modelcontextprotocol/protocolVersion": "2026-07-28",      "io.modelcontextprotocol/clientInfo": {        "name": "MyCoolAgent",        "version": "2.0.0"      },      "io.modelcontextprotocol/clientCapabilities": {}    }  }}

JSON-RPC数据项说明：

jsonrpc: "2.0" （没变）
id: 请求唯一标识
method: "tools/call"（没变）
params.name / params.arguments: 工具名和参数（没变）
_meta: 这个是新版实现“无状态”的关键数据项。这里携带了协议版本、客户端信息（Client Info）和能力（Capabilities）。

2.Server发给Host的响应（Response）

{  "jsonrpc": "2.0",  "id": 101,  "result": {    "resultType": "complete",    "content": [      {        "type": "text",        "text": "北京当前天气：晴，气温 25°C，湿度 40%。"      }    ],    "_meta": {      "io.modelcontextprotocol/serverInfo": {        "name": "WeatherServer",        "version": "2.0.0"      }    }  }}

Response数据项解析：

resultType（新增且必需）：这是新版中要求的必要字段，其值包括：

1）complete：表示工具执行成功并结束

2）input_required：表示工具需要更多信息

3.MRTR（Multi Round-Trip Request）多轮往返

当resultType的值为input_request时，会进入MRTR。

假设天气工具需要用户确认气温的单位（摄氏还是华氏）

第一轮响应（需要输入）：

{  "jsonrpc": "2.0",  "id": 101,  "result": {    "resultType": "input_required",    "inputRequests": {      "confirm_unit": {        "method": "elicitation/create",        "params": {          "message": "请确认温度单位：",          "options": ["celsius", "fahrenheit"]        }      }    },    "requestState": "opaque-state-string"  }}

用户输入之后，携带之前的requestState，重新发起请求

{  "jsonrpc": "2.0",  "id": 102,  // 注意：ID 变了  "method": "tools/call",  "params": {    "name": "get_weather",    "arguments": { "location": "北京" },    "inputResponses": {      "confirm_unit": { "action": "accept", "content": { "unit": "celsius" } }    },    "requestState": "opaque-state-string", // 原样带回    "_meta": { ... }  }}

四、最后

MCP生态越来越成熟，也会出现更多“即插即用”的工具，会极大提高AI能力。而对于开发者来说，理解MCP数据流向和JSON-RPC结构，是后续AI Agent开发的重要一步。