MCP PROTOCOL · HANDS-ON

协议不是黑盒：亲手发一遍 MCP 消息

本页连接一个真实的最小 MCP server（POST /api/mcp）。每次运行都会依次完成 initialize 握手、tools/list 工具发现和 tools/call 调用，并完整展示每一对 JSON-RPC 请求与响应。

MESSAGE FLOW

一次 MCP 会话的消息时序

下方实验里的每一次点击都会按这个顺序真实执行；MCP 的 streamable HTTP transport 在单请求模式下就是普通的 POST + JSON。

STEP 01initialize

客户端声明 protocolVersion 与身份信息；server 返回协商后的版本、capabilities 和 serverInfo。

STEP 02notifications/initialized

客户端确认初始化完成。这是通知：server 返回 202，不应答任何响应体。

STEP 03tools/list

server 按 JSON Schema 公布可用工具。client 不需要预先知道工具签名，运行时发现即可。

STEP 04tools/call

按 name + arguments 调用工具；结果以 content 与 structuredContent 返回，工具级失败用 isError 标记。

PROTOCOL vs MODEL CAPABILITY

MCP 是协议层标准化，function calling 是模型能力

面试高频追问。两者解决不同层的问题，经常一起出现：宿主用 function calling 让模型选择工具，用 MCP 把工具接到模型面前。

维度

MCP

FUNCTION CALLING

本质

开放协议：client 与 server 之间的 JSON-RPC 2.0 消息标准，本身与模型无关。

模型能力：模型按给定 Schema 输出结构化调用意图，本身与传输无关。

解决什么

工具的发现与接入标准化：任何 MCP client 都能连接任何 server，一次集成、处处复用。

让模型决定何时调用、调用哪个工具、参数填什么。

Schema 来源

server 通过 tools/list 动态公布，client 在运行时拉取。

应用开发者在每次模型请求里静态提供。

运行边界

工具跑在独立 server，可跨语言、跨机器、独立控权与独立发布。

工具通常在应用进程内执行，延迟最低、类型闭环最强。

本站实例

POST /api/mcp（本实验）：5 个协议方法、2 个只读工具。

POST /api/agent/run + lib/agent-runtime：受控 Agent 实验。

WHEN TO USE WHICH

工程上怎么选

选 MCP

工具要被多个宿主（IDE、对话客户端、内部平台）复用；跨语言或跨团队提供工具；需要把权限边界部署在独立服务里；接入第三方工具生态。

本实验：同一批工具对任何 MCP client 可见

选 function calling

工具是应用私有实现；追求最低延迟与最强类型闭环；工具数量少、变化慢，随应用一起发布即可。

本站受控 Agent 运行时就是这种模式

对比实验：看同一批工具如何被 function calling 运行时调用 · 延伸知识：MCP Host、Client 与 Server · MCP Tools、Resources 与 Prompts · 函数调用与工具回路

JSON-RPC 2.0 · 单请求无状态streamable HTTP transport

arguments.query

arguments.limit输入会原样放进 tools/call 的 params.arguments，并经过服务端 Zod 严格校验。

只读工具经 MCP 暴露；save_learning_note 只走站内人工审批

协议错误返回标准 JSON-RPC error（-32601 / -32602 / -32600）

Schema 与权限守卫复用受控 Agent 运行时，无第二份实现

运行后，这里会逐帧展示 initialize、tools/list、tools/call 的 JSON-RPC 请求与响应原文。