В определении инструмента живут два вида проблем. Первый структурный: тип, который не является типом JSON Schema; обязательное имя, которого нет среди свойств; массив без items; строгий режим без правил, которые он налагает. Это отклоняется, обычно с сообщением, называющим поле, но не причину. Второй вид проходит проверку безупречно и создаёт другую беду: инструмент вызывают не вовремя или с правдоподобной чепухой в аргументе, потому что нигде в схеме не сказано, что что означает. Здесь проверяется и то и другое, каждое замечание сопровождается путём, откуда оно взялось, и принимается любая вставленная форма: один инструмент, массив, фрагмент запроса или просто схема.
Возможности
Принимает один инструмент, массив, фрагмент tools или отдельную схему
Каждое замечание несёт путь, откуда оно взялось
Ловит недопустимые типы, в том числе у отдельных свойств
Ловит обязательное имя, которого нет среди свойств
Применяет правила строгого режима и называет нарушающие свойства
Отмечает схему под неверным ключом
Ловит повторяющиеся имена инструментов в массиве
Предупреждает о параметрах без описаний и пустых перечислениях
Как использовать Проверка схемы инструмента
Вставьте определение в той форме, в какой оно у вас есть
Прочтите замечания вместе с путями
Сначала исправьте ошибки, затем описания
Проверяйте снова, пока ничего не останется
Пример
Ввод
"required": ["email", "customer_id"]
Результат
Error: “customer_id” is required but is not among the properties
Обязательное имя без соответствующего свойства отклоняется сразу.
Частые ошибки и устранение неполадок
API отклоняет инструмент, не называя поля. — Вставьте его сюда — замечания несут путь, и проблемный узел называется, а не оставляется на поиски.
Говорит, что схема под неверным ключом. — Messages API читает input_schema. Определения, написанные под другие соглашения, часто используют parameters — это корректный JSON, который просто не читается.
Строгий режим падает на схеме, которая выглядит правильной. — Ему нужны additionalProperties: false и все свойства как обязательные. Проверяется и то и другое, с именами нарушителей.
Выдаёт предупреждения об описаниях, а не ошибки. — Это второй класс проблем. Они не мешают принять инструмент; они и есть причина, по которой его вызывают с неверными аргументами.
Часто задаваемые вопросы
Какие формы можно вставлять?
Объект инструмента, массив таких объектов, фрагмент {"tools": [...]} или отдельную входную схему. Отдельная схема распознаётся и отмечается, поскольку инструменту нужны ещё имя и описание.
Зачем предупреждать об отсутствующих описаниях?
Потому что это самая частая причина неверных вызовов, и она никогда не даёт ошибки. Параметр с именем и без описания оставляет смысл на угадывание по одному имени.
Проверяет ли он схему на настоящих аргументах?
Нет — он проверяет само определение. Пройдёт ли конкретный набор аргументов, это другой вопрос, и на него отвечает API при вызове.
Поддерживаются ли $ref?
Они отмечаются. Ссылки в схемах инструментов разрешаются не всегда надёжно, поэтому определение, опирающееся на них, часто ведёт себя не так, как читал его автор. Встроить определение — снять вопрос.
Можно проверить сразу несколько инструментов?
Да, вставьте весь массив. Повторяющиеся имена в наборе будут пойманы — эта проблема видна только когда смотришь на инструменты вместе.
Связанные инструменты
Схема инструмента MCP — Опишите инструмент и получите JSON Schema с проверкой строгого режима.