注册 MCP 工具 JSON Schema 时,模型如何获得结构化工具信息?
未标记
考查重点:工具发现与模型输入构造。Server 发布工具定义,Client 列举发现,Host 转成模型可读工具输入;模型生成调用后仍由运行时校验并执行
本题目录
参考答案
核心回答
模型获得 MCP 工具信息,要经过 Server 提供定义、Client 发现、Host 适配并传给模型 这条链路:
- Server 定义工具的名称、用途和
inputSchema,其中JSON Schema描述参数类型、必填项和取值约束。 - Host 中的
MCPClient 通过tools/list获取当前可用工具;Host 选择本次允许使用的工具,并适配成模型接口支持的工具定义格式。 - Host 调用模型时,把用户请求、必要上下文和工具定义一起提供。模型据此选择工具并生成结构化名称与参数;这些信息进入的是本次推理输入,不是模型权重。
- Host 解析、校验并路由调用,由 Client 发出
tools/call,Server 执行后返回结果,再由 Host 作为对应工具结果交回模型。
所以 MCP 的 inputSchema 和模型接口的工具字段分属不同接口,中间需要宿主适配;模型输出了工具调用,也还没有执行工具。
展开说明
1. Server 注册的是可发现的能力描述
例如天气服务可以暴露以下工具定义,示例只展示工具对象:
{
"name": "get_weather",
"description": "查询指定城市当前天气",
"inputSchema": {
"type": "object",
"properties": {
"city": { "type": "string", "description": "需要查询的城市" }
},
"required": ["city"]
}
}
description 帮助模型判断什么时候使用,inputSchema 说明怎样填写参数。工具的实际查询逻辑和凭据留在 Server 侧,工具发现不需要把函数源码或密钥发给模型。
支持工具的 Server 要响应 tools/list,返回当前请求方可用的工具集合。列表可能分页,也可能随权限和服务配置变化;Client 不能只取第一页就认为已经发现全部工具。服务支持 Tools 是能力声明,具体有哪些工具则由工具列表给出。
2. Host 怎样把定义变成模型输入
Host 可以先把多个 Server 的工具收进统一注册表,再按用户权限和当前任务选择候选工具。面对很多工具时,可以先发现相关工具,再加载其完整定义,减少上下文负担;候选筛选也需要保留歧义处理或补充发现路径。
支持原生工具调用的模型接口通常有专门的工具定义字段,Host 将名称、描述和参数 Schema 映射到该接口要求的结构。模型平台再按自己的输入表示处理这些定义;具体聊天模板、序列化和约束解码方式取决于模型服务,MCP 不规定它们必须怎样实现。
如果宿主采用提示词加解析器,也可以把工具说明序列化进提示词,但这是一种适配方式。能否生成可用的结构化调用,取决于模型、模板和解析校验,不能把“把 JSON 放进 Prompt”直接等同于完整的原生工具接口。
3. 模型选中工具以后,程序怎样执行
用户问“上海现在天气怎样”,模型看到天气工具的用途和参数定义后,可以返回调用 get_weather、参数为 city=上海 的结构化提案。Host 检查工具是否已登记、参数是否满足 Schema 和业务条件、当前用户是否允许调用,再查找对应 Server。
Client 随后通过 MCP tools/call 发送工具名和 arguments,Server 校验并执行天气查询。结果经 Client 回到 Host,Host 按模型接口的调用关联标识组织工具结果,再让模型生成回答或继续决策。
这里有两种不同的关联:MCP 请求 ID 对应一次协议请求与响应,模型工具调用 ID 对应模型侧的调用与结果。适配层应保留映射,不能因为它们都是 ID 就混用。工具出错也应作为可识别的错误反馈,不能当作成功的天气数据。
4. Schema 正确与选对工具是两件事
Schema 可以约束字段结构,但无法独自判断城市是否理解正确、工具是否适合当前任务,或返回的数据是否新鲜。Host 和 Server 仍需执行参数和业务校验;是否支持某种 JSON Schema 关键字,也要看模型接口及适配器的能力。
工具命名和描述应清楚区分适用场景。多个 Server 都有 search 时,Host 可以给模型侧名称增加稳定的命名空间,并保存它到原 Server、原工具名的映射。模型使用适配后的名称,真正发出 MCP 调用时再正确还原。
常见追问
配置 MCP 后,模型为什么仍然看不到工具?
按链路定位:服务是否可达,Client 是否成功取得工具列表,分页和权限是否正确,Host 是否把工具纳入当前候选,Schema 是否被适配器接受,以及本次模型请求是否真正携带了工具定义。仅在应用配置中写了一个 Server 地址,还没有完成模型侧的工具输入。
工具列表会一直不变吗?
不一定。宿主可以按协议缓存规则和授权范围复用列表,在需要时重新获取;支持工具变更通知的双方还可以订阅相应更新。工具列表、模型侧定义与实际执行路由应保持一致,避免模型按旧参数生成调用。
完整流程是否必须先发 initialize?
要看协议 revision。按当前 2026-07-28 规范,请求自带协议版本和客户端能力,不再要求旧版的 initialize/initialized 握手;server/discover 可用于发现服务能力,但调用它不是获取工具列表的强制前置。使用旧 revision 的兼容实现仍可能有初始化握手,具体工具定义依然需要通过工具发现获得。
对应教程
- MCP 模型上下文协议:阅读 Host、Client、Server,以及工具发现、模型决策和结果反馈的分工;新版请求流程可结合官方 2026-07-28 规范继续对照。
参考资料
- 国内:JavaGuide:MCP 与 Function Calling 的关系:依据 Host、Client 与 Server 的职责,解释正文中工具定义如何经宿主适配进入模型输入,再路由到实际执行。
- 国内:WeThinkIn:函数调用的执行链路与 Schema:采用模型生成调用提案、宿主校验执行和回填结果的分工,说明正文中结构约束、业务判断与执行权的边界。
- 国内:Datawhale:智能体通信协议中的工具选择流程:借鉴发现、上下文构建、选择、执行和反馈的分层,说明正文中宿主如何连接 MCP 与模型接口。
- 国外:MCP:2026-07-28 Tools 规范:依据
tools/list、inputSchema、分页和tools/call约定,解释正文中工具定义与真实调用分别交换的内容,以及同名工具的处理。 - 国外:MCP:2026-07-28 架构说明:依据应用聚合工具、拦截调用和回填结果的过程,说明正文中 MCP 为何不规定模型内部工具输入格式。


