Aller plus loin

Un schéma est un prompt

Le modèle lit la définition de l’outil pour décider quand et comment l’appeler. Le nom, la description et chaque description de paramètre agissent comme des instructions, et les améliorer aide souvent plus que réécrire le prompt système.

{
  "name": "refund_order",
  "description": "Refund a delivered order. Use only after checking the policy.",
  "input_schema": {
    "type": "object",
    "properties": {
      "order_id": { "type": "string", "description": "Format: ORD-1234" },
      "amount": { "type": "number", "exclusiveMinimum": 0 }
    },
    "required": ["order_id", "amount"]
  }
}

Un schéma n’exprime pas tout. Il ne dira pas que la commande 4512 appartient à ce client, ni que le montant correspond à la commande. Ces contrôles se font dans votre code, côté serveur. Même quand un fournisseur impose le schéma, traitez les arguments comme des entrées non fiables.

Plusieurs appels en un tour

Un modèle peut demander plusieurs outils d’un coup. Tous les résultats repartent alors dans le message suivant, chacun relié à sa demande par un identifiant. Les exécuter en parallèle fait gagner du temps quand ils ne font que lire. Quand ils écrivent, l’ordre compte : le choix sûr est de les enchaîner, ou de désactiver les appels parallèles.

Les erreurs s’adressent au modèle

« 500 Internal Server Error » n’apprend rien à un modèle. « Commande ORD-99 introuvable. Les identifiants ressemblent à ORD-1234 » lui permet de se rattraper seul. Renvoyez les échecs comme des résultats d’outil marqués en erreur, et gardez les traces de pile dans vos journaux.

Une reprise paie deux fois

Un délai réseau dépassé ne dit pas si l’action a eu lieu. La reprise peut donc la répéter. Une clé d’idempotence règle le problème : l’appelant génère une clé par action voulue, et le serveur renvoie le premier résultat s’il revoit cette clé. Faites créer la clé par votre code, pas par le modèle : il pourrait en produire une nouvelle à chaque tentative, ce qui annulerait tout l’intérêt.

MCP sous le capot

MCP, c’est du JSON-RPC 2.0 sur un transport : stdio pour un processus local, Streamable HTTP pour un serveur distant. Une session commence par un échange initialize, où chaque côté annonce ce qu’il sait faire. Un serveur peut ensuite exposer trois primitives : les outils appelés par le modèle, les ressources lues par l’application, et les prompts choisis par l’utilisateur.

→ {"jsonrpc":"2.0","id":2,"method":"tools/call",
   "params":{"name":"get_order","arguments":{"id":4512}}}
← {"jsonrpc":"2.0","id":2,
   "result":{"content":[{"type":"text","text":"{\"total\":89}"}]}}

Notez les deux niveaux d’échec. Un problème de protocole, comme une méthode inconnue, est une erreur JSON-RPC. Un outil qui échoue donne un résultat normal avec isError: true, pour que le modèle puisse le lire.