MCP工具发现：Agent如何动态感知可用工具

可视化演示

动态演示MCP工具发现的核心机制，通过总览/传输/转换/输出四种模式展示关键概念与交互流程。

发现机制概述

美食博主打开外卖 App 的“附近商家”，看到的不是一堵写满店名的墙，而是一份会呼吸、会生长的活菜单：新店开业会冒出来，售罄的菜品会消失。对 AI Agent 来说，MCP 的工具发现机制就是那枚“附近商家”按钮——它让 Agent 在运行时向 Server 发出询问：“你此刻提供了哪些工具？”而不是在出生前就把所有工具背下来。

在没有发现机制的传统集成方式里，开发者必须在代码里写死每个工具的调用方式：工具叫什么、需要传什么参数、返回什么格式。一旦服务端新增功能，客户端就得跟着改代码、发版、升级，像极了把整本电话簿背下来却只为了找一家餐厅。MCP 的发现机制把这种“静态契约”变成了“动态问答”：客户端随时可以重问，服务端随时能更新答案。

在协议层面，发现机制的核心是一条请求-响应消息流。Agent 与 Server 之间通过 JSON-RPC 格式对话，Agent 发出 tools/list，Server 返回一个工具数组。这个数组里的每个元素就是一件工具的完整“说明书”，包含工具的名称、用途和输入参数。整个过程发生在 Agent 完成初始化握手之后、首次决策调用哪个工具之前——就像一个旅人先站在街口扫一圈招牌，再决定迈进哪家店。

$$\displaystyle \text{Agent} \xrightarrow{\ \text{tools/list}\ } \text{Server}, \quad \text{Server} \xrightarrow{\ \text{tools 数组响应}\ } \text{Agent}$$

1. 客户端发起请求：Agent 作为客户端，主动发出名为 tools/list 的方法请求，询问服务端可用工具。

$$\text{method} = \text{tools/list}$$

2. 服务端返回数组：Server 响应一个 tools 数组，数组里每一项是一份完整工具定义。

$$\text{tools}: [\text{Tool}_1, \text{Tool}_2, \ldots]$$

3. 一次往返即一次发现：请求与响应构成完整的发现过程，工具列表随服务端状态实时变化。

$$\text{roundtrip} = \text{request} + \text{response}$$

像外卖 App 的列表永远不会忘记刷新一样，MCP 的发现机制让 Agent 始终握着最新鲜的“菜单”。硬编码的工具清单是博物馆里的展品，而发现机制拉取的工具列表，是窗明几净的今日菜单——Agent 的每一次行动，都从这一刻的“附近商家”开始。

工具列表请求

外卖 App 的“附近商家”背后，其实是一次次精心设计的网络请求。MCP 的 tools/list 就是那个请求协议：它是一则 JSON-RPC 2.0 消息，向服务端明确“把你的工具清单交给我”。工具特别多的时候，和外卖列表一样需要“滑动加载更多”——这就是分页。

tools/list 的请求体结构并不复杂：method 固定为 tools/list，params 里可以携带一个可选的 cursor 游标。游标是什么？它是上一页返回的“书签”：当清单太长、一次响应装不完时，服务端会返回一个 nextCursor，客户端带上它请求下一页，就像下拉刷新后继续滑动页面，直到看完所有商家。

响应体的核心是 tools 数组，每个元素是一个工具定义；如果还有更多工具未返回，响应中会带上 nextCursor。这种设计保证即使一个 Server 暴露了几百个工具，客户端也能分批拉完，不丢项、不卡顿，让 Agent 面对“挑花眼”的大列表依然从容。

$$\displaystyle \text{Request} = \{\text{method}: \text{tools/list},\ \text{params}: \{\text{cursor}?\}\}; \quad \text{Response} = \{\text{tools}: [\text{Tool}],\ \text{nextCursor}?\}$$

1. 方法名路由：请求体必须写明 method 为 tools/list，服务端据此把消息路由到“枚举工具”的处理逻辑。

