Suivre les changements incompatibles des serveurs MCP

Un serveur MCP est une API dont le principal consommateur est un modèle de langage. Cela rend les changements incompatibles plus étranges qu’à l’habitude : un client ne lève jamais d’erreur de type, le modèle se met simplement à appeler un outil un peu de travers.

Pourquoi la dérive de schéma passe facilement inaperçue

L’auteur d’un serveur renomme un paramètre de query en search_text, ou rend un champ optionnel obligatoire. Rien n’échoue au déploiement. La liste des outils est récupérée à l’exécution, donc chaque client récupère le nouveau schéma à sa prochaine connexion. Des agents qui fonctionnaient hier passent maintenant les anciens noms d’arguments et reçoivent des erreurs de validation, ou pire, voient leurs entrées ignorées sans bruit.

Trois types de changement nous ont régulièrement posé problème :

• Un outil a été renommé ou supprimé.
• Un paramètre a changé de type, ou est devenu obligatoire.
• Une description a changé suffisamment pour modifier le moment où un modèle choisit l’outil.

Ce que Proxar compare

Proxar capture la réponse tools/list de chaque serveur devant lequel il se place et la stocke avec un hachage de son contenu. Quand le hachage change, il compare les deux captures outil par outil.

{
  "name": "search_issues",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string" },
      "limit": { "type": "integer" }
    },
    "required": ["query"]
  }
}

La comparaison parcourt le JSON Schema de chaque outil, pas le texte brut, de sorte que réordonner des clés ou reformater ne compte jamais comme un changement.

Décider de ce qui est incompatible

Nous appliquons un jeu de règles volontairement prudent, dans le même esprit que le versionnage sémantique des bibliothèques.

Incompatible

Supprimer un outil, supprimer un paramètre, ajouter un paramètre obligatoire, restreindre un type (par exemple de string à une énumération), ou durcir une contrainte comme maxLength.

Compatible

Ajouter un outil, ajouter un paramètre optionnel, élargir un type, ou assouplir une contrainte.

Nécessite un humain

Les changements de description. Nous ne pouvons pas savoir si une description reformulée modifie le comportement du modèle, donc Proxar la signale comme un avis plutôt que comme une rupture et affiche l’ancien et le nouveau texte côte à côte.

Ce qu’il fait du résultat

Une différence incompatible ne bloque pas le trafic par défaut. Elle déclenche une alerte indiquant le chemin exact qui a changé, par exemple search_issues.inputSchema.required, et vous pouvez choisir d’épingler la capture précédente le temps de mettre vos agents à jour.

# compare the pinned snapshot with what the server reports now
proxar diff --server issues-mcp --against pinned

Ce que nous n’arrivons toujours pas à faire

Les changements sémantiques derrière un schéma inchangé nous sont invisibles. Si un outil se met à renvoyer des résultats triés différemment, le schéma est identique et la différence est vide. Nous préférons le dire plutôt que de prétendre qu’une vérification de schéma couvre ce cas. L’échantillonnage des réponses est dans notre liste, et nous en parlerons quand cela fonctionnera.