Timeout MCP ? Vérifiez l’écriture avant de renvoyer

Pourquoi un timeout ne dit-il pas si le changement a eu lieu ?

Votre IA a demandé à un outil de faire un changement, puis elle a attendu. Aucune réponse n’est venue : votre app d’IA a arrêté d’attendre et a signalé un échec. Cette étiquette décrit l’attente, pas le changement. Renvoyez un changement déjà fait, et vous obtenez deux tickets, deux pages ou deux messages.

Les développeurs appellent un tel changement une écriture. Trois cas sont possibles.

La spécification MCP le prévoit. Un client devrait fixer un timeout sur chaque requête et, une fois ce délai dépassé, interrompre la requête et arrêter d’attendre. Une interruption n’est pas une garantie. Le serveur peut l’ignorer quand le travail est déjà fini ou ne peut pas être arrêté. Elle peut aussi arriver après l’envoi de la réponse.

Le guide de l’API de Stripe dit la même chose : après une coupure de connexion, vous ne savez peut-être pas si la requête a été exécutée. Il demande de considérer aussi une erreur serveur comme un résultat inconnu.

Que faire après un timeout, dans l’ordre ?

Faites ces étapes dans l’ordre. Les deux premières prennent une minute.

1. Arrêtez le renvoiMaintenant

   Demandez à votre IA de ne pas répéter l’appel : « Ne renvoyez pas l’appel. Vérifiez d’abord s’il a été fait. » Un renvoi automatique est justement ce qui fait un changement deux fois.

2. Regardez dans l’outil, pas dans le chat1 minute

   Ouvrez l’outil lui-même : la page Notion, les tickets GitHub, le dossier. Cherchez le titre ou l’identifiant demandé. Le chat sait seulement que l’appel a échoué.

3. Lisez ce que vous trouvez2 minutes

   Trouvé et complet : le changement a été fait. Continuez, sans le refaire.
   Trouvé, à moitié fait : complétez la partie manquante avec une mise à jour, pas avec une nouvelle création.
   Introuvable : il n’est jamais arrivé, ou il tourne encore. Attendez une minute, puis regardez à nouveau.

4. Renvoyez une fois, et seulement un appel sans risqueEnsuite

   S’il manque toujours, renvoyez une fois. Le tableau ci-dessous indique quels appels peuvent être répétés. Avant un envoi, regardez où il atterrit.

5. Si le timeout revient, corrigez la causeAprès

   Un appel qui dépasse toujours a une limite trop courte ou un travail trop gros. Augmentez la limite de ce serveur, ou demandez moins par appel.

Quels appels peuvent être renvoyés sans risque ?

Un appel peut être renvoyé sans risque quand le faire deux fois donne le même résultat qu’une seule fois. Les lectures y répondent. Beaucoup de changements non. La norme HTTP considère PUT (définir une valeur) et DELETE comme pouvant être répétés sans risque, et les lignes ci-dessous la suivent. L’annotation idempotentHint ou la description d’un outil l’emporte sur elles.

Une clé d’idempotence peut-elle empêcher le doublon ?

Parfois. Une clé d’idempotence est une étiquette unique envoyée avec une requête. Si la même étiquette arrive deux fois, le service fait le travail une seule fois et renvoie sa première réponse. Elle sert à une requête restée sans réponse.

• Comment une clé fonctionne chez Stripe. Son API v1 accepte une clé sur les requêtes POST. Elle garde le premier résultat, même une erreur, et le renvoie pour un renvoi avec la même clé. Les clés sont conservées au moins 24 heures. La même clé avec d’autres paramètres est refusée.
• Ce que doit faire un renvoi. Envoyer la même clé et les mêmes paramètres. Stripe demande de ne pas renvoyer avec une nouvelle clé tant que vous ne connaissez pas le premier résultat. Une nouvelle clé à chaque tentative n’apporte aucune protection.
• Ce que MCP vous donne. Une requête tools/call porte un nom d’outil et ses arguments. Le schéma de la spécification ne définit aucune clé d’idempotence pour elle. Un outil peut quand même en accepter une comme argument propre, donc lisez ses arguments.
• Ce qu’un outil peut déclarer. idempotentHint indique que rappeler l’outil avec les mêmes arguments n’a aucun effet supplémentaire. Ce n’est qu’une indication. La spécification dit que les clients ne devraient jamais fonder leurs décisions sur les indications de serveurs auxquels ils ne font pas confiance.

Une clé est donc un plus, pas un plan. Quand l’outil n’en offre aucune, la vérification ci-dessus vous protège.

Comment changer le timeout MCP ?

Une limite trop courte coupe un travail honnête. Une limite trop longue vous fait attendre. Le réglage dépend de votre app d’IA. Voici les réglages de Claude Code.

Le délai de 60 secondes par défaut pour les serveurs distants. Un serveur joint en HTTP, en SSE ou comme connecteur claude.ai a un second minuteur. Il tourne sur chaque requête jusqu’au premier octet de réponse du serveur. Il dure 60 secondes, sauf si MCP_TOOL_TIMEOUT, le timeout du serveur ou MCP_TIMEOUT est réglé plus haut. Les serveurs stdio locaux n’ont pas de minuteur par requête.

Pour le régler pour un seul serveur, ajoutez "timeout": 600000 à son entrée dans .mcp.json. Cela fait dix minutes.

Un appel lent n’est pas toujours un échec. À partir de la version 2.1.212, Claude Code fait passer un appel MCP de la conversation principale en tâche d’arrière-plan au bout de deux minutes. Il livre le résultat quand l’appel se termine.

La documentation MCP de Cursor ne décrit aucun réglage de timeout. La spécification MCP ne fixe aucun chiffre. Elle dit que les SDK devraient permettre de régler les délais par requête, et qu’un client devrait toujours garder un maximum.

Pour un travail qui dure des minutes, un serveur peut utiliser MCP Tasks. Il renvoie tout de suite un identifiant de suivi, et le client interroge le résultat, même après une reconnexion. Les deux côtés doivent le prendre en charge, et le support côté client varie.

Que fait Delta MCP quand une réponse se perd ?

Delta MCP est une app gratuite sur votre ordinateur, entre votre IA et ses outils. Quand un changement ne reçoit aucune réponse, elle ne devine pas et ne renvoie pas à l’aveugle. Elle lit l’outil.

Avant qu’un changement parte, Delta MCP choisit une lecture qui peut montrer si le changement a eu lieu. Cette lecture est l’objet relu, ou une liste relue. Quand aucune réponse ne vient, elle lance cette lecture tout de suite. Ce que montre la lecture décide :

Un appel d’outil déjà passé tel quel ne peut pas être annulé par Delta MCP. Si un appel précédent a réussi, il reste fait, et la réponse le liste pour que votre IA ne le répète pas. Chaque tâche qui change quelque chose est gardée dans Activity, avec chaque changement, avant et après.

Comment une tâche est vérifiée et appliquée