Une définition d'outil a deux missions, et une seule est du JSON. Le schéma dit quelle forme prennent les arguments ; les descriptions disent à quoi sert l'outil et ce que signifie chaque argument. Un schéma peut être parfaitement valide et produire malgré tout un outil appelé au mauvais moment avec des absurdités plausibles dedans, parce que rien dans le JSON n'explique ce qu'est quoi. Ce créateur écrit le schéma et vérifie les deux moitiés : la structure, et si quoi que ce soit est réellement décrit. Le mode strict est également traité comme il se doit : il exige que chaque propriété figure comme requise et interdit les propriétés supplémentaires, ce qui surprend car le schéma est sinon inchangé.
Fonctionnalités
Paramètres avec types, descriptions et ensembles de valeurs fermés facultatifs
La règle « tout requis » du mode strict appliquée, non découverte plus tard
additionalProperties correctement posé quand le mode strict est actif
Les tableaux reçoivent automatiquement un schéma items
Avertit sur un paramètre sans description
Attrape les noms de paramètre en double
Note un énuméré à valeur unique, qui est une constante
Produit la définition entière, pas seulement le schéma
Comment utiliser Schéma d'outil MCP
Nommez l’outil et décrivez quand l’utiliser
Ajoutez chaque paramètre avec son type et une description
Marquez les requis, ou activez le mode strict
Copiez la définition dans votre tableau d’outils
Exemple
Entrée
"strict": true
Sortie
Error: strict mode requires every property to be listed as required
Le mode strict n’admet pas de propriétés facultatives : autorisez null à la place.
Erreurs courantes et dépannage
Le mode strict est refusé. — Il exige toutes les propriétés requises et additionalProperties à false. Marquez les facultatives comme requises en autorisant null, ou désactivez le mode strict.
L’outil est appelé avec de mauvais arguments. — Souvent des paramètres sans description. Un nom seul laisse le sens à la déduction, et « id » pourrait être n’importe quoi.
L’outil est appelé au mauvais moment. — C’est la description de l’outil, pas le schéma. Dites quand y recourir et ce qu’il renvoie, pas seulement ce qu’il fait.
Un paramètre tableau est refusé. — Les tableaux ont besoin d’un schéma items disant ce qu’ils contiennent. Il est ajouté automatiquement ici.
Foire aux questions
Que change réellement le mode strict ?
Il garantit que les arguments valident exactement contre le schéma. Le prix : chaque propriété doit figurer comme requise et aucune propriété supplémentaire n’est admise, donc un argument vraiment facultatif doit être modélisé comme requis mais annulable.
Quel niveau de détail pour une description de paramètre ?
Assez pour qu’une personne lisant seulement le schéma sache quoi mettre : le format, les unités, d’où vient la valeur. « L’adresse courriel du client sous laquelle la commande a été passée » vaut bien plus que « courriel ».
Quand utiliser un énuméré ?
Quand l’ensemble des valeurs valides est réellement fermé et court. Cela élimine toute une classe de réponses fausses. Un énuméré à valeur unique est signalé parce que c’est une constante.
Cela vaut-il pour les outils MCP et API ?
Le schéma est le même sous-ensemble de JSON Schema dans les deux cas. L’enveloppe diffère un peu, mais le schéma d’entrée — la partie facile à rater — est identique.
Qu’est-ce qu’une bonne description d’outil ?
Trois choses en deux phrases : ce qu’il fait, quand y recourir, ce qu’il renvoie. La dernière est la plus souvent omise et la plus utile, car elle dit si un seul appel suffira.
Outils associés
Vérificateur de schéma — Collez une définition et découvrez pourquoi elle est rejetée ou mal appelée.