En la definición de una herramienta viven dos clases de problema. La primera es estructural: un tipo que no es un tipo de JSON Schema, un nombre obligatorio que no está entre las propiedades, un array sin items, el modo estricto sin las reglas que el modo estricto impone. Eso se rechaza, normalmente con un mensaje que nombra el campo pero no el motivo. La segunda clase valida perfectamente y causa otro problema: la herramienta se llama en el momento equivocado, o con disparates verosímiles en un argumento, porque nada en el esquema dice qué significa nada. Esto comprueba ambas, informa de cada hallazgo con la ruta de donde salió y acepta la forma que pegues: una herramienta, un array, un fragmento de petición o un esquema suelto.
Características
Acepta una herramienta, un array, un fragmento tools o un esquema suelto
Cada hallazgo lleva la ruta de donde salió
Detecta tipos inválidos, incluso en propiedades individuales
Detecta un nombre obligatorio que no es una propiedad
Aplica las reglas del modo estricto y dice qué propiedades las incumplen
Señala un esquema bajo la clave equivocada
Detecta nombres de herramienta duplicados en un array
Avisa de parámetros sin descripción y de enums vacíos
Cómo usar Verificador de esquemas
Pega la definición, en la forma que la tengas
Lee los hallazgos junto a sus rutas
Corrige primero los errores y luego las descripciones
Vuelve a comprobar hasta que no quede nada
Ejemplo
Entrada
"required": ["email", "customer_id"]
Salida
Error: “customer_id” is required but is not among the properties
Un nombre obligatorio sin propiedad correspondiente se rechaza sin más.
Errores comunes y solución de problemas
La API rechaza la herramienta sin nombrar ningún campo. — Pégala aquí: los hallazgos llevan ruta, así que el nodo problemático se nombra en vez de dejarlo para que lo busques.
Dice que mi esquema está bajo la clave equivocada. — La API de mensajes lee input_schema. Las definiciones escritas para otras convenciones suelen usar parameters, que es JSON válido y simplemente no se lee.
El modo estricto falla con un esquema que parece correcto. — Necesita additionalProperties: false y todas las propiedades como obligatorias. Se comprueban ambas cosas y se nombran las propiedades que fallan.
Avisa de descripciones en vez de errores. — Esa es la segunda clase de problema. No impedirán que la herramienta se acepte; son la razón de que se llame con los argumentos equivocados.
Preguntas frecuentes
¿Qué formas puedo pegar?
Un objeto de herramienta, un array de ellos, un fragmento {"tools": [...]} o un esquema de entrada suelto. Un esquema suelto se reconoce y se indica, ya que una herramienta necesita además nombre y descripción.
¿Por qué avisa de descripciones que faltan?
Porque son la causa más habitual de que una herramienta se llame mal, y nunca producen un error. Un parámetro con nombre y sin descripción deja su significado a la deducción a partir del nombre.
¿Comprueba mi esquema contra argumentos reales?
No: comprueba la definición en sí. Si un conjunto concreto de argumentos valida es otra pregunta, y la responde la API cuando haces la llamada.
¿Se admiten los $ref?
Se señalan. Las referencias no se resuelven de forma fiable en esquemas de herramienta, así que una definición que dependa de una suele comportarse distinto de lo que leyó quien la escribió. Poner la definición en línea evita la cuestión.
¿Puedo comprobar varias herramientas a la vez?
Sí, pega el array entero. Se detectan nombres duplicados en el conjunto, un problema que solo aparece al mirar las herramientas juntas.
Herramientas relacionadas
Esquema de herramienta MCP — Define una herramienta y obtén el JSON Schema, con el modo estricto revisado.