Een WebMCP-tool geeft een timeout: is de boeking mislukt?

Door E. Clein · Laatst bijgewerkt 5 september 2026 · 3 min lezen

De agent wacht op een bevestiging, maar de verbinding valt weg. Nog een keer proberen lijkt logisch. Bij een boeking kan dat een tweede reservering opleveren. Dit voorbeeld laat zien hoe je de uitkomst controleerbaar maakt.

Een WebMCP-tool kan bestaande serverlogica aanroepen. Daarbij kan de aanvraag al zijn verwerkt terwijl het antwoord de browser niet bereikt. Een melding ‘verbinding verbroken’ beschrijft dan alleen wat de client weet. Zij bewijst niet dat er niets is gebeurd. Dit is een bekend probleem bij netwerkverzoeken, dat ook bij agentgestuurde acties aandacht verdient.

Het onderstaande boekingsvoorbeeld is fictief en beschrijft een applicatieontwerp. Het is geen verslag van een waargenomen WebMCP-storing en geen mechanisme dat WebMCP automatisch voor je toevoegt.

Het gevaarlijke moment zit na het opslaan

Als elke poging een nieuwe aanvraag-ID krijgt, kan de server beide pogingen als afzonderlijke opdrachten behandelen. De herstelknop moet daarom dezelfde identiteit behouden voor dezelfde bedoelde actie. Pas een echt nieuwe boeking krijgt een nieuwe sleutel.

Maak herhaling een servereigenschap

Een gangbaar patroon is een idempotentiesleutel: de server koppelt het resultaat van een bewerking aan die sleutel. Stripe documenteert dit patroon voor zijn eigen API. De exacte bewaartermijn en foutafhandeling van Stripe zijn geen voorschrift voor jouw website; bepaal die op basis van je eigen proces.

In ons ontwerp bewaart de backend R42 samen met het bevoegde account, de relevante boekingsinvoer en de uitkomst. Het vastleggen van de sleutel en de boeking moet tegen gelijktijdige verzoeken bestand zijn. Alleen eerst controleren of een sleutel bestaat en daarna los opslaan is onvoldoende: twee aanvragen kunnen die controle tegelijk passeren.

Gebruik daarom bijvoorbeeld een unieke databasebeperking en een transactie of een gelijkwaardige atomaire aanpak. Krijgt dezelfde sleutel andere boekingsgegevens, weiger die combinatie. Geef nooit de boekingsstatus van een ander account terug doordat iemand een sleutel raadt. Herhaling vervangt autorisatie niet.

Laat de tool een bruikbare status teruggeven

Maak een onderscheid tussen voltooid, nog in verwerking, afgewezen en onbekende uitkomst. Die namen zijn hier eigen applicatievelden, geen WebMCP-standaard. Een voltooid antwoord kan er als volgt uitzien:

{
  "requestId": "R42",
  "status": "completed",
  "bookingId": "B17",
  "createdNow": false
}

createdNow: false vertelt in dit voorbeeld dat de bestaande boeking wordt getoond. Bij een onbekende uitkomst vraagt de interface eerst de status op. Ze meldt niet dat reserveren mislukt is en start niet automatisch een nieuwe boeking. Ook de gewone websiteknop moet dit gedrag volgen, zodat gebruiker en agent hetzelfde herstelpad hebben.

Controleer het met een gerichte foutproef

Test in een oefenomgeving een onderbreking ná het opslaan maar vóór het antwoord. Herhaal daarna twee keer met dezelfde sleutel. Er hoort één boeking te bestaan en elke herhaling moet naar die boeking verwijzen. Probeer vervolgens dezelfde sleutel met gewijzigde invoer en met een onbevoegd account; beide moeten volgens je eigen contract worden afgewezen.

Bewaar voor diagnose een technische correlatie-ID, stap en uitkomst. Volledige prompts of klantgegevens zijn daarvoor niet vanzelf nodig. Een foutbericht helpt pas wanneer mens en agent weten of ze moeten wachten, status controleren of een nieuwe keuze maken. Dat is ook de kern van Chrome's advies over herstelbare toolfouten.