Comment la conception du schéma des outils limite-t-elle les actions d’un agent d’IA domestique ?

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

La conception du schéma d’un outil limite un agent IA domestique en restreignant les paramètres et les formes d’action qui peuvent devenir des appels d’outils valides avant leur exécution.

Un modèle peut toujours raisonner de manière incorrecte, mais les champs typés, les cibles obligatoires, les énumérations et la validation réduisent ce que cette erreur peut exprimer avant que les couches d’autorisation et d’approbation ne décident si l’action peut être exécutée.

Un schéma d’outil définit la forme d’une requête autorisée

Un outil d’agent n’est pas seulement un nom et une description. Son schéma définit les champs qui peuvent être fournis, les types qu’ils utilisent et les combinaisons qui sont structurellement acceptables.

La spécification MCP actuelle exige un inputSchema défini avec JSON Schema. Cela fournit à l’environnement d’exécution un contrat lisible par machine, au lieu de reposer uniquement sur le langage naturel. Le Model Context Protocol définit les outils avec un schéma d’entrée, ce qui rend explicite la structure des arguments acceptés avant l’exécution d’un appel d’outil ; voir les schémas d’entrée des outils MCP.

Sur un serveur domestique, cela peut distinguer un outil de redémarrage limité d’un shell administratif vague.

Un appel qui ne peut pas exprimer des commandes arbitraires dispose déjà d’une surface d’action plus réduite.

Les champs obligatoires empêchent les actions incomplètes

Les propriétés obligatoires contraignent le modèle à fournir les informations nécessaires à une opération. Un outil de déplacement de fichiers peut exiger à la fois la source et la destination ; un outil de gestion de conteneurs peut exiger une cible et une action.

MCP suit les sémantiques de validation de JSON Schema, qui prennent en charge les propriétés obligatoires et les contraintes de type. La validation JSON Schema définit les propriétés obligatoires et d’autres assertions structurelles capables de rejeter les requêtes incomplètes, ce qui renforce la couche de contraintes dans le vocabulaire de validation JSON Schema.

Cela évite au code de l’application de deviner les cibles manquantes ou d’hériter de valeurs par défaut dangereuses. L’absence devient une erreur de validation plutôt qu’une action implicite.

Les énumérations et les plages excluent les actions que le modèle ne peut pas exprimer

Un schéma peut limiter un champ à un ensemble énuméré ou à une plage définie. Si l’action autorise uniquement le redémarrage, l’arrêt et le démarrage, la suppression ne peut pas passer par ce champ.

MCP exige que les arguments des outils soient conformes au schéma d’entrée de l’outil. Les contraintes structurelles sont plus strictes qu’une description indiquant simplement ce qui devrait habituellement se produire. Les schémas OpenAPI peuvent exprimer des valeurs énumérées, des limites numériques et des propriétés typées, illustrant comment un outil peut rendre les actions invalides impossibles à représenter grâce aux définitions de schémas OpenAPI.

À domicile, le même mécanisme peut limiter les valeurs du thermostat, le nombre de jours de conservation, les noms de services ou les cibles de sauvegarde afin que le vocabulaire d’action reste explicite.

Les descriptions guident la sélection, mais la validation impose la structure

Les descriptions en langage naturel aident le modèle à choisir un outil et à interpréter les champs, mais elles n’imposent pas la même limite qu’un validateur qui rejette les appels non conformes au contrat.

MCP décrit les descriptions d’outils comme une indication lisible par l’être humain destinée à aider le modèle à les comprendre, tandis que inputSchema fournit le contrat formel des paramètres. L’utilisation d’outils d’Anthropic s’appuie sur des paramètres d’outils déclarés pour guider les appels générés par le modèle, mais ce guidage reste différent de la validation à l’exécution, comme l’expliquent les schémas d’utilisation des outils Anthropic.

Cela distingue ce sujet de l’article de ZimaSpace sur la perte de fiabilité de la sélection des outils lorsqu’ils sont trop nombreux. L’ambiguïté de sélection survient avant le choix d’un outil ; les contraintes du schéma s’appliquent à l’appel candidat lui-même.

La validation du schéma n’accorde pas d’autorisation

Une requête structurellement valide peut néanmoins être non autorisée. Le schéma peut autoriser restart(container=postgres) alors que l’appelant n’est autorisé à redémarrer qu’un conteneur multimédia.

MCP considère l’utilisation des outils comme une interaction avec des systèmes externes et recommande de mettre en place des contrôles de sécurité et d’approbation humaine autour des appels. La conformité au schéma constitue une seule couche et non un système complet de gestion des autorisations. L’appel de fonctions de Google Gemini utilise également des déclarations de fonctions structurées, tandis que l’autorisation reste extérieure au schéma lui-même ; cette séparation est illustrée par les schémas d’appel de fonctions Gemini.

Cette limite rejoint l’article de ZimaSpace sur les limites de portée des outils pour les agents IA domestiques : le schéma contraint les paramètres représentables, tandis que la portée et les capacités déterminent quelles opérations valides sont effectivement autorisées.

Les schémas plus petits sont plus faciles à tester et à auditer

Un outil étendu comportant de nombreux champs facultatifs crée de nombreuses combinaisons valides.

La réduction du nombre d’outils diminue le nombre de comportements que l’évaluation doit couvrir.

JSON Schema prend en charge les propriétés d’objet, les membres obligatoires et le contrôle des propriétés supplémentaires, ce qui permet de rejeter les champs inattendus au lieu de les accepter silencieusement. Pydantic peut générer des schémas lisibles par machine à partir de modèles typés, illustrant pourquoi les schémas plus petits et explicites sont plus faciles à valider et à tester grâce à la génération de schémas JSON de Pydantic.

Les tests peuvent alors énumérer les actions autorisées, les combinaisons invalides, les valeurs limites et le comportement de rejet avant que le modèle ne soit connecté à des fichiers, des conteneurs, des appareils ou des systèmes de sauvegarde.

Centre Tech & IA

Plus à lire

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.