Quand le client refuse de se connecter
Chaque refus, ce qu’il veut dire au juste, et le geste qu’il réclame, y compris la négociation de version qu’un client réel était seul à pouvoir trouver.
Livré dans la construction courante. Vous pouvez le faire sur votre machine aujourd’hui.
L’essentiel de ce qui ressemble ici à une panne est un refus, et un refus nomme son geste. La table sépare les deux.
| Ce que vous voyez | Ce que cela veut dire | Quoi faire |
|---|---|---|
| La version de protocole du serveur n’est pas prise en charge | Le client et le serveur ne se sont pas entendus sur une révision du protocole. MCP se négocie : le client annonce sa version, et le serveur répond avec celle-là s’il la parle. | Mettez Deskworth à jour. Depuis le 0.0.24 le serveur parle quatre révisions et reflète celle du client quand il la connaît. |
| Deskworth ne tourne pas, ouvrez l’application, puis réessayez | Le serveur a démarré, et l’application est fermée. Le serveur est une façade mince ; le travail se fait dans l’application. | Ouvrez Deskworth, puis demandez au client de se reconnecter. |
| La déclaration existe et rien n’est connecté | Déclarer un serveur ne s’y connecte pas. L’état vient d’une vraie poignée de main. | Vérifiez le chemin du binaire dans la déclaration, le client le lance, donc une application déplacée le casse. |
| Connecté, et aucun outil | La poignée de main a réussi, la surface non. | Vérifiez que le binaire vient d’une construction 0.0.24 ou plus récente ; la surface externe n’existe pas avant. |
| Un outil répond par une erreur au lieu d’échouer | C’est un outil qui refuse en donnant sa raison, pas un serveur cassé, le protocole sépare les deux à dessein. | Lisez la raison. Elle est écrite pour qu’on agisse dessus. |
#La négociation, et pourquoi aucun test ne l’a trouvée
Le premier client réel a refusé de se connecter. Le serveur annonçait la révision la plus récente qu’il connaissait et l’exigeait ; le client en demandait une plus ancienne et s’arrêtait là. Rien dans la suite n’aurait pu l’attraper : le serveur était cohérent avec lui-même, et c’est le client qui décide.
La correction est ce que le protocole disait depuis toujours : une version se négocie, elle ne s’impose pas. Le serveur parle désormais quatre révisions, propose la plus récente par défaut, et répond avec celle du client quand il la reconnaît. Voilà la différence entre « couvert par des tests » et « exercé par un client réel », et voilà pourquoi ce site tient ces deux mots séparés partout ailleurs.
PreuveSi votre client signale un désaccord de version, l’information utile est la version qu’il a demandée. C’est celle que le serveur doit parler, et ajouter une révision à la liste est un changement plus court qu’il n’en a l’air.
#Lire le processus vous-même
- Le serveur est un sous-processus ordinaire : votre client l’a lancé, et il s’arrête quand son entrée se ferme.
- Seuls les messages de protocole vont sur la sortie standard. Tout ce que le serveur a à dire pour lui-même va sur la sortie d’erreur, où votre client l’affiche d’ordinaire.
- Une seule ligne illisible n’abat pas la session, elle reçoit une réponse et la boucle continue.
#Sources
- Deskworth OS, product state at 0.0.24, providers and MCPDeskworthDocument interne, non publié
- The external MCP surface, mirrored on this siteDeskworthDocument interne, non publié
- Model Context Protocol, stdio transportModel Context Protocol projecthttps://modelcontextprotocol.io/specification/2026-07-28/basic/transports/stdio
- Connect Claude Code to tools via MCPAnthropichttps://code.claude.com/docs/en/mcp