Je WebMCP-tool navigeert naar de volgende pagina. Krijgt de agent nog een resultaat?

Door Enrico Clein · Gepubliceerd 3 oktober 2026 · 3 min lezen

Stel: een agent vult namens een klant een aanvraag in en de website gaat daarna naar een bevestigingspagina. De server kan de aanvraag al hebben verwerkt, terwijl de agent geen betrouwbaar eindresultaat terugkrijgt. Dat is een praktische grens van WebMCP-tools die een volledige paginawissel veroorzaken. Een recent voorstel met een werkende ontwikkelaarsdemo probeert die grens te verleggen, maar is nog geen beschikbare standaardfunctie.

Eén document, één lopende tool

De huidige WebMCP-conceptspecificatie koppelt een lopende tooluitvoering aan het document waarin de tool draait. Als dat document wordt vernietigd, wordt de uitvoering afgehandeld of afgebroken; de nieuwe pagina neemt de JavaScript-callback niet zomaar over. Het op 2 oktober 2026 samengevoegde uitlegvoorstel noemt de concrete pijn: na een serververzoek dat een volledige navigatie veroorzaakt, ontvangt de agent mogelijk geen succesmelding of toolresultaat.

Dat betekent niet dat de serveractie automatisch is teruggedraaid. Bij een bestelling of aanvraag kan juist onzeker worden of de stap is gelukt. Laat een agent in die situatie niet blind dezelfde muterende tool opnieuw aanroepen. Controleer het resultaat via de vertrouwde serverstatus en ontwerp herhaalde verzoeken zó dat ze geen dubbele handeling veroorzaken. Dat is ons implementatieadvies, geen garantie die WebMCP zelf biedt.

Een routewissel binnen dezelfde geladen webapp is iets anders dan een volledige paginawissel. Een single-page-app kan in hetzelfde document blijven, maar ook daar moet je testen of de tool geregistreerd blijft en of zijn resultaat de werkelijke servertoestand weerspiegelt. Een URL die verandert, vertelt je op zichzelf niet welke van de twee situaties je hebt.

Wat continuatietokens zouden veranderen

Het nieuwe explainer-document stelt voor dat een tool tijdens de uitvoering een eenmalig token opvraagt. De website geeft dat door aan het volgende document, dat met resumeTool() de oorspronkelijke aanroep hervat. Pas na de laatste stap zou de agent het definitieve resultaat krijgen. Het voorbeeld is een checkout die van factuurgegevens naar verzending en vervolgens bevestiging gaat; dezelfde gedachte wordt verkend voor een later geladen iframe op dezelfde origin.

Dit is geen manier om een agent onzichtbaar door elke betaalflow te sturen. Het voorstel beperkt inwisseling tot dezelfde origin en browsercontext, trekt tokens in bij annulering en laat vragen over levensduur, navigaties en beveiligingsgrenzen open. Identiteit, bevoegdheid, prijs, voorraad en expliciete klantbevestiging blijven verantwoordelijkheden van de website en haar server.

Werkende demo, maar nog geen browserbelofte

De relevantie is concreter dan een losse GitHub-discussie: GoogleChromeLabs heeft op 2 oktober een demo-aanpassing samengevoegd. De maker meldt dat een tool in een lokale Chromium-proef na navigatie kan worden hervat en dat de demo terugvalt op een declaratieve formulierroute als de tokens ontbreken. De bijbehorende Chromium-implementatie stond bij onze controle nog open; ondersteuning in de voorbeeldextensie was nog een draft. Een samengevoegde explainer en demo zijn dus geen bewijs dat de API al in de browser van jouw klanten of hun agent werkt. Wij hebben die lokale proef niet zelf uitgevoerd.

Voor een productteam is de eerstvolgende stap nuchter: teken één klanttaak uit waarin een volledige navigatie voorkomt. Test met fictieve gegevens of de agent na iedere stap kan onderscheiden tussen 'nog bezig', 'gelukt' en 'onbekend'. Controleer de serverstatus apart, ook als de tool geen resultaat teruggeeft, en test herhaling na een afgebroken aanroep. Houd voorlopig de paginastappen en bevestiging expliciet. Experimenteer pas met continuatietokens in een geïsoleerde proef zodra de benodigde browser- én agentondersteuning aantoonbaar aanwezig is.

De les is groter dan deze voorgestelde API: ontwerp een WebMCP-tool niet alleen rond de knop die hij vervangt, maar rond de plek waar zijn resultaat betrouwbaar vaststaat. Bij een proces over meerdere pagina's is juist die grens bepalend voor wat een agent eerlijk aan de klant kan bevestigen.