MCP Release QA

Testez le serveur que les utilisateurs vont exécuter. Une revue de schéma ou un test unitaire réussi ne constituent pas une preuve d'exécution.

Cette skill complète la revue de sécurité. Elle se concentre sur le comportement du protocole, la dérive du contrat publié, la justesse du transport et la preuve de livraison reproductible.

Rules

• Exécutez les vérifications sur un processus serveur récent construit à partir de la révision candidate.
• Maintenez initialize, notifications/initialized, discovery et invocation dans la même session. Un nouveau processus est une nouvelle session STDIO.
• Traitez les enregistrements source comme la vérité d'implémentation et la documentation publique comme un contrat qui doit s'y conformer.
• Enregistrez les commandes exactes et les réponses brutes. Ne remplacez pas les preuves manquantes par « semble correct ».
• N'invoquez pas les outils capables de mutation sur des données de production. Utilisez des fixtures, un sandbox, ou arrêtez et nommez l'environnement de test sécurisé manquant.
• Dérivez l'inventaire de capacités attendu de la source candidate à chaque exécution.

1. Establish the release surface

Identifiez :

• le commit candidate et la commande de compilation ;
• le point d'entrée du serveur et le transport : STDIO, Streamable HTTP ou SSE ;
• les versions du protocole MCP supportées ;
• les fichiers source qui enregistrent les tools, resources, templates de ressources et prompts ;
• les catalogues générés, manifests, tableaux README et instructions d'installation ;
• les commandes existantes de protocole, intégration et smoke-test.

Privilégiez les commandes natives du repository. Inspectez package.json, pyproject.toml, Makefile, les workflows CI et les instructions de contribution avant d'inventer un harness de test.

2. Start a clean server

Compilez la candidate et démarrez le point d'entrée documenté avec une configuration sûre pour les tests. Capturez :

• la commande exacte ;
• le SHA du commit ;
• les noms des variables d'environnement, avec les valeurs masquées ;
• stdout, stderr et le code de sortie ;
• l'endpoint ou le transport de processus enfant utilisé par le client.

Pour STDIO, stdout ne contient que le protocole. Les logs, bannières et stack traces doivent aller sur stderr. Pour les transports HTTP, enregistrez le statut, les en-têtes MCP pertinents et la gestion de l'identifiant de session sans imprimer les credentials.

Si le serveur ne peut pas démarrer à partir de ses instructions documentées, signalez cela comme une défaillance de livraison et préservez l'erreur de démarrage mot pour mot.

3. Exercise one complete session

Exécutez cette séquence via un vrai client MCP ou le harness d'intégration du repository :

1. initialize avec une version de protocole que le serveur prétend supporter.
2. Confirmez la version négociée et les capacités annoncées.
3. Envoyez notifications/initialized.
4. Appelez ping.
5. Appelez chaque méthode de discovery supportée :
   • tools/list
   • resources/list
   • resources/templates/list
   • prompts/list
6. Exercez au moins un élément représentatif en lecture seule pour chaque classe de capacité annoncée.
7. Suivez la pagination jusqu'à ce qu'aucun cursor ne reste quand une méthode de liste est paginée.

N'envoyez pas de requêtes post-initialisation via des processus one-shot séparés. Cela teste accidentellement plusieurs sessions incomplètes au lieu d'une session valide.

4. Prove inventory parity

Construisez quatre inventaires à partir de la preuve actuelle :

Comparez par identifiant stable. Signalez :

• les entrées source manquantes à l'exécution ;
• les entrées runtime absentes des métadonnées ou de la documentation ;
• les noms, descriptions, arguments, URIs ou paramètres de prompts obsolètes ;
• les commandes d'installation documentées qui ne démarrent pas le serveur candidate.

Régénérez les fichiers dérivés avec la propre commande de compilation du repository, puis échouez si l'arborescence de travail contient toujours des modifications générées inexpliquées.

5. Check published contracts

Pour chaque élément découvert, vérifiez la définition à l'exécution par rapport à sa source :

Tools

• Le nom et la description sont stables et spécifiques.
• inputSchema définit les types, champs obligatoires, enums et limites le cas échéant.
• Les propriétés inconnues sont rejetées quand le contrat du tool est fermé.
• Les annotations de mutation, idempotence, lecture seule et monde ouvert correspondent au comportement.
• Les appels réussis se conforment à outputSchema quand l'un est publié.
• Les erreurs sont des erreurs de protocole ou des défaillances structurées de tools, non des stack traces échappées.

Resources et templates

• Les URIs et types MIME correspondent aux définitions enregistrées.
• Les resources statiques sont lisibles.
• Les paramètres de template sont validés avant résolution.
• Les resources manquantes ou interdites échouent explicitement.

Prompts

• Les arguments obligatoires et optionnels correspondent à la sortie de discovery.
• prompts/get retourne des messages utilisables pour les arguments valides.
• Les arguments obligatoires manquants et les noms de prompts inconnus échouent explicitement.

6. Test failure paths

Sondez au minimum :

• une requête avant la fin de l'initialisation ;
• du JSON malformé ou une enveloppe JSON-RPC invalide ;
• une méthode inconnue ;
• une version de protocole non supportée ;
• une initialisation répétée ;
• des noms de tools, resources et prompts inconnus ;
• des arguments manquants, supplémentaires, de mauvais type ou hors limites ;
• une requête à la limite de taille de transport documentée et une au-delà ;
• une défaillance interne contrôlée avec credentials et stack traces masquées.

Vérifiez que chaque réponse a le bon ID de requête, un message d'erreur utile et aucun effet secondaire réussi. Pour STDIO, confirmez aussi que chaque ligne stdout est un message de protocole complet et qu'une session saine laisse stderr propre sauf si le serveur documente explicitement une sortie de diagnostic.

7. Smoke-test installation

Quand le projet publie une commande d'installation :

1. Créez une destination temporaire en dehors du checkout source.
2. Exécutez la commande d'installation publique exactement comme documentée.
3. Démarrez l'artefact installé sans vous fier aux fichiers de l'arborescence source.
4. Répétez l'initialisation, discovery et une invocation en lecture seule.
5. Supprimez la destination temporaire après avoir préservé la sortie de commande.

Une chaîne d'installation qui a été seulement inspectée est non vérifiée.

8. Report the evidence

Utilisez ce format :

# MCP Release QA

Candidate: [commit]
Transport: [STDIO | Streamable HTTP | SSE]
Verdict: PASS | PASS WITH CAVEATS | FAIL

## Commands and results
- `[exact command]` — [exit status and result]

## Session transcript
- initialize: [result]
- discovery: [result]
- representative calls: [result]
- negative paths: [result]

## Parity
| Identifier | Source | Runtime | Metadata | Docs | Result |
|---|---|---|---|---|---|

## Findings
| Severity | Evidence | Impact | Narrowest fix |
|---|---|---|---|

## Missing evidence
- [check that could not run and why]

Utilisez FAIL pour un serveur qui ne peut pas démarrer, compléter une session valide, garder le transport analysable ou rejeter proprement les entrées invalides. Utilisez PASS WITH CAVEATS uniquement pour la dérive de documentation ou métadonnées bornée qui ne dénature pas une capacité dangereuse. Sinon utilisez PASS.