Ce qui se passe réellement
Comprendre l'enchaînement évite les deux tiers des erreurs de diagnostic, parce qu'il permet de savoir à quelle étape regarder.
- Connexion et négociation. Le client et le serveur s'annoncent et conviennent de ce qu'ils savent faire.
- Découverte. Le client demande la liste des outils, ressources et invites. Il obtient noms, descriptions et schémas d'arguments.
- Mise à disposition. Le client transmet cette liste au modèle, dans un format qu'il comprend.
- Décision. Le modèle demande l'appel d'un outil avec des arguments.
- Autorisation. Selon la configuration, l'utilisateur valide, ou la politique décide.
- Exécution. Le serveur exécute et renvoie un résultat, ou une erreur.
- Reprise. Le résultat retourne au modèle, qui poursuit.
Deux points méritent d'être soulignés. Le modèle ne parle jamais directement au serveur : le client est toujours entre les deux, et c'est lui qui applique les autorisations. Et la liste des outils peut changer en cours de session, ce qui explique certains comportements déroutants après une reconnexion.
Les deux modes de transport
Local, par entrée et sortie standard. Le serveur est un processus lancé par le client sur la même machine. Simple, sans réseau, sans port ouvert. L'authentification est celle de l'utilisateur qui lance le processus.
Distant, par HTTP. Le serveur tourne ailleurs et sert plusieurs clients. Il faut alors une authentification explicite, du chiffrement, et une réflexion sur qui accède à quoi.
Le premier mode couvre la majorité des usages individuels. Le second devient nécessaire dès qu'une équipe partage un serveur, et il change la nature du sujet : ce n'est plus un outil personnel, c'est un service exposé.
Ce que voit le modèle, et ce qu'il ne voit pas
Il voit les noms, descriptions et schémas. Il ne voit pas votre code, ni vos journaux, ni ce que l'outil fait réellement.
Conséquence pratique importante : le modèle croit la description. Un outil décrit comme « lit un fichier » et qui en écrit un sera appelé comme une lecture. La description n'est pas de la documentation, c'est le contrat.
Le résultat d'un appel
Renvoyez ce qui est utile au raisonnement, pas un vidage brut.
Trois recommandations concrètes : limitez la taille, car un résultat de dix mille lignes consomme la fenêtre de contexte sans rien apporter ; nommez les champs de façon parlante ; et en cas d'erreur, dites ce qui manque et comment corriger, plutôt qu'un code technique.
Une erreur du type « paramètre date attendu au format AAAA-MM-JJ, reçu 12/03/2026 » permet au modèle de réessayer correctement. Un « Bad Request » le fait abandonner ou boucler.
À retenir
Le client est toujours entre le modèle et le serveur, et c'est lui qui autorise. Transport local pour un usage personnel, HTTP pour un service partagé, ce qui change tout. La description est le contrat que le modèle croit. Et une erreur explicite vaut mille journaux.