Je hebt al een API. Wanneer voegt WebMCP dan iets toe?

Door E. Clein · Laatst bijgewerkt 6 september 2026 · 4 min lezen

Kies je WebMCP omdat een agent de toestand van je webapp nodig heeft, of volstaat toegang tot de backend? Dat onderscheid is belangrijker dan ‘met of zonder mens’. Sinds 4 september staat expliciet in de officiële uitleg dat ook headless browsers binnen het toepassingsgebied vallen.

Een API is geen synoniem voor een externe serverkoppeling met aparte sleutels. Je eigen browserinterface kan een API aanroepen met de bestaande gebruikerssessie. Een andere toepassing kan dezelfde functionaliteit via een eigen authenticatieroute benaderen. De nuttige vraag is daarom welke context en bediening de gebruiker nodig heeft.

WebMCP voegt een beschrijving van aanroepbare paginafuncties toe voor agents. De uitvoering kan je bestaande applicatielogica gebruiken. Dat kan dubbel werk beperken, maar voorkomt niet automatisch dat interface, toolbeschrijving en validatie uit elkaar groeien.

Voorbeeld 1: een reparatieafspraak samen kiezen

Stel dat een klant op een reparatiesite een apparaat en vestiging heeft geselecteerd. Een agent helpt beschikbare momenten vergelijken terwijl de gebruiker meekijkt. Een WebMCP-tool kan de actieve selectie gebruiken om tijden op te vragen en een gekozen moment in de interface te tonen.

De klant ziet daardoor hetzelfde apparaat, dezelfde vestiging en dezelfde keuze als waar de tool mee werkt. Dat is een concrete reden om in de pagina te blijven. De tool moet wel duidelijk maken welke selectie zij gebruikt; een onzichtbare oude vestiging in de applicatiestatus kan anders een correct uitgevoerd verzoek toch onjuist maken.

Voorbeeld 2: iedere nacht afspraken exporteren

Een nachtelijke export naar het planningssysteem heeft in dit voorbeeld alleen afspraken uit de backend nodig, geen selectie of logica uit een webpagina. Daar passen een geplande backendtaak en een API vaak beter. Wanneer een AI-toepassing meerdere tools en databronnen moet gebruiken, kan een MCP-server een passende interface bieden. MCP heeft zowel lokale als externe serververbindingen; zie de MCP-architectuur.

WebMCP speciaal voor deze export toevoegen creëert waarschijnlijk extra afhankelijkheid van een pagina zonder duidelijke gebruikerswinst. Dat is een ontwerpafweging voor dit fictieve voorbeeld, geen verbod op andere technische constructies.

Headless: zonder venster, niet zonder browser

Op 4 september 2026 is PR #296 gemerged. De officiële README noemt headless gebruik nu expliciet als doel, ook in combinatie met menselijke tussenkomst. Dit verduidelijkt het toepassingsgebied; het is geen nieuwe API of browserrelease. Hoe een externe agent de browser aanstuurt, wordt hiermee niet gestandaardiseerd.

Bij headless gebruik draait de browser zonder zichtbaar venster. De pagina en haar clientcode blijven onderdeel van de uitvoering; zie Chrome's uitleg over headless. Een proces op een server kan dus een browser draaien. Dat is iets anders dan rechtstreeks server-API's aanroepen zonder pagina.

Ons testadvies voor de fictieve reparatiesite: laad in een gecontroleerde testomgeving dezelfde apparaat- en vestigingsselectie met en zonder zichtbaar venster. Wacht op de registratie, roep de alleen-lezen beschikbaarheidstool aan en vergelijk beide resultaten met dezelfde verwachte testdata. Noteer browserbuild en API-toegang. Een geslaagde tooltest bewijst nog niet dat een agent de tool juist kiest; daarvoor zijn afzonderlijke taakevaluaties nodig.

Controleer de beoogde browser- en agentcombinatie dus apart. De README belooft geen universele ondersteuning of automatische overdracht aan een gebruiker. Vereist een boeking nieuw akkoord, ontwerp dan hoe de uitvoering daarop wacht; een ontbrekend venster is geen toestemming.

Hergebruik de logica, controleer de grenzen

Ons advies: laat de bestaande UI en de WebMCP-tool dezelfde relevante servicefunctie aanroepen. Behoud daar de servercontroles op account, bevoegdheid, invoer en actuele beschikbaarheid. Voeg afzonderlijke tests toe voor de toollaag: haalt de agent de juiste argumenten uit de klantvraag en wordt het resultaat begrijpelijk weergegeven?

Het sluiten van een tab maakt een reeds uitgevoerde boeking niet ongedaan. Ook verdwijnen eerder gedeelde resultaten daardoor niet uit alle betrokken systemen. De bestaande sessie gebruiken is daarom geen bewijs dat er geen gegevens kunnen lekken of geen aanvullend toestemmingsontwerp nodig is.

Kijk wat een platform werkelijk levert

Shopify kondigde op 5 augustus tools aan voor Liquid-storefronts en een Hydrogen-preview, onder meer voor catalogus en winkelmand. Dat laat zien dat platformondersteuning werk kan overnemen. Het bewijst niet dat iedere winkel, maatwerkthema of klanttaak al volledig getest is. Controleer vooral eigen extensies en de overgang naar checkout.

Evenmin is WebMCP een automatische toegankelijkheidsverbetering. Benoemde tools kunnen nieuwe bedieningsmogelijkheden bieden, maar toetsenbordbediening, labels en de werking met hulptechnologie moeten zelfstandig goed blijven. Een toolregistratie vervangt die controles niet.

Neem de reparatieafspraak als beslisproef: is de paginastatus of samenwerking in de site waardevol? Onderzoek dan WebMCP, zichtbaar of headless. Heeft de taak alleen backendgegevens nodig, begin dan bij die integratie. Het benodigde uitvoeringsmodel geeft de doorslag, niet de aanwezigheid van een venster.