MCP - Model–Control Protocol

Cline 可以帮助练习 prompt

引言

MCP（Model–Control Protocol）：一种用于在大模型（LLM）与外部工具/服务之间进行高效、可控交互的标准化协议。
目标：
- 解耦模型与工具开发，提升复用性
- 支持流式反馈、超时管理、安全和权限控制
- 兼容多种传输方式（HTTP、SSE、WebSocket 等）

SSE VS Streamable HTTP

特性	Server-Sent Events (SSE)	Streamable HTTP
双向通信	单向（服务器 → 客户端）	单向（服务器 → 客户端）
标准化	HTML5 原生支持	需自行设计“分段”格式（如 chunked）
重连机制	自动重连、事件 ID	需手动管理
使用场景	实时日志、进度汇报、流式回复	大文件下载、视频流、增量响应

优劣对比

SSE 内置心跳、断线重连更友好；
Streamable HTTP 对接老系统成本低、兼容性更强。

MCP VS RPC

方面	RPC（Remote Procedure Call）	MCP（Model–Control Protocol）
调用范式	直接调用具体函数/方法	LLM 驱动，根据“tools list”动态决策
耦合度	较高（client/服务端同步定义）	低（工具注册与调用解耦）
扩展性	新增接口需修改 client 代码	新增工具只需更新 schema，无需改 agent
交互模式	请求→响应	请求→流式推理→多轮调用→响应

MCP的工具发现机制（tools/list 协议）

tools/list：客户端发起一次“列出可用工具”的 RPC 或 HTTP 请求。
服务端返回 JSON 数组，每项包含：
- name（工具标识）
- description（功能说明）
- parameters（JSON Schema，限定调用参数格式）
Agent/Client 根据此列表动态构建 prompt，使 LLM 在推理时可选调用。

ListTool 动态优化方案

MCP 协议里允许所有的 Request 和 Response 的 params 里带上 _meta 字段，即业务可以透传元数据。

在 MCP Server 实现的时候，自定义 listToolHandler 即可根据 meta 做一些业务逻辑区分。

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Get current weather information for a location",
        "inputSchema": {
          "type": "object",
          "properties": {
            "location": {
              "type": "string",
              "description": "City name or zip code"
            }
          },
          "required": ["location"]
        }
      }
    ],
    "nextCursor": "next-page-cursor",
    "_meta": {
      "get_weather": {
        "tool_extra": "tool extra info"
      }
    }
  }
}

超时与流式反馈

超时控制 & Fallback

工具耗时过长
- 通过设置超时阈值，触发 fallback；
- 使用 SSE 向客户端汇报 当前进度、日志，防止“无响应”假死。
实现要点
- 在工具执行端，每完成一个阶段就 push 一个 SSE 事件；
- 客户端收到流式进度，更新 UI 或引导下一步交互。

Tool耗时过长

SSE向客户端汇报，可以解决流式回答

进度通知

MCP Server 支持运行长耗时任务，并通过 Http SSE 向客户端推送通知流
此功能需要客户端发送 progressToken 启用能力，建议使用 uuid 作为唯一标识

客户端配置

客户端需在请求中设置 progressToken，它与 jsonrpc 的 id 不同，业务方无法直接获取系统递增生成的 id。
示例中展示了如何在 _params_ 字段中添加 progressToken：

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "some_method",
  "params": {
    "_meta": {
      "progressToken": "abc123"
    }
  }
}

服务端实现

同时需要 MCP Server 配置实现 report，即 Server 开发者可以在某个运行点位，把进度通知到 client。

total 可以理解为总步数，progress 是当前进度，progress 必须小于等于 total，且每次发送 progress 要变大。
如果不能准确判断总步数，可以只递增发送 progress，不设置 total，即 total = null。

{
  "jsonrpc": "2.0",
  "method": "notifications/progress",
  "params": {
    "progressToken": "abc123",
    "progress": 50,
    "total": 100
  }
}

Human-in-the-Loop 与动态采样

告诉client 期望的调用的大模型和参数，以及message返回等等

可以修改发送内容和收到的内容，可以保护隐私，安全机制

通过在请求中携带 meta 原始数据，实现按业务场景动态返回不同功能，同时支持细粒度权限控制。

Human-in-the-Loop：
- 在关键决策点（如高风险操作、财务决算）人工审核；
- 通过 sampling（抽样）策略，随机或基于置信度把部分调用结果回给审阅者。
隐私与安全
- 在请求中携带 meta 原始数据（脱敏或加密），后端根据业务场景动态开放不同功能；
- 支持 细粒度权限控制：不同角色可见不同字段。

A2A（Agent-to-Agent）

解决智能体之间通信与协作的问题

主Agent将复杂任务分解，并委派给其他智能体，汇总成果完成

A2A与MCP是互补关系

Agent：能够通过使用工具，推理和用户交互来完成新任务的应用程序

定义：多个智能体（Agent）间通信与任务分工的协议／架构。
流程：
- 主 Agent 接收复杂需求 → 规划子任务
- 子 Agent 各司其职，调用专属工具
- 汇总结果 → 主 Agent 整合输出
互补：MCP 聚焦模型和工具的调用标准，A2A 侧重多 Agent 的协同。

MCP如何结合A2A

MCP应用开发

为什么 Agent 需要 MCP
- 自动选择并调用最佳工具；
- 降低硬编码提示链的复杂度；
- 支持插件化生态。
Workflow vs Agent
- Workflow：预定义代码路径，固定调用顺序；
- Agent：LLM 动态推理驱动，实时决策与工具交互。
- Agent 三大核心功能
  - Perception（感知）：从用户/工具获取信息
  - Planning（规划）：推理选择下一个动作
  - Action（行动）：执行工具调用或生成回答