$$\text{method}: \ \text{tools/list}$$

2. 可选游标参数：params 里的 cursor 是上一次响应返回的翻页凭据，第一页请求时可以省略。

$$\text{params} = \{\text{cursor}?\}$$

3. 工具数组响应：响应中的 tools 数组是发现成果的主体，每个元素都是一份完整工具元数据。

$$\text{tools}: [\text{Tool}, \ldots]$$

4. 游标续页：nextCursor 非空表示还有更多工具，客户端需要携带它继续请求，直到返回空。

$$\text{nextCursor} \neq \text{null} \Rightarrow \text{再次请求翻页}$$

点菜的流程因此变得有序：先点开“附近商家”，一页一页翻完整个工具宇宙，不漏掉任何一家藏在深处的宝藏小店。分页机制让 Agent 的“眼睛”再大也不会看花。

工具元数据

外卖商家列表里，每家店都挂着一块信息牌：店名告诉你它是谁，图文简介告诉你它值不值得吃，点单表单告诉你该怎么下单。MCP 的每个工具也有一块“信息牌”，由三个字段构成：name、description、inputSchema。

name 是工具在 Server 内的唯一标识，也是后续实际调用（tools/call）时指代这个工具的名字。description 是写给大模型看的“简介”——模型在几十个工具里做选择时，主要靠 description 判断哪个匹配当前任务。inputSchema 用 JSON Schema 描述参数结构：有哪些字段、哪些必填、每个字段什么类型。它相当于“点单表单”，Agent 依据它生成合法入参。

这三个字段缺一不可：名字写错，调用找不到工具；描述写糊，模型选错工具；参数模式写漏，调用直接出错。它们共同构成 Agent 对一件工具的完整认知：是什么、何时用、怎么用——这也是“工具发现”真正发现的东西。

$$\displaystyle \text{Tool} = \langle \text{name},\ \text{description},\ \text{inputSchema} \rangle$$

1. name 唯一标识：工具名在 Server 作用域内唯一，调用时通过它路由到具体实现。

$$\text{name} \in \text{String}, \ \text{Server 内唯一}$$

2. description 语义匹配：用自然语言描述工具用途，是大模型做工具选择的依据。

$$\text{description}: \text{说明使用场景与功能}$$

3. inputSchema 参数模板：以 JSON Schema 描述入参结构，Agent 据此生成合法参数。

$$\text{inputSchema}: \text{JSON Schema 对象}$$

菜单写得好不好吃，直接决定美食博主会不会点这道菜——工具的“信息牌”质量，直接决定 Agent 选得对不对、调得顺不顺。给工具写 description，就像给招牌菜写诱人的介绍，多写一句“适合深夜加班的人”，就多一次被选中的机会。

版本兼容

老版本外卖 App 遇到新开业的餐厅，会出现什么情况？新店招牌上有“AR 实景选座”这类新玩法，老 App 里根本不显示这个入口，但基础的点餐功能照常能用。MCP 的版本兼容处理，就是这个道理的协议版。

MCP 会话开始时，双方先通过 initialize 消息握手：客户端和服务端各自报上支持的协议版本（protocolVersion）和能力集（capabilities）。能力集就像各自支持的“功能开关列表”。协商的结果是取交集：两边都懂的功能才启用，有一边不懂的就先不用。这种“向下兼容、能力裁剪”的策略，避免了“版本不一致就崩溃”的尴尬。

更难得的是，MCP 遵循 JSON-RPC 的“忽略未知字段”惯例：老版本客户端收到新 Server 返回的、自己不认识的新字段时，会选择忽略而不是报错。这意味着新老版本可以共存——老客户端不会因为多看了几个新字段而当场“晕倒”，新 Server 也不必拒绝服务老客户。

$$\displaystyle \{\text{protocolVersion},\ \text{capabilities}\}_C \leftrightarrow \{\text{protocolVersion},\ \text{capabilities}\}_S$$

1. 版本号互换：双方在 initialize 中交换各自支持的协议版本，像交换名片一样互相摸底。

$$\text{protocolVersion}_C \ vs \ \text{protocolVersion}_S$$

2. 能力求交集：capabilities 声明支持的特性集合，协商后取交集作为实际可用范围。

$$\text{可用能力} = \text{capabilities}_C \cap \text{capabilities}_S$$

3. 未知字段忽略：低版本端遇到不认识的新字段直接跳过，保证会话不中断。

$$\text{未知字段} \mapsto \text{忽略并继续}$$

版本兼容就像两个口音不同的人用普通话交流：各自收起对方听不懂的方言词，把音量让给彼此能理解的部分。只要“普通话”（协议核心）还在，饭局就不会散。

客户端缓存

外卖 App 当然不会每次打开都重新下载整座城市的商家列表——它会缓存在本地，只有地点变化、用户手动下拉或商家营业状态变化时才重新拉取。MCP 客户端对工具列表的处理，遵循同样的智慧。

一次完整的 tools/list 请求-响应是有网络开销的，如果 Agent 每做一个决策都要重新问一遍服务端“你有哪些工具”，那就成了无意义的重复劳动。所以客户端会在一次发现后把工具列表缓存起来，会话内直接复用。这就是“缓存命中”——零请求，直接用。

但缓存必须知道什么时候失效。MCP 提供了 notifications/tools/list_changed 通知：Server 侧工具列表变化时，主动推送一条通知给客户端，客户端收到后立即重新发送 tools/list。这是事件驱动的刷新，比定时轮询更快、更省。如果通知和调用之间存在竞争（比如通知刚发出、调用就已到达），客户端还能用“调用失败后兜底重发现”的策略自愈。

$$\displaystyle \text{命中} \mapsto \text{直接调用}; \quad \text{list\_changed} \mapsto \text{重新 tools/list}; \quad \text{调用失败} \mapsto \text{兜底重发现}$$

1. 缓存命中零请求：会话内已缓存的工具列表直接复用，减少网络往返。

$$\text{cache hit}: \text{无网络请求}$$

2. 通知驱动刷新：Server 通过 list_changed 通知工具变化，客户端收到后重发 tools/list。

$$\text{list\_changed} \Rightarrow \text{tools/list}$$

3. 失败兜底：tools/call 遇到“工具不存在”时，客户端可回退到重新发现再重试。

$$\text{call error} \Rightarrow \text{discover 后重试}$$

缓存是聪明食客的记忆力：记得住常去的店，但店铺改菜单时会收到店家来信（list_changed），点菜时如果发现菜已下架（method not found），也懂得重新翻开菜单再点一遍——既省力气，又不至于吃闭门羹。

同名工具冲突

你所在的城市可能有两家“老王饺子馆”：一家在中山路，一家在建设路。外卖平台不会让它们混为一谈——每个店的条目后面都跟着位置后缀，把“老王饺子馆（中山路店）”与“老王饺子馆（建设路店）”区分开。MCP 生态里的工具名冲突，也需要这种“加后缀”的智慧。

工具 name 只在各自 Server 内唯一。当 Agent 同时连接多个 Server，恰好有两个 Server 都提供了同名工具时，比如文件 Server 和网盘 Server 都有一个 upload，直接按名字调用就会产生歧义。这是所有走向“多 Server 生态”的 Agent 都会撞上的墙。

实践中主流的解决思路有三种：其一是命名空间隔离，客户端维护一张“Server 名 → 工具表”的映射，用 Server 标识加斜杠拼成全局唯一限定名；其二是约定式命名，Server 开发者按领域前缀给工具命名，比如文件服务叫 file_upload、网盘服务叫 drive_upload，从源头规避重名；其三是在日志与提示词中展示完整限定路径，让开发者一眼看出工具来自哪个 Server，排查问题时不会张冠李戴。

$$\displaystyle \text{qualified\_name} = \text{server\_prefix} \ \text{/} \ \text{tool\_name}$$

1. 冲突根源：工具名仅 Server 内唯一，跨 Server 时天然存在重名概率。

$$\text{Server}_A, \text{Server}_B \Rightarrow \text{name}_A = \text{name}_B \ \text{可能}$$

2. 前缀限定隔离：客户端用 Server 标识拼上工具名，构成全局唯一键。

$$\text{qualified} = \text{server} + \text{/} + \text{name}$$

3. 约定去重：开发者遵循“领域前缀 + 动作”的命名规范，降低冲突概率。

$$\text{name} = \text{domain} + \text{\_} + \text{action}$$

有了限定名，Agent 就像拥有精准地址的食客：它要的是“中山路的老王饺子馆”，而不是“建设路的”——同名不再可怕，前缀分隔了世界，工具调用从此精确无误。

AI 应用场景

Python 演示

import jsonimport time  class MockMCPClient:    """模拟 MCP 客户端：动态发现、缓存、冲突处理"""     def __init__(self):        self.cache = {}   # server_url -> {"tools": [...], "ts": 时间戳}        self.version = "2024-11-05"     def send_request(self, server_url, method, params=None):        """模拟 JSON-RPC 请求；真实场景这里会走网络层"""        if method == "tools/list":            return self._fetch_tools(server_url)        raise ValueError("未知方法: " + method)     def _fetch_tools(self, server_url):        """模拟服务端返回的工具清单（含分页游标逻辑）"""        catalog = {            "file://svc": ["file_read", "file_write", "fulltext_search"],            "mail://svc": ["send_mail", "read_inbox"],            "weather://svc": ["get_weather"],        }        names = catalog.get(server_url, [])        tools = []        for name in names:            tools.append({                "name": name,                "description": "提供 " + name + " 能力",                "inputSchema": {                    "type": "object",                    "properties": {"q": {"type": "string"}},                    "required": ["q"],                },            })        return {"tools": tools, "nextCursor": None}     def discover(self, server_url, force=False):        """带缓存的发现：命中 60 秒内的缓存就不发请求"""        now = time.time()        if not force and server_url in self.cache:            entry = self.cache[server_url]            if now - entry["ts"] < 60:                return entry["tools"]        resp = self.send_request(server_url, "tools/list")        self.cache[server_url] = {"tools": resp["tools"], "ts": now}        return resp["tools"]     def on_list_changed(self, server_url):        """服务端通知工具变化：强制刷新缓存"""        return self.discover(server_url, force=True)     def qualified_names(self):        """解决跨 Server 同名冲突：server/tool 限定名"""        result = []        for server_url in ["file://svc", "mail://svc", "weather://svc"]:            prefix = server_url.split("://")[0]            for tool in self.discover(server_url):                result.append(prefix + "/" + tool["name"])        return result  if __name__ == "__main__":    client = MockMCPClient()    first = client.discover("file://svc")    print("首次发现工具数:", len(first))    again = client.discover("file://svc")    print("缓存命中(同一对象):", again is first)    print("list_changed 后刷新:", client.on_list_changed("file://svc"))    for q in client.qualified_names():        print("限定名:", q)

1. self.cache = {}缓存字典，以 Server 地址为键，存放工具列表与时间戳。
2. if method == "tools/list":模拟协议路由，真实场景这里会通过 JSON-RPC 发送网络请求。
3. resp = self.send_request(server_url, "tools/list")核心的发现动作：向服务端请求工具清单。
4. if now - entry["ts"] < 60:缓存命中判断，60 秒内的工具列表直接复用，避免重复网络开销。
5. self.cache[server_url] = {"tools": resp["tools"], "ts": now}把最新工具列表写回缓存。
6. return self.discover(server_url, force=True)收到 list_changed 通知后强制刷新，这是事件驱动的缓存失效。
7. prefix = server_url.split("://")[0]提取服务端前缀（file/mail/weather），用于构造限定名。
8. result.append(prefix + "/" + tool["name"])用“服务端前缀/工具名”解决跨 Server 重名问题。

常见误区

面试题