Deux sortes de problèmes vivent dans une définition d'outil. La première est structurelle : un type qui n'est pas un type JSON Schema, un nom requis absent des propriétés, un tableau sans items, le mode strict sans les règles qu'il impose. Cela est refusé, généralement avec un message qui nomme le champ mais pas la raison. La seconde sorte valide parfaitement et cause un autre problème : l'outil est appelé au mauvais moment, ou avec des absurdités plausibles dans un argument, parce que rien dans le schéma ne dit ce que signifie quoi que ce soit. Les deux sont vérifiées ici, chaque constat est rapporté au chemin dont il provient, et toute forme collée est acceptée : un outil, un tableau, un fragment de requête ou un schéma seul.
Fonctionnalités
Accepte un outil, un tableau, un fragment tools ou un schéma seul
Chaque constat porte le chemin dont il provient
Attrape les types invalides, y compris sur des propriétés isolées
Attrape un nom requis qui n’est pas une propriété
Applique les règles du mode strict et nomme les propriétés fautives
Signale un schéma sous la mauvaise clé
Attrape les noms d’outils en double dans un tableau
Avertit sur les paramètres sans description et les énumérés vides
Comment utiliser Vérificateur de schéma
Collez la définition, dans la forme dont vous disposez
Lisez les constats et leurs chemins
Corrigez d’abord les erreurs, puis les descriptions
Revérifiez jusqu’à ce qu’il ne reste rien
Exemple
Entrée
"required": ["email", "customer_id"]
Sortie
Error: “customer_id” is required but is not among the properties
Un nom requis sans propriété correspondante est refusé d’emblée.
Erreurs courantes et dépannage
L’API refuse l’outil sans nommer de champ. — Collez-le ici — les constats portent un chemin, le nœud fautif est donc nommé plutôt que laissé à chercher.
Il dit que mon schéma est sous la mauvaise clé. — L’API de messages lit input_schema. Les définitions écrites pour d’autres conventions utilisent souvent parameters, qui est du JSON valide et simplement non lu.
Le mode strict échoue sur un schéma qui semble correct. — Il lui faut additionalProperties : false et toutes les propriétés requises. Les deux sont vérifiés, avec les propriétés fautives nommées.
Il avertit sur des descriptions au lieu d’erreurs. — C’est la seconde classe de problème. Elles n’empêchent pas l’acceptation ; elles expliquent pourquoi l’outil est appelé avec de mauvais arguments.
Foire aux questions
Quelles formes puis-je coller ?
Un objet d’outil, un tableau d’objets, un fragment {"tools": [...]} ou un schéma d’entrée seul. Un schéma seul est reconnu et signalé, puisqu’un outil réclame en plus un nom et une description.
Pourquoi avertir sur les descriptions manquantes ?
Parce qu’elles sont la première cause d’appels erronés et ne produisent jamais d’erreur. Un paramètre nommé sans description laisse son sens à deviner à partir du seul nom.
Vérifie-t-il mon schéma contre de vrais arguments ?
Non — il vérifie la définition elle-même. Savoir si un jeu d’arguments valide est une autre question, à laquelle l’API répond lors de l’appel.
Les $ref sont-ils pris en charge ?
Ils sont signalés. Les références ne sont pas résolues de façon fiable dans les schémas d’outils, donc une définition qui en dépend se comporte souvent autrement que ne l’a lu son auteur. L’intégrer évite la question.
Puis-je vérifier plusieurs outils d’un coup ?
Oui, collez tout le tableau. Les noms en double sont attrapés — un problème qui n’apparaît qu’en regardant les outils ensemble.
Outils associés
Schéma d'outil MCP — Définissez un outil et obtenez le JSON Schema, mode strict vérifié.