Tools is Important

解决：

幻觉问题
LLM不擅长的问题，例如math类问题

如何把tools跟LLM结合在一起

以往的方式

提示工程，提示有哪些工具

固定工具，工作流

longChain

不用每次拼接message，处理结果

步骤

获取search服务接口

编写client

暴露function

编写tools jsonSchema

纯 Prompt 工程：在 prompt 中硬编码工具列表，易碎；
固定 Workflow：代码层面串联多次 API 调用；
Long-Chain：代码中手动拼接多轮消息与结果；
MCP：
- 第一次 tools/list → 获取 schema → 动态构建 prompt
- LLM 生成函数调用指令 → 客户端/服务端执行 → 返回 Observation
- 循环至任务完成

典型开发步骤

1. 获取 search 服务接口  
2. 编写 MCP client  
3. 在服务端暴露 functions（工具）  
4. 撰写 tools JSON Schema

MCP优化了跟工具的交互

可以解决：

开发耦合度
复用性
生态碎片化

让工具开发者和Agent开发者各司其职，工具质量和功能的迭代不需要Agent开发者感知。

mcp inspector工具

MCP 生态与工具

mcp-inspector：可视化调试工具，实时展示：
- tools/list 返回内容
- LLM 推理出的调用决策
- 工具执行结果
Build a MCP Agent
- 使用 cline（命令行 client）快速接入 MCP Server
- 支持模拟请求、断点调试

Build a MCP Agent

可以快速通过cline接入mcp server

我觉得这是一个非常好的测试接口工具

React Agent的工作流程

Reasoning（推理）：首先通过推理来判断需要执行什么操作。
Action（行动）：基于推理结果，Agent 执行工具调用。
Observation（观察）：观察工具调用结果，判断是否需要进一步行动。
迭代：直到收集足够信息或达到终止条件

可以使用 for 循环或多 Agent 并行/串行（multi-agent）协作，配合 LangChain、Qwen 等开源框架，实现Sequential Thinking。

基于Qwen和Langchain的MCP应用开发

MCP Client的请求

MCP 直接采用了 JSON‑RPC 2.0 规范用来封装每一次 RPC 调用的底层消息格式。

请求对象：发送一个请求对象至服务端代表一个 rpc 调用。

一个请求对象包含下列成员：

- **jsonrpc**：指定 JSON‑RPC 协议版本的字符串，必须准确写为 `"2.0"`。
- **method**：包含所要调用方法名称的字符串。以 `rpc` 开头的方法名，用英文句号（U+002E 或 ASCII 46）连接的（即 `rpc.xxx`）为预留给 RPC 内部的方法名及扩展名，且不能在其他地方使用。
- **params：**调用方法所需要的结构化参数值，该成员可以省略。
- **id：**已建立客户端的唯一标识 id，值必须包含一个字符串、数值或 `null`。如果不包含该成员则被认定为是一个“通知”（notification）——服务器不会返回响应。该值一般不为 `null`，若为数值则不应包含小数。

服务端如果在响应中包含 id，则必须原样返回，用以将请求和对应的响应关联起来

Function calling with MCP

在 MCP（Model Connection Protocol） 场景下，如何用“外部模拟”的方式实现 LLM 的函数/工具调用（Function Calling）

行为

观察LLM如何决定和发起调用的具体流程

mcp像是一个function call的标准协议

实现方式

不依赖模型内置的 Function/Tool Calling API，完全通过精心设计的 System Prompt 和输出解析来实现。
执行与结果回传（由 Client 应用/Controller 处理）：
- Client 应用接收到 LLM 的完整文本响应
- 解析响应文本：查找并提取 <tool_name>…</tool_name> 格式的 XML 块
- 执行：根据提取的工具名和参数，调用 Client 本地的相应功能（e.g. 执行 fs.readFile('src/main.js')）
- 反馈：将执行结果（文件内容、命令输出、成功/失败状态）作为下一轮输入的一部分（模拟用户回复或环境信息更新）发送给 LLM

协议

以OpenAI和Anthropic Claude的协议

能力

强大的指令遵循和推理能力
- 基础：模型需要能准确理解函数描述（description）的意图，并将其与用户请求匹配。
- 体现：能在众多工具中精确选择最合适的那个；能理解复杂或模糊的用户请求并判断是否需要以及需要哪个工具。
- 强的模型：对描述的细微差别更敏感，选择更准确。
优秀的参数提取与格式化能力
- 基础：能从自然语言对话中可靠地识别、提取并结构化所需的参数。
- 体现：处理各种参数类型（字符串、数字、布尔、枚举、数组、对象）；处理缺失值、歧义；按照 JSON Schema 要求生成严格格式化的参数 JSON。
- 强的模型：参数提取更鲁棒，不易出错，生成的 JSON 格式更稳定、合规。
针对 Tool Use 的优化训练
- 基础：模型是否在训练数据中包含了大量的 Function Calling/Tool Use 样例。
- 体现：模型“知道”何时应该调用工具，如何格式化调用请求，以及如何利用工具返回的结果来生成回复。这种模式在模型内部被强化。
- 强的模型：通常是那些明确宣传并针对此功能进行了大量预训练或微调的模型（e.g. OpenAI 的 gpt-4/3.5‑turbo 系列，Google 的 Gemini 系列，Anthropic 的 Claude 3 系列）。