第八话｜MCP 的边界：工具发现与调用是协议，选哪个工具仍是模型的事

Tue, 09 Jun 2026 00:00:00 +0000

第七话结尾，留下了一个没解决的问题。

那一篇我们让 Agent 记住了「你是谁、你要什么」——跨会话、跨进程地。但记忆要真正派上用场，还差一环：Agent 要去做事，就得调工具。而调工具这件事，前七话一直是「写死」的。

查天气，是代码里写死的一个函数；查库存，是代码里写死的另一个函数。每接一个新工具，就得写一套适配——把它的参数拼成 LLM 认识的 schema，把它的返回值包成 LLM 认识的 Observation。一个工具一套，N 个模型 × M 个工具，就是 N×M 套。

于是问题冒出来了：

工具能不能像 USB 外设一样，插上就能被 Agent 发现、调用，而不是每接一个都要手写一套适配？

「怎么把工具接进来」，就是 MCP（Model Context Protocol） 要解决的问题。

但讲 MCP 之前，得先立住一条边界——它是 MCP 最容易讲错、也最容易被误解的地方：

MCP 定义了「工具怎么被发现、怎么被调用」的格式，但「选哪个工具、给什么参数」这一步，MCP 一个字都不管。 前者是协议，后者是 LLM 在 function-calling 层做的决策。

这条边界落到代码上，就是一件事：把前七话那个 ReAct 循环里「写死的工具源」，换成「可发现、可调用」的 MCP Server——以及在这两者之间，你自己要写的那几行桥接。

一、内存注册表的集成成本：每接一个工具都是一份私有适配

先回到第五话。那一次我们手写了一个 ReAct 循环，模型「想」一步、「做」一步、「看」一步。其中「做」这一步，工具是从哪来的？看代码：

# C05 tools.py —— 工具注册表，写死在进程里
class ToolRegistry:
 def __init__(self):
 self._tools: dict = {} # 工具名 → {fn, schema}

 def register(self, fn, name, description, parameters):
 self._tools[name] = {"fn": fn, "schema": {...}}

 def list_schemas(self):
 return [t["schema"] for t in self._tools.values()] # 给 LLM 拼 tools 参数

 def execute(self, name, arguments):
 return self._tools[name]["fn"](**arguments) # 本地函数调用

而 ReAct 循环里，工具是这样被用到的：

# C05 react_loop.py —— 循环里对工具的两次触碰
msg = call_llm(state.messages, tools=self.registry.list_schemas()) # ① 工具列表来自注册表
...
resp = self.registry.execute(fn["name"], args) # ② 调用发给本地函数

两个动作，一个来源：工具定义和工具实现，都住在同一个进程的内存里。 list_schemas() 把工具描述拼给 LLM，execute() 直接调本地函数——工具「从哪来」和「调用发给谁」，是一件事，而且都写死。

这在只有一个 get_weather 的时候很顺手。但一旦要接别人家的工具，问题就现形了：

场景	写死的注册表	你实际要做的
接一个天气 API	手写 `get_weather` 函数	读它家的文档，自己写适配
接一个股票数据源	手写 `get_quote` 函数	再读一套文档，再写一套适配
换一个 Agent 框架	注册表 API 全变	全重写
工具升级了	改函数体	改完还要同步改 schema

问题不在「写函数」这件事本身，而在于：「工具怎么被描述」和「工具怎么被调用」，每个工具、每个框架、每个厂商都各有一套私有的约定。 你写的适配，绑死了工具、绑死了框架、绑死了厂商。

这就是 N×M 集成问题——N 个模型/框架 × M 个工具，组合爆炸。你要的是一套「工具如何被发现和调用」的公共约定，而不是第 M+1 套私有适配。 而这，正是 MCP 要解决的。

二、MCP 只解决一件事：把工具接口与实现解耦

MCP 干的事，一句话：把「工具怎么被发现、怎么被调用」做成一套公开标准，让「提供工具的一方」和「使用工具的一方」彻底解耦。

它像什么？像 USB-C。你插一个键盘、一个显示器、一个硬盘，主机不用为每个外设写驱动——因为「外设怎么自我介绍、数据怎么传」有一套公开协议。外设厂商照协议做设备，主机照协议读设备，谁也不用认识谁。

MCP 也是这么个东西，只是对象从「外设」换成了「工具」：

flowchart LR
 subgraph S[工具提供方 · MCP Server]
 T1[get_weather]
 T2[get_quote]
 T3[refund_order]
 end
 subgraph C[工具消费方 · MCP Client]
 H[你的 Agent 循环]
 end
 S -- "标准协议：发现 tools/list · 调用 tools/call" --> C

