Pourquoi le Tool Routing et l'Intent Lock sont-ils importants dans la conception d'un serveur MCP ?

Le Model Context Protocol (MCP) permet à un modèle de langage d'appeler des outils sur des systèmes externes via une interface standard. En pratique, ce n'est pas le protocole lui-même qui est déterminant, mais la conception des outils côté serveur : les noms d'outils, les schémas de paramètres et les messages d'erreur façonnent directement le comportement du modèle.

Lors du test d'un serveur MCP multi-domaine, un problème typique se présente : alors qu'un utilisateur effectue une recherche dans un domaine, le modèle appelle un outil appartenant à un autre domaine en raison d'une similarité de nom ou de paramètre. C'est ce qu'on appelle l'intent drift. Par exemple, la requête d'un utilisateur cherchant un bus interurbain peut être dirigée vers un outil d'affectation de véhicule car l'ensemble des paramètres est similaire. Cela est moins dû à une erreur du modèle qu'à l'ambiguïté de la conception de l'interface.

Qu'est-ce que l'intent lock ? C'est le fait de conserver le domaine actif de la session côté serveur et de vérifier la correspondance avec ce domaine à chaque appel d'outil. Lorsqu'un utilisateur est dans le domaine des bus, un appel à l'outil de location de voiture est rejeté et une erreur explicite est retournée au modèle : le domaine ne correspond pas, appelez d'abord l'outil de changement de domaine. Ainsi, le changement d'intention devient une étape explicite plutôt qu'implicite.

La deuxième ligne de défense est le schéma. Ajouter une information de domaine obligatoire à chaque objet de requête et de réponse oblige le modèle à déclarer à nouveau le contexte dans lequel il opère à chaque appel. Lorsque la déclaration contredit l'état de la session, le serveur arrête l'opération. Cela déplace la validation vers le serveur au lieu de se fier à une règle côté client.

Le troisième point est la discipline de nommage. Utiliser des noms préfixés par le domaine, comme bus_search, flight_search, car_rental_search, au lieu de noms génériques comme effectuer_recherche, rechercher, interroger, augmente la distance entre des outils similaires. Les textes de description doivent être tout aussi clairs ; écrire ce qu'un outil ne fait pas est aussi précieux que d'écrire ce qu'il fait.

Les champs de date et d'heure sont une autre source d'erreurs. Un outil acceptant une date en texte libre peut amener le modèle à produire des formats localisés. Rendre la norme ISO-8601 obligatoire et demander explicitement le fuseau horaire simplifie à la fois la validation et les messages d'erreur. De même, déclarer l'unité dans les champs numériques (nombre de personnes, nombre de nuits, devise) réduit l'ambiguïté.

Côté sécurité, les flux d'authentification OTP ou similaires sont une bonne approche pour les outils qui initient des transactions. Cependant, l'authentification doit être contraignante au niveau de la transaction, pas au niveau de l'outil : les appels de réservation, de paiement ou d'annulation ne doivent pas être acceptés sans un identifiant de session vérifié. Autoriser une action en se fiant au texte généré par le modèle est une faille de sécurité indépendante du protocole.

Les messages d'erreur sont la surface d'apprentissage du modèle. Retourner des erreurs structurées qui indiquent quel champ est manquant et le format attendu, au lieu d'une réponse 400 générique, augmente considérablement la probabilité que le modèle produise le bon appel lors de sa prochaine tentative. De même, les limites de débit et les politiques de nouvelle tentative doivent être documentées ; le modèle ne peut comprendre qu'il doit attendre qu'à partir du texte de l'erreur.

Liste de contrôle rapide pour un tool routing sécurisé : nommage des outils basé sur le domaine, intent lock au niveau de la session, information de domaine obligatoire dans le schéma, validation côté serveur, outil de changement de domaine explicite, format de date ISO-8601, contrôle d'autorisation au niveau de la transaction, messages d'erreur structurés, documentation des limites et des politiques de nouvelle tentative.

Le point commun de ces éléments est de rendre le mauvais comportement impossible côté serveur, au lieu d'espérer que le modèle se comportera correctement. Lors de la conception d'un serveur MCP, la question à se poser est la suivante : quel est l'appel incorrect le plus plausible que le modèle puisse générer, et à quelle couche le système l'arrête-t-il ?