Het korte antwoord
Bij een MCP-toolaanroep die een timeout krijgt, kun je niet zien of de wijziging is gebeurd. Je AI kan het antwoord zijn kwijtgeraakt, niet het werk. Controleer voor je opnieuw probeert: kijk in de tool wat die probeerde te maken. Probeer alleen opnieuw als het ontbreekt. Verstuur nooit uit zichzelf opnieuw.
In deze handleiding
Waarom vertelt een timeout niet of de wijziging is gebeurd?
Je AI vroeg een tool om een wijziging te maken en wachtte. Er kwam geen antwoord, dus je AI-app stopte met wachten en meldde een fout. Dat label beschrijft het wachten, niet de wijziging. Probeer je een wijziging die al is gemaakt opnieuw, dan krijg je twee tickets, twee pagina’s of twee berichten.
Ontwikkelaars noemen zo’n wijziging een write. Drie dingen kunnen er gebeurd zijn.
| Wat er gebeurde | Staat de wijziging in de tool? | Als je opnieuw probeert |
|---|---|---|
| Het verzoek is nooit aangekomen. | Nee. | Juiste aanroep: de wijziging wordt één keer gemaakt. |
| De tool werkt nog. | Nog niet. Ze verschijnt nadat je AI het opgaf. | De wijziging wordt twee keer gemaakt, tenzij herhalen niet schadelijk is. |
| De tool was klaar en het antwoord is verloren gegaan. | Ja. | De wijziging wordt twee keer gemaakt, tenzij herhalen niet schadelijk is. |
De MCP-specificatie houdt hier rekening mee. Een client hoort op elk verzoek een timeout te zetten en, als die verstrijkt, het verzoek te annuleren en te stoppen met wachten. Een annulering is geen garantie. De server mag haar negeren als het werk al klaar is of niet meer te stoppen is. Ze kan ook aankomen nadat het antwoord al is verstuurd.
De API-handleiding van Stripe zegt hetzelfde: na een mislukte verbinding weet je misschien niet of het verzoek is uitgevoerd. Behandel een serverfout ook als een onbekende uitkomst.
Wat moet je na een timeout doen, in deze volgorde?
Doe dit in deze volgorde. De eerste twee duren een minuut.
- Stop de nieuwe pogingNu
Zeg je AI dat het de aanroep niet moet herhalen: “Probeer het niet opnieuw. Kijk eerst of het is gemaakt.” Een nieuwe poging op zichzelf is hoe een wijziging twee keer wordt gemaakt.
- Kijk in de tool, niet in de chat1 minuut
Open de tool zelf: de Notion-pagina, de GitHub-issues, de map. Zoek op de titel of het id dat je vroeg. De chat weet alleen dat de aanroep mislukte.
- Lees wat je vindt2 minuten
Gevonden en compleet: de wijziging is gemaakt. Ga door en herhaal haar niet.
Gevonden, half af: maak het ontbrekende deel af met een update, niet met een nieuwe create.
Niet gevonden: ze is nooit aangekomen, of ze loopt nog. Wacht een minuut en kijk opnieuw. - Probeer één keer opnieuw, en alleen een veilige aanroepDan
Staat ze er nog niet, probeer het dan één keer opnieuw. De tabel hieronder zegt welke aanroepen veilig zijn om te herhalen. Kijk bij een verzending waar die terechtkomt.
- Blijft het timeouten, verhelp dan de oorzaakDaarna
Een aanroep die altijd een timeout krijgt, heeft een limiet die te kort is of een taak die te groot is. Verhoog de limiet voor die server, of vraag per aanroep minder.
Welke aanroepen zijn veilig om opnieuw te proberen?
Een aanroep is veilig om opnieuw te proberen als twee keer doen hetzelfde resultaat geeft als één keer doen. Lezen valt daaronder. Veel wijzigingen niet. De HTTP-standaard ziet PUT (een waarde zetten) en DELETE als veilig om te herhalen, en de rijen hieronder volgen dat. De eigen idempotentHint of beschrijving van een tool gaat voor op die regels.
| De aanroep | Opnieuw proberen zoals het is? | Controleer eerst door |
|---|---|---|
| Lezen: zoeken, lijsten, openen | Ja. Het verandert niets. | Niets om te controleren. |
| Een waarde zetten: een status, een titel, een label | Meestal. Dezelfde waarde twee keer zetten geeft hetzelfde resultaat, zoals bij een HTTP PUT. | Het veld lezen. Heeft iemand het sindsdien gewijzigd, dan overschrijft een nieuwe poging hun bewerking. |
| Iets toevoegen: een reactie, een rij, een regel | Nee. Twee keer doen voegt het twee keer toe. | Het item openen en zoeken naar wat je toevoegde. |
| Aanmaken: een pagina, een issue, een bestand | Nee. Een nieuwe poging maakt er een tweede. | Zoeken op de titel of het id dat je opgaf. Alleen opnieuw proberen als niets overeenkomt. |
| Verwijderen | Meestal, als het één exact item noemt, zoals bij een HTTP DELETE. Niet “de laatste”: de tweede aanroep raakt een ander item. | Zoeken naar het item. Weg betekent klaar. |
| Versturen: een bericht, een e-mail, een melding | Nooit uit zichzelf. Een verzending kan niet worden teruggehaald. | Kijken waar die terechtkomt: de verzonden lijst, het kanaal, de andere kant. Kun je het niet zien, vraag dan voordat je opnieuw verstuurt. |
Kan een idempotency key het dubbele voorkomen?
Soms. Een idempotency key is een uniek label dat met een verzoek wordt meegestuurd. Komt hetzelfde label twee keer binnen, dan voert de dienst het werk één keer uit en herhaalt hij het eerste antwoord. Hij is gemaakt voor een verzoek dat geen antwoord kreeg.
- Hoe een key werkt bij Stripe. De v1-API van Stripe neemt een key bij
POST-verzoeken. Het slaat het eerste resultaat op, ook een fout, en geeft dat opnieuw terug bij een nieuwe poging met dezelfde key. Keys blijven minstens 24 uur bewaard. Dezelfde key met andere parameters wordt geweigerd. - Wat een nieuwe poging moet doen. Stuur dezelfde key en dezelfde parameters. Stripe zegt dat je niet met een nieuwe key opnieuw moet proberen tot je de eerste uitkomst kent. Een nieuwe key bij elke poging biedt geen bescherming.
- Wat MCP je geeft. Een
tools/call-verzoek bevat een toolnaam en zijn argumenten. Het schema van de specificatie definieert er geen idempotency key voor. Een tool kan er toch zelf een als argument aannemen, dus lees zijn argumenten. - Wat een tool mag aangeven.
idempotentHintzegt dat het opnieuw aanroepen van de tool met dezelfde argumenten geen extra effect heeft. Het is alleen een aanwijzing. De specificatie zegt dat clients nooit beslissingen moeten baseren op aanwijzingen van servers die ze niet vertrouwen.
Een key is dus een bonus, geen plan. Biedt de tool er geen, dan beschermt de controle hierboven je.
Hoe verander je de MCP-timeout?
Een limiet die te kort is, snijdt eerlijk werk af. Een limiet die te lang is, laat je wachten. Waar je hem instelt, hangt af van je AI-app. Hier zijn de instellingen van Claude Code.
| Instelling | Wat het begrenst | Standaard |
|---|---|---|
MCP_TOOL_TIMEOUT | Hoe lang één toolaanroep mag duren, in milliseconden. | 100.000.000 ms, ongeveer 28 uur |
timeout in .mcp.json | Hetzelfde, voor één server. Het overschrijft de variabele voor die server. Een harde limiet: voortgangsmeldingen verlengen hem niet. | De waarde van de variabele |
CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT | Hoe lang een aanroep stil mag blijven, zonder antwoord en zonder voortgang, voordat hij wordt afgebroken. 0 zet de controle uit. | 5 minuten voor netwerkservers, 30 minuten voor stdio |
MCP_TIMEOUT | Het starten van een server. Voor een remote server telt die ook mee in de timer per verzoek hieronder. | 30.000 ms, 30 seconden |
CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS | Wanneer een aanroep die nog loopt in het hoofdgesprek naar een achtergrondtaak gaat. 0 zet het uit. Versie 2.1.212 of later. | 120.000 ms, 2 minuten |
De standaard van 60 seconden voor remote servers. Een server die via HTTP, SSE of als claude.ai-connector wordt bereikt, heeft een tweede timer. Die loopt bij elk verzoek tot de eerste byte van het antwoord van de server. Hij duurt 60 seconden, tenzij MCP_TOOL_TIMEOUT, de timeout van de server of MCP_TIMEOUT hoger is ingesteld. Lokale stdio-servers hebben geen timer per verzoek.
Om hem voor één server in te stellen, voeg je "timeout": 600000 toe aan zijn item in .mcp.json. Dat is tien minuten.
Een trage aanroep is niet altijd een mislukte. Vanaf versie 2.1.212 zet Claude Code een MCP-aanroep in je hoofdgesprek na twee minuten om naar een achtergrondtaak. Het levert het resultaat af wanneer de aanroep eindigt.
De MCP-documentatie van Cursor beschrijft geen instelling voor een timeout. De MCP-specificatie noemt geen getal. Ze zegt dat SDK’s timeouts per verzoek instelbaar moeten maken, en dat een client altijd een maximum moet houden.
Voor werk dat minuten duurt, kan een server MCP Tasks gebruiken. Hij geeft meteen een handle terug, en de client vraagt het resultaat steeds opnieuw op, ook na opnieuw verbinden. Beide kanten moeten het ondersteunen, en de steun van clients verschilt.
Wat doet Delta MCP als een antwoord verloren gaat?
Delta MCP is een gratis app op je computer, tussen je AI en zijn tools. Als een wijziging geen antwoord krijgt, gokt het niet en probeert het niet zomaar opnieuw. Het leest de tool.
Voordat een wijziging wordt doorgestuurd, kiest Delta MCP een leesaanroep die kan laten zien of ze is gebeurd. Dat is het object opnieuw lezen, of een lijst opnieuw lezen. Komt er geen antwoord, dan voert het die leesaanroep meteen uit. Wat die toont, bepaalt wat er gebeurt:
| De leesaanroep toont | Delta MCP |
|---|---|
| De wijziging is gemaakt. | De taak gaat door, en het antwoord zegt dat het is gecontroleerd. |
| De wijziging is niet gemaakt. | Het stuurt de wijziging nog eens, met dezelfde argumenten. Bij een bericht of een andere verzending doet het dat nooit uit zichzelf. Voor die gevallen zegt het antwoord dat het niet is gezien, dat het misschien toch nog verschijnt, en stopt de taak. |
| Onduidelijk, of er is niets te lezen om het te zien. | Het antwoord zegt “outcome unknown”, en waarom. De taak stopt. Kijk in de tool voordat je de wijziging opnieuw maakt. |
Een tool die is aangeroepen zoals hij is, kan Delta MCP niet terugdraaien. Als een eerdere aanroep is gelukt, blijft die gedaan, en het antwoord noemt hem zodat je AI hem niet herhaalt. Elke taak die iets verandert, staat in Activity, met elke wijziging voor en na.
Hoe een taak wordt gecontroleerd en toegepast
Vragen
Is het veilig om een MCP-toolaanroep na een timeout opnieuw te proberen?
Lezen wel. Een wijziging niet, tot je hebt gecontroleerd. De timeout zegt alleen dat er geen antwoord kwam: de tool kan de wijziging toch hebben gemaakt. Kijk in de tool of ze er is, en probeer alleen opnieuw als ze ontbreekt. Probeer een verzending nooit uit zichzelf opnieuw.
Is mijn MCP-wijziging doorgegaan als het verzoek een timeout kreeg?
Dat zie je niet aan de timeout. Het verzoek is misschien nooit aangekomen, de tool werkt misschien nog, of ze was klaar en het antwoord is verloren gegaan. Open de tool en zoek de wijziging.
Hoe verhoog ik de timeout voor MCP-tools in Claude Code?
Zet MCP_TOOL_TIMEOUT in milliseconden, of voeg een veld timeout toe aan het item van de server in .mcp.json. Voor een remote server zet je hem boven 60.000 om de timer van 60 seconden per verzoek op te heffen. MCP_TIMEOUT is de wachttijd bij het starten, niet de limiet voor een toolaanroep.
Hoe verander ik de MCP-timeout in Cursor?
De MCP-documentatie van Cursor beschrijft geen instelling voor een timeout. Ze zegt dat een mislukte aanroep in de chat als mislukt wordt gemarkeerd, en dat je opnieuw kunt proberen of de logs kunt controleren. Kijk eerst in de tool wat er al is.
Heeft MCP idempotency keys?
Nee. Een toolaanroep bevat een toolnaam en argumenten, en het schema van de specificatie definieert er geen idempotency key voor. Een tool kan er zelf een als argument aannemen. Hij kan ook idempotentHint instellen, dat alleen een aanwijzing is.
Wat doet Delta MCP als een toolaanroep geen antwoord krijgt?
Het leest de tool meteen om te zien of de wijziging is gemaakt. Gemaakt: de taak gaat door. Niet gemaakt: het stuurt de wijziging nog eens. Een bericht of andere verzending wordt uit zichzelf nooit opnieuw verstuurd. Onduidelijk: het antwoord zegt “outcome unknown”, en de taak stopt.
Bronnen
- Model Context Protocol, Cancellation Clients horen timeouts te zetten, aanroepen te annuleren en te stoppen met wachten; een annulering kan aankomen nadat het werk klaar is (revisie 2026-07-28).
- Model Context Protocol, Schema Reference Een toolaanroep bevat een naam en argumenten, zonder idempotency key; de annotatie idempotentHint, en annotaties zijn alleen aanwijzingen (revisie 2026-07-28).
- Model Context Protocol, Tasks Een duurzame handle voor lange bewerkingen, die wordt opgevraagd en opgehaald na opnieuw verbinden; beide kanten moeten zich aanmelden.
- Claude Code, Connect Claude Code to tools via MCP De timeout per server, de timer van 60 seconden per verzoek voor remote servers, het idle-venster, de overgang naar de achtergrond na twee minuten.
- Claude Code, Environment variables MCP_TOOL_TIMEOUT, MCP_TIMEOUT, CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT en CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS, met hun standaardwaarden.
- Cursor, Model Context Protocol (MCP) Een mislukte MCP-aanroep wordt in de chat als mislukt gemarkeerd; opnieuw proberen of de logs controleren; er wordt geen instelling voor een timeout beschreven.
- Stripe, Idempotent requests Hoe een idempotency key werkt: het eerste resultaat wordt bewaard en opnieuw teruggegeven; keys blijven minstens 24 uur; andere parameters worden geweigerd.
- Stripe, Advanced error handling Na een mislukte verbinding weet je misschien niet of het verzoek is uitgevoerd; een serverfout is een onbekende uitkomst; geen nieuwe key voordat de uitkomst bekend is.
- IETF, RFC 9110: HTTP Semantics Idempotente methoden (veilige methoden, PUT en DELETE), en een niet-idempotent verzoek niet opnieuw proberen, tenzij je kunt zien dat het eerste nooit is toegepast.
- Delta MCP, Writing a task Wat Delta MCP doet als een wijziging geen antwoord krijgt: gemaakt, niet gemaakt of onbekende uitkomst; een verzending wordt niet uit zichzelf opnieuw verstuurd.
- Delta MCP, Activity and Undo Elke taak die iets verandert, staat in Activity, met elke wijziging voor en na.
Lees verder
- AI-wijzigingen ongedaan maken in Notion, GitHub en bestandenHeeft je AI-agent iets gewijzigd of verwijderd? Zie wat er veranderde, maak het ongedaan in Notion, GitHub of je bestanden, en lees wat nooit terug te halen is.
- MCP vs CLI voor AI-agents: waar de tokenkosten vandaan komenMCP of CLI voor je AI-agent? Wat elk aan tokens kost, wat de metingen laten zien, wanneer een CLI wint, wanneer MCP, en waar code ze allebei verslaat.
