JSON Schema → Tool Use 转换
从 JSON Schema 或手写的参数定义自动生成 Anthropic Claude 的 tool_use、OpenAI 的 function calling 和 Google Gemini 的 function declaration 格式。使用表单 UI 从零开始组建，或粘贴现有 Schema 以同时转换为所有 3 种格式。
完全免费
无需注册
浏览器内完成
5 种语言
深色模式
完整 MCP 服务器:
🧬 MCP 服务器样板 →
使用：放入 SDK 的 tools[] 数组
📖 常见的坑
把 JSON Schema 或手写的参数定义，转换为 Claude 的 tools、OpenAI 的 function calling、Gemini 的 function declarations 各自的格式。处理全部在浏览器内完成。格式对上了，并不意味着模型就会正确调用该工具——决定它调不调用的不是 JSON 结构，而是 description 里写了什么。
| 情形 | 会发生什么 | 怎么处理 |
|---|---|---|
| 模型始终不调用该工具 | 原因是 description 太短，或者只写了「做什么」。仅凭 "获取天气"，模型无法判断何时应当调用。当存在功能相近的多个工具时，它无法区分，于是要么偏向其中一个，要么两个都不调用。参数上的 description 为空，也会造成同样的后果。 |
请在 description 中同时写明「何时使用」与「何时不使用」。例如「当用户询问某个城市的当前天气时使用；历史气象数据与天气预报不要使用本工具（那些请用 get_forecast）」，这种显式划出边界的写法最有效。每个参数也同样处理：不要只写 "date"，而写 "日期，YYYY-MM-DD 格式。例：2026-07-26"。 |
| 参数类型没有被遵守 | 即便写了 "type": "integer"，也可能返回字符串 "3"。数字与字符串的界线、null 的处理、日期格式，仅靠 schema 无法被完全强制。嵌套很深的对象，以及含 oneOf / anyOf 分支的 schema，准确率还会进一步下降。 |
收到的参数请务必在应用侧校验——用 zod、pydantic 之类的校验器过一遍，校验失败时把错误作为工具结果返回给模型。返回「date 必须是 YYYY-MM-DD 格式；收到的是 2026/07/26」，模型就会自行纠正并重新调用。同时请让 schema 保持扁平：嵌套最多两层，复杂分支拆成多个工具——这比任何措辞上的打磨都更能提升准确率。 |
| 工具越多，准确率越低 | 所有工具定义都会包含在每一次请求的输入中。定义 20 个，仅此一项就要多出数千 token 的固定成本；更糟的是，描述越相似，模型的选择就越不稳定。当 get_user、fetch_user、load_user_data 并列时，连人都选不出来。 |
每次请求只传入该场景真正需要的工具。按会话状态或页面切换工具集是可行的做法。名称相近的，请合并，或改名到仅凭名称即可唯一确定用途——像 search_users_by_email 这样把「查什么、怎么查」都写进名字，就不会再冲突。token 用量可用 Token 计数器测量。 |
三家的格式相似，但schema 的嵌套位置不同：Claude 直接放在 input_schema 下，OpenAI 在 function.parameters 下，Gemini 在 functionDeclarations[].parameters 下。此外，Gemini 只支持 JSON Schema 的一部分关键字——$ref、additionalProperties 这类在别家能通过的写法，可能会被丢弃。移植之后，请务必真实调用一次，确认参数如预期送达。「格式被接受」与「行为符合预期」是两件事。
📖 使用方法
-
1
表单 / JSON表单或粘贴 JSON
-
2
选择提供商Anthropic / OpenAI / Gemini
-
3
粘贴到 SDK粘贴到 tools[]
❓ 常见问题
3 种区别？
input_schema / parameters / functionDeclarations
strict？
仅 OpenAI 有 strict
多工具？
一次一个，手动拼接
🐛 此工具出现问题了吗？
免费、无需注册。仅提供复现步骤也有帮助。报告将直接发送给运营者并用于改进。
✅
感谢您的反馈！
已送达运营者,将用于改进工具。