Server 端负责「我有这些工具，能这么调」；Client 端负责「我发现、我调用」。中间只有一套标准协议，两边各写各的，谁都不需要知道对方的实现。

这套协议有几个关键事实，先立住：

它借了 LSP 的消息流设计——LSP（Language Server Protocol）早就证明了「编辑器 ↔ 语言服务」可以用 JSON-RPC 解耦，MCP 把同样的思路搬到了「Agent ↔ 工具」。
它由 Anthropic 于 2024 年 11 月开源，之后 OpenAI（2025-03）、Google（2025-04）、微软（2025-05）陆续采纳，2025 年 12 月捐给 Linux Foundation 旗下的 Agentic AI Foundation（AAIF）——已经从一个厂商的项目，变成了跨厂商的事实标准。
底层是 JSON-RPC 2.0，消息走 stdio（子进程标准输入输出）或 Streamable HTTP 两种传输。
三个核心原语：Tools、Resources、Prompts（后来加了 Sampling）。这里只展开 Tools——因为它正是我们前七话一直在调、也最关心的一种。Resources（让模型读数据）和 Prompts（让模型拿模板）是另外两个维度，这里不展开。

但比这些事实更关键的，是下面这条边界：

MCP 只到「工具发现与调用」为止。它不替 LLM 决策。

MCP 的 tools/list 返回的，是「这些工具叫什么、能收什么参数」；MCP 的 tools/call 执行的，是「你（Agent）指名要调的那个工具」。至于「该调哪个工具、给什么参数」，MCP 从头到尾不参与——那是 LLM 在 function-calling 层干的活。

这条边界落到代码里，就是「发现」和「调用」两段——接下来动手把它实现出来。

三、真正要动的只有一处：把循环里的工具源换成 MCP Server

不背协议术语，就做一件事：把第五话那个 ReAct 循环里的「写死的工具源」，换成「MCP Server」，然后看中间多出来的那几行桥接。

3.1 Server 端：暴露工具，就一个装饰器

Server 端用官方 Python SDK v2，暴露三个工具——两个语义化工具（get_weather、get_time）给 LLM 去「选择」，一个最小确定性工具（add）用来验收协议链路本身：

# server.py —— 工具提供方，跑在独立进程里
from mcp.server import MCPServer

mcp = MCPServer("c08-mcp-demo")

@mcp.tool()
def add(a: int, b: int) -> int:
 """Add two integers and return the result."""
 return a + b

@mcp.tool()
def get_weather(city: str) -> str:
 """Get the current weather for a city."""
 fake = {"北京": "晴，24°C", "上海": "多云，27°C", "深圳": "阵雨，30°C"}
 return fake.get(city, f"{city} 暂无数据")

@mcp.tool()
def get_time() -> str:
 """Get the current server time."""
 return datetime.now(timezone.utc).isoformat()

if __name__ == "__main__":
 mcp.run() # 默认走 stdio：从 stdin 读 JSON-RPC，往 stdout 写 JSON-RPC

有个细节现在就得记住，它是 MCP 最容易踩的坑之一：mcp.run() 走 stdio，意味着 stdout 就是协议通道。 任何业务日志 print 到 stdout，都会污染 JSON-RPC 消息流，导致客户端解析失败。所以日志只能写 stderr（代码里那条 sys.stderr.write(...) 就是为此）。

3.2 Client 端：发现和调用，两行就够

Client 端启动这个 Server 子进程，连上去，发现工具、调用工具：

# main.py —— 工具消费方
from mcp import Client, StdioServerParameters

async with Client(StdioServerParameters(
 command=sys.executable, args=["server.py"])) as client:

 listed = await client.list_tools() # 发现：tools/list
 result = await client.call_tool("add", {"a": 2, "b": 3}) # 调用：tools/call
 print(result.structured_content) # 5

跑起来，真实输出：

[1] 纯 MCP 层：发现工具 → 调用工具 → 错误路径
 发现工具: ['add', 'get_weather', 'get_time']
 - add: Add two integers and return the result.
 - get_weather: Get the current weather for a city.
 - get_time: Get the current server time.
 调用 add(2, 3): 5
 错误场景（未知工具）: is_error=True; Unknown tool: missing_tool

注意最后一行。调用一个不存在的工具，MCP 没有抛异常，而是返回了一个 is_error=True 的结果，错误信息放在结果里。这是 MCP 的一个设计取向：错误也是协议的一部分，走的是返回值而不是异常栈——调用方拿到的是结构化的错误结果，而不是一个需要 try/catch 去猜的异常。这跟第四话 ToolRegistry 里「错误要结构化、可读」是同一个思路，只是这次被提到了协议层。

到这里，「发现」和「调用」这两条协议链路都通了。但——这还只是 MCP 自己。LLM 在哪？

