Je ticketwidget heeft WebMCP. Wat kan een agent op jouw website dan echt?

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

Je website verkoopt tickets via een ingesloten stoelplattegrond. Een klant vraagt zijn browseragent om twee plaatsen naast elkaar te vinden. Moet je daarvoor je hele ticketproces opnieuw als WebMCP-tools bouwen? Niet per se. Maar de widget, de pagina eromheen en de betaalstap hebben elk een eigen rol. Als je die door elkaar haalt, lijkt een demo verder af dan hij is.

Een echte widget, geen nieuwe standaardregel

De SeatLayer-documentatie beschrijft een optionele WebMCP-integratie in zijn SeatPicker. Volgens de maker bestaat die sinds SDK-versie 0.71.5, gepubliceerd op 28 augustus 2026. De documentatie is op 1 oktober bijgewerkt met een nieuwere pakketversie; dát is op zichzelf geen nieuwe WebMCP-release. In de huidige publieke SDK-bundel staan de beschreven toolnamen en verwijzingen naar modelContext. We hebben de code en documentatie gecontroleerd, maar geen echte aankoop of agentrun uitgevoerd.

De integratie staat standaard uit. Met webMcp: true biedt de picker tools om een evenement te beschrijven, beschikbare stoelen te zoeken, stoelen te selecteren en de actuele selectie te lezen. Een agent die seatlayer_find_seats aanroept, krijgt kandidaten; die aanroep legt nog niets vast. seatlayer_select_seats wijzigt wél de winkelmand en de koper ziet die keuze op dezelfde plattegrond. Dat gedeelde scherm is de interessante les voor iedere ingebouwde configurator: laat een agent werken in dezelfde toestand die de klant kan bekijken en corrigeren.

Een hold is bovendien niet vrijblijvend: hij houdt plaatsen tijdelijk bezet voor andere kopers. SeatLayer laat die actie daarom apart inschakelen. Er is geen WebMCP-tool voor afrekenen of betalen. Dit zijn eigenschappen van deze SDK, geen regels die iedere ticketwidget automatisch volgt.

Staat de widget in een iframe? Dan verandert de test

Een widget die als script in jouw pagina draait, heeft een andere herkomstsituatie dan een widget in een iframe van een leverancier. Bij een iframe op een andere origin moet de host volgens de Chrome-uitleg toegang via allow="tools" delegeren. De widget moet met exposedTo expliciet aangeven welke host-origin zijn tools mag zien. Een agent die als script op de hostpagina draait, moet ze vervolgens met getTools({ fromOrigins: [...] })` bij die iframe-origin opvragen. SeatLayer beschrijft precies deze opt-ins.

Dat is geen universeel recept voor iedere browseragent. Een ingebouwde browseragent heeft zijn eigen ontdekkingstraject; ondersteuning voor de WebMCP-API, iframe-tools en daadwerkelijke aanroepen moet je per client testen. Zo meldt Cloudflare dat Kitesurf via zijn CDP-verbinding geen tools uit iframes aanbiedt. Een werkende tool op de hoofdpagina bewijst dus niet dat dezelfde agent je ingesloten kaart kan bedienen.

Houd de boeking bij de vertrouwde server

SeatLayer laat de koper via de normale checkout doorgaan. In zijn integratievoorbeeld gaat bij die overdracht alleen een ondoorzichtige hold-ID naar de eigen server. Die server moet de hold en actuele prijs controleren, de koper authenticeren en met een herhaalveilige boekingsreferentie afrekenen. Neem geen prijs of stoelgegevens uit een agentargument over als autoritatieve bestelling. Ook een toolomschrijving of annotatie is geen vervanging voor die controle.

Voor een eerste proef adviseren wij één testevenement met fictieve kopers. Controleer in een ondersteunde browser of de agent de vier basistools vindt, twee naast elkaar gelegen stoelen selecteert en de zichtbare mand klopt. Herhaal daarna met een uitverkochte rij, een verlopen hold en een iframe. Noteer bij iedere stap wat de agent zag, wat de gebruiker bevestigde en wat de server werkelijk vastlegde. Zet holds: true pas aan als de organisator de gevolgen voor voorraad en klantreis accepteert. Dit is ons testadvies, geen door ons gemeten SeatLayer-resultaat.

De bredere boodschap: vraag je leverancier niet alleen óf zijn widget WebMCP ondersteunt. Vraag waar de tools draaien, welke acties gegevens of voorraad veranderen, welke agent ze kan bereiken en waar de menselijke bevestiging en servercontrole blijven. Een agent-ready onderdeel maakt nog niet vanzelf de hele website agent-ready.