Interfaces d’outils pour les agents AI : MCP, function calling, CLI, Skills

Traduction automatique Cet article a été traduit automatiquement depuis la version originale en anglais.

Utilisez le function calling lorsqu’une application expose un petit ensemble d’outils typés à une seule API de modèle. Utilisez le Model Context Protocol (MCP) lorsque plusieurs clients compatibles doivent découvrir et appeler un serveur réutilisable. Utilisez une CLI lorsqu’une commande stable existe déjà et que le texte ou les fichiers constituent une frontière acceptable. Utilisez un skill lorsque des instructions, des scripts et des références réutilisables doivent apprendre à un agent à exécuter un workflow.

Ces interfaces peuvent être combinées. Un skill peut indiquer à un agent quand appeler un outil MCP, un serveur MCP peut encapsuler une CLI et un modèle peut sélectionner l’appel via le function calling. La frontière de sécurité relève toujours du harness et du runtime, et non de la description de l’interface.

Dernière révision : 2026-08-10. Cette comparaison privilégie la clarté des schémas, la réutilisation entre clients, le coût du transport et du déploiement, le principe du moindre privilège, l’observabilité et la responsabilité de maintenance.

Tableau de décision

BesoinMeilleur point de départPrincipale précaution
Petit ensemble d’outils typés dans une applicationFunction callingUn schéma valide n’autorise pas l’action et ne garantit pas la sécurité des arguments.
Outils réutilisables entre clients compatiblesOutils MCPL’identité du serveur, les identifiants, les modifications des outils et le contenu renvoyé nécessitent des contrôles distincts.
Commande existante pour les développeurs ou les opérationsCLIL’analyse du texte, l’injection shell, l’état de l’environnement et des identifiants trop larges peuvent fragiliser la frontière.
Instructions et ressources de workflow réutilisablesAgent SkillsLes instructions peuvent guider l’utilisation des outils, mais ne fournissent ni transport ni frontière de permissions.
Logique stable en processusAPI de fonction ou de bibliothèque typéeN’ajoutez pas de protocole lorsqu’une même base de code contrôle les deux côtés.

Function calling

Le function calling fournit au modèle des opérations nommées avec des arguments structurés. Il convient à un harness géré par le produit, dans lequel les outils, les contrôles de policy, les identifiants et l’exécution résident dans une seule application. Gardez les schémas étroits, validez chaque argument et évaluez à la fois la sélection de l’outil et l’effet de bord qui en résulte.

MCP

MCP sépare les clients des serveurs réutilisables et standardise la découverte et l’invocation. Il est utile lorsqu’une même intégration doit fonctionner avec plusieurs agents ou applications compatibles. MCP ne décide pas si un tool call est autorisé. Authentifiez le serveur, limitez les tokens, examinez les modifications des définitions d’outils, isolez les serveurs non fiables et traitez les résultats comme des entrées non fiables.

Outils CLI

Une CLI constitue souvent le chemin le plus court vers des fonctionnalités matures telles que Git, les gestionnaires de paquets, les outils cloud et les systèmes de build. Préférez les sorties structurées, les répertoires de travail explicites, les flags non interactifs, des timeouts plafonnés et des identifiants limités au strict nécessaire. Évitez de construire des chaînes shell à partir de texte non fiable.

Skills

Un skill regroupe des instructions procédurales et peut inclure des scripts, des références ou des templates. Il est utile lorsque la difficulté principale consiste à connaître le workflow, plutôt qu’à créer un nouvel outil distant. Gardez le skill suffisamment petit pour être révisé, figez les hypothèses externes et rendez explicites les actions destructrices ou externes.

Checklist de sélection

  • Qui possède le client, l’interface et l’implémentation ?
  • Plusieurs clients doivent-ils le réutiliser ?
  • Le schéma d’entrée est-il étroit et versionné ?
  • Où l’autorisation et l’approbation sont-elles appliquées ?
  • Du contenu non fiable peut-il atteindre les identifiants ou la sortie réseau ?
  • Les appels, arguments, résultats et décisions de policy sont-ils traçables ?
  • Un appel à une bibliothèque typée peut-il résoudre le problème avec une surface d’attaque moindre ?

Pour aller plus loin

Références