Pourquoi le registre ne peut pas être juste un catalogue

Une liste d'outils peut indiquer à un modèle qu'une fonction de recherche existe. Il ne peut pas dire au moteur d'exécution si la recherche envoie des données en dehors du périphérique, si le résultat est en lecture seule, ou si le budget des tâches permet l'appel.

Une carte de capacité ajoute ces propriétés et transforme un outil en option d'exécution régie.

Les domaines qui comptent d'abord

Ces champs permettent au système de filtrer les candidats avant les plans du modèle. Ils font aussi les choix du plan , expliqués à l'utilisateur.

  • Schéma d'entrée et de sortie.
  • Effet secondaire : lecture seule, écriture locale, envoi externe, paiement ou irréversible.
  • Limite des données : si les données peuvent quitter l'appareil et vers quelle destination approuvée.
  • Attentes en matière de coûts et de latence.
  • Délais, politique de réessayer, santé et politique de confirmation.

Un contrat entre différents protocoles

MCP, OpenAPI, CLI et les adaptateurs locaux exposent les capacités dans différents formats. La couche d'adaptateur les normalise dans un contrat de capacité commune de sorte que le moteur d'exécution n'a pas besoin de comprendre chaque protocole directement.

Cette séparation permet à l'écosystème de l'outil d'évoluer sans permettre aux détails du protocole de contourner la gouvernance.

La carte est également une unité d'audit

Lorsqu'une capacité est invoquée, l'événement d'exécution peut référencer sa carte, sa version, ses paramètres, son coût, sa destination et son résultat. L'examen ultérieur peut relier la sortie aux conditions dans lesquelles elle a été produite.

C'est la différence entre un appel d'outils et une invocation de capacité régie.