协议与标准
工具清单（Tool Manifest）
工具清单是对一个工具的结构化描述——它的名称、能做什么、需要什么参数——被放进模型的上下文里，让模型知道有这个工具、该怎么调用它。
模型不可能调用一个它根本不知道存在的工具，也不可能在不知道需要什么参数的情况下正确调用它。工具清单解决的正是这个问题：一份结构化的条目，通常是 JSON 格式，列出工具名称、用自然语言说明这个工具做什么（往往也会说明什么情况下该用它），以及参数的结构。
description 这个字段的重要性经常被低估——模型正是靠这段文字来判断某个工具跟当前请求相不相关，如果描述写得含糊或者容易误导，工具就可能在不该用的时候被用上，或者在真正该用的时候被忽略。
工具清单会在不同规模下出现：可能只是随一次模型 API 调用传进去的一个函数定义，也可能是某个服务端在 MCP 能力协商阶段暴露出来的一整份工具列表。不管哪种情况，形状都是一样的——名称、说明、参数结构——因为这正是模型判断『要不要调用、怎么调用』所需要的最小信息。
举个例子
{
"name": "get_weather",
"description": "获取指定地点当前的天气状况。",
"parameters": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "城市名称，例如「东京」"
}
},
"required": ["location"]
}
}常见误解
常被以为： 工具清单里的 description 只是写给人看的文档。
实际上： 它主要是给模型读的，模型靠这段文字判断某个工具跟当前请求相不相关；描述写得含糊，会直接影响这个工具能不能被正确、可靠地用上。
常被以为： 工具清单必须按某个厂商的私有格式来写。
实际上： 名称、说明、参数结构这个核心形状，在绝大多数工具调用和 MCP 实现里都是一致的，只是具体 JSON 结构可能略有差异。
常见问题
工具清单是什么？
它是对一个工具的结构化描述——名称、功能说明、期望的参数——被放进模型上下文里，让模型判断要不要调用它、怎么调用。
工具的 description 为什么这么重要？
因为模型判断这个工具跟当前请求是否相关，靠的主要就是这段文字而不只是工具名；描述写得不清楚，工具就容易被漏用或者用错。
工具清单和 MCP 服务端的工具列表是一回事吗？
两者关系很紧密——MCP 服务端在能力协商阶段暴露的每个工具，用的基本就是同一种清单结构（名称、说明、参数 schema）。
最近核实： 2026-08-28