{
"name": "get_weather",
"description": "Current weather for a city",
"input_schema": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "City name"
}
},
"required": [
"city"
],
"additionalProperties": false
}
}Ce qu’il fait
Les outils de function-calling et MCP se définissent par un JSON Schema, et les fournisseurs exécutent ce schéma en mode strict : additionalProperties: false sur chaque objet, chaque propriété listée dans required, aucun default, tout typé. Cet outil fait deux choses à ce sujet :
- Construire — renseignez un nom d’outil, une description et des lignes de paramètres ; il génère un schéma conforme au mode strict par construction, en direct, avec un bouton de copie.
- Vérifier — collez une définition d’outil quelconque ; elle est confrontée au contrat du mode strict et chaque violation est listée avec son chemin exact. Un clic applique Auto-strict — les corrections mécaniques — tandis que les noms et les descriptions restent à écrire par vous.
Les règles (le contrat exact que le linter applique)
| Règle | Ce qu’elle vérifie |
|---|---|
non-empty-name |
le nom fait 1–64 caractères de [a-z0-9_-] (la convention get_weather) |
description-present |
l’outil et chaque propriété portent une vraie description |
no-additional-properties |
chaque objet — racine et imbriqué — définit additionalProperties: false |
all-required |
required liste toutes les propriétés, à tous les niveaux |
no-defaults |
aucune clé default — les fournisseurs les rejettent ou les ignorent |
typed-properties |
le type de chaque propriété est l’un de string · number · integer · boolean · object · array |
enum-values |
les enums sont non vides et partagent un seul type primitif |
array-items |
les tableaux déclarent items avec un type |
json-parseable |
l’entrée se parse et input_schema est un objet typé |
Auto-strict corrige no-additional-properties, all-required (y compris les entrées parasites dans required) et no-defaults — récursivement, de façon idempotente. Il n’invente jamais de noms ni de descriptions : c’est sémantique, pas mécanique.
Comment l’utiliser
- Mode Construire : saisissez le nom et la description de l’outil, ajoutez une ligne par paramètre (nom, type, description), puis copiez le schéma généré. Il n’y a volontairement pas d’interrupteur « optionnel » — le mode strict exige chaque propriété dans
required, donc l’optionalité relève de la sémantique de votre modèle, pas du schéma. - Mode Vérifier : collez une définition (essayez les puces — une valide, une cassée). Les problèmes apparaissent avec ids de règle et chemins ; appuyez sur Auto-strict pour corriger les mécaniques ; le schéma corrigé remplace l’entrée pour examen, avec un bouton de copie.
- Pointez votre agent vers la table des règles ci-dessus — c’est la surface de réponse à « pourquoi mon schéma d’outil est-il rejeté ? »
Exemples
Un outil propre — get_weather avec city et un enum unit : zéro problème, se copie tel quel dans la définition d’outils de n’importe quel fournisseur.
Un cassé typique — une description vide, un default, un additionalProperties manquant et un required qui a oublié unit : le linter nomme les six violations ; Auto-strict en corrige trois instantanément ; le reste demande deux phrases de votre part.
Bon à savoir
- 100 % côté client. Rien n’est envoyé nulle part — les schémas peuvent être propriétaires.
- Le mode strict est le choix sûr par défaut : il garantit que les arguments du modèle valident contre votre schéma, ce qui rend un appel d’outil assez digne de confiance pour être exécuté.
- Jumeau Go : les mêmes règles existent en
cosmodev tool-schema-builderdans la CLI (vecteurs de test partagés), pour que les agents fassent le lint localement. - Pourquoi pas de paramètres optionnels ? Les fournisseurs en mode strict exigent chaque propriété dans
required; la convention de l’écosystème est de décrire l’optionalité dans la description et de laisser le modèle omettre les valeurs sémantiquement.