3.3 桥接是唯一的脏活，也是唯一不能省的一步

回到第五话的 ReAct 循环，工具源是内存注册表，两处触碰：

msg = call_llm(messages, tools=self.registry.list_schemas()) # ① 工具列表 → LLM
resp = self.registry.execute(name, args) # ② LLM 的选择 → 本地函数

换成 MCP 之后，循环本身一行都不用改——模型照样「想」、照样「做」、照样「看」。变的只有这两处触碰的来源：

# 换成 MCP 之后
async with Client(stdio_server()) as client:
 tools = await client.list_tools() # ① 工具列表来自 MCP
 resp = call_llm(messages, tools=tools_to_llm_schema(tools))
 ...
 result = await client.call_tool(name, args) # ② 调用发给 MCP

但注意中间那一步——tools_to_llm_schema(tools)。 这就是桥接，而且是 MCP 自己不会替你做的事。

client.list_tools() 返回的，是 MCP 的 Tool 对象（name / description / input_schema）；而 LLM 的 function-calling 认的，是 OpenAI 风格的 tools 参数（type: "function" / function: {name, description, parameters}）。这两个格式长得像，但不是一个东西。把它们对齐，是你（Agent 代码）要写的字段搬运：

def tools_to_llm_schema(mcp_tools):
 """把 MCP 的 tools/list 结果，转成 LLM function-calling 的 tools 参数。"""
 return [
 {
 "type": "function",
 "function": {
 "name": t.name,
 "description": t.description or "",
 "parameters": t.input_schema or {"type": "object", "properties": {}},
 },
 }
 for t in mcp_tools
 ]

就是这十几行，没用什么高深技巧。但它恰恰是最容易被忽略、也最容易误解的一环：

MCP 到 LLM 之间，没有一步是 MCP 自己完成的。 tools/list 返回 MCP 的工具描述，要变成 LLM 认识的 tools 参数，是你做的字段搬运；LLM 返回的 tool_call，要变成 MCP 的 tools/call，也是你做的。

很多人对 MCP 的误解，恰恰卡在这里：以为「装上 MCP 工具，就自动能被 LLM 用了」。不是的。MCP 把「工具怎么描述、怎么调用」标准化了，但「把 MCP 工具翻译给 LLM」和「把 LLM 的选择翻译回 MCP 调用」，这两步是 Agent 循环里你自己写的桥接代码。框架（LangChain、SDK 的 agent 封装）会把这一步藏进 bind_tools()、create_mcp_client() 之类的黑盒里，让你看不见；手写循环反而把这一步摊开在眼前。

这条链，用一张图看更清楚：

sequenceDiagram
 participant L as LLM
 participant A as Agent 循环
（你的代码）
 participant C as MCP Client
 participant S as MCP Server

 A->>C: list_tools()
 C->>S: tools/list (JSON-RPC)
 S-->>C: [add, get_weather, get_time]
 C-->>A: MCP Tool 对象
 A->>A: tools_to_llm_schema()
（桥接：MCP → LLM 格式）
 A->>L: chat(messages, tools=...)
 L-->>A: tool_calls = [get_weather(city=北京), add(a=12,b=30)]
 A->>C: call_tool(get_weather, {city:北京})
 C->>S: tools/call (JSON-RPC)
 S-->>C: "晴，24°C"
 C-->>A: Observation
 A->>A: 把 Observation 回填 messages
 A->>L: chat(messages) ← 带上工具结果
 L-->>A: "北京晴 24°C，12+30=42"

看清这条链上，MCP 到底在哪、LLM 到底在哪：MCP 只出现在「工具发现」和「工具执行」两段；「选哪个工具、给什么参数」，是 LLM 从 tools 参数里自己决定的；「把 MCP 结果翻译给 LLM、把 LLM 的选择翻译成 MCP 调用」，是 Agent 循环做的。三者各司其职，边界清晰。

3.4 串起来，让模型自己挑工具

把上面全部串起来，带真实 LLM 跑一遍。问题是「北京今天天气怎么样？顺便帮我算一下 12 加 30」——这句话故意一次要两个工具，好让「模型选择」这个关键点现形：

[2] LLM 完整闭环：MCP 工具 → LLM 决策 → 执行 → 回答
 问：北京今天天气怎么样？顺便帮我算一下 12 加 30。
 从 MCP 拿到 3 个工具，转成 function-calling schema
 模型选择调用 get_weather({'city': '北京'})
 Observation: "晴，24°C"
 模型选择调用 add({'a': 12, 'b': 30})
 Observation: 42
 最终回答: 北京今天晴，24°C；12 加 30 等于 42。

模型自己挑了 get_weather（不是 get_time，不是 add），给对了参数 city=北京；又挑了 add 去算 12+30。这两个「选择」全是 LLM 在 function-calling 层做的，MCP 全程没参与决策——它只负责把 get_weather 和 add 这两个工具「被发现」和「被调用」。

这正是那句话的活体证据：

MCP 标准化了「工具怎么被发现、怎么被调用」，但它不替 LLM 决策——选哪个工具、给什么参数，仍是 LLM 在 function-calling 层做的。

四、从 demo 到生产，还有四块要补

跑通了最小闭环，但你不会就这么上线。从「demo 能跑」到「生产能用」，至少要补四块：

传输换成 Streamable HTTP。 stdio 只能本地子进程；生产里的 MCP Server 往往跑在远端、要鉴权、要并发。Streamable HTTP 是 stdio 的远程版，也支持无状态服务器的水平扩展。
工具白名单 / 覆写。 MCP Server 暴露的工具，你不一定全要、也不一定全信。生产里 Client 端通常会过滤、重命名、甚至覆写某个工具的 schema，而不是「Server 给什么就接什么」。
可观测。 一次 tools/call 从发起到返回，走了哪台 Server、耗时多少、失败在哪，需要 Trace 和日志。demo 里那些打到 stderr 的日志，就是这条链的雏形。
安全边界。 MCP 的 tools/call 本质是「让 Agent 替你执行一个远端函数」。这个函数能不能写文件、能不能发请求、能不能碰敏感数据，是 Server 端要想清楚并显式约束的，不能把「协议通了」当成「安全没问题」。

这四块，把 MCP 从「能跑」推进到「敢用」。它们属于「工程化」的延伸，不是「MCP 是什么」本身，所以这里只列出来，不展开。

五、工具能标准化接入了，下一个没解决的问题是什么

把这条数据流从头到尾捋一遍，答案就完整了：

前七话：工具写死在内存注册表里，list_schemas() 拼给 LLM，execute() 调本地函数
 → 痛点：每接一个工具/框架/厂商，都要手写一套适配，N×M 组合爆炸
 → MCP：把「工具怎么被发现、怎么被调用」做成标准协议，Server/Client 解耦
 → 桥接：tools/list 结果 → tools_to_llm_schema() → LLM 的 function-calling 参数
 → 决策：LLM 从 tools 里自己选工具、给参数（MCP 不参与）
 → 执行：Agent 把 LLM 的选择，翻译成 MCP 的 tools/call，拿回 Observation
 → 回答：Observation 回填 messages，LLM 生成最终答案

MCP 是「工具注册表」和「工具执行器」的替代品，不是「Agent 循环」的替代品。它把原来「本地字典 + 本地函数」这两件事，换成了「跨进程问一个 Server」；而循环、状态、记忆、决策，全都还在你手里。那几行 tools_to_llm_schema() 桥接，就是 MCP 和 LLM 之间「你」的存在——框架会把它藏起来，但理解了它，你才真正理解了 MCP 是怎么进 Agent 的。

工具能标准化地接入了，但还有一类东西没法靠 MCP 解决：「怎么做一件事的方法」。 查天气是工具，但「处理订单要先查库存、再扣库存、扣完发通知、全程落盘」是一套方法——它不是「一个工具」，而是「一串工具的编排 + 判断」。工具能即插即用了，方法怎么复用？这就是第九话要讲的：Skill。

演示代码：Python 版在 GYA 仓库 c08-mcp，Java 21 等价实现在 GYA-Java 仓库 c08-mcp。按各自 README 的命令跑，不要复制这篇文章里零散的代码块。

运行环境：Python 版用官方 MCP Python SDK v2（mcp[cli]，实测 2.2.0）；Java 版用官方 MCP Java SDK 2.0.1。注意：本文代码基于 SDK v2 的 API（from mcp import Client / from mcp.server import MCPServer）。 如果你手上还留着 v1 风格的旧代码（ClientSession、stdio_client 上下文、client.initialize()、result.content[0].text），那在 v2 下是跑不通的——v2 把客户端统一成了 Client、结果结构也从 content[0].text 改成了 structured_content / is_error。

参考：MCP 由 Anthropic 于 2024 年 11 月 25 日开源（Wikipedia「Model Context Protocol」条目），2025 年 12 月捐给 Linux Foundation 旗下的 Agentic AI Foundation（AAIF）；底层为 JSON-RPC 2.0，传输支持 stdio 与 Streamable HTTP；核心原语为 Tools / Resources / Prompts（另加 Sampling）。借鉴 LSP 消息流设计一事，见 Anthropic 官方介绍与 MCP 规范文档。闭环 Trace 为 2026-09 本机实测（Python 与 Java 双跑）。

JSON-RPC on Renxin's Blog