Wanneer een AI-agent een website bezoekt, is het in wezen een toerist die de lokale taal niet spreekt. Of het nu gebouwd is op LangChain, Claude Code of het steeds populairder wordende OpenClaw-framework, de agent wordt gedwongen te raden welke knoppen hij moet indrukken: ruwe HTML schrapen, schermafbeeldingen naar multimodale sjablonen sturen en duizenden tokens verbranden om erachter te komen waar een zoekbalk zich bevindt.
Aan dat tijdperk komt mogelijk een einde. Het Google Chrome-team is eerder deze week gelanceerd WebMCP – Web Model Context Protocol – als vroege preview in Chrome 146 Canary. WebMCP, gezamenlijk ontwikkeld door Google- en Microsoft-ingenieurs en geïncubeerd via het W3C Web Machine Learning-gemeenschapsgroepis een voorgestelde webstandaard waarmee elke website gestructureerde en opvraagbare tools rechtstreeks aan AI-agenten kan tonen via een nieuwe browser-API: navigator.modelContext.
De gevolgen voor bedrijfs-IT zijn aanzienlijk. In plaats van afzonderlijke backend MCP-servers in Python of Node.js te bouwen en te onderhouden om hun webapplicaties met AI-platforms te verbinden, kunnen ontwikkelingsteams nu bestaande JavaScript-logica aan de clientzijde omzetten in door agenten leesbare tools, zonder ook maar één pagina opnieuw te hoeven ontwerpen.
AI-agenten zijn dure en kwetsbare toeristen op internet
De kosten- en betrouwbaarheidsproblemen met de huidige benaderingen van interactie met webagents (browseragents) worden goed begrepen door iedereen die deze op grote schaal heeft geïmplementeerd. De twee dominante methoden, visuele screen-scraping en DOM-analyse, lijden beide onder fundamentele inefficiënties die rechtstreeks van invloed zijn op de bedrijfsbudgetten.
Met een op screenshots gebaseerde aanpak voeden agenten afbeeldingen aan multimodale modellen (zoals Claude en Gemini) en hopen ze dat het model niet alleen kan identificeren wat er op het scherm staat, maar ook waar knoppen, formuliervelden en interactieve elementen zich bevinden. Elke afbeelding verbruikt duizenden tokens en kan een lange latentie hebben. Met op DOM gebaseerde benaderingen nemen agenten onbewerkte HTML en JavaScript op, een vreemde taal gevuld met verschillende tags, CSS-regels en structurele opmaak die niet relevant is voor de uit te voeren taak, maar nog steeds ruimte in beslag neemt in het contextvenster en gevolgtrekkingen kost.
In beide gevallen vertaalt de agent tussen waar de website voor is ontworpen (menselijke ogen) en wat het model nodig heeft (gestructureerde gegevens over beschikbare acties). Voor een enkele productzoekopdracht die een mens binnen enkele seconden voltooit, kunnen tientallen opeenvolgende agentinteracties nodig zijn (op filters klikken, door pagina’s scrollen, resultaten parseren), die allemaal een gevolgtrekking zijn die latentie en kosten toevoegt.
Hoe WebMCP werkt: twee API’s, één standaard
WebMCP biedt twee complementaire API’s die fungeren als brug tussen websites en AI-agents.
DE Declaratieve API verwerkt standaardacties die rechtstreeks in bestaande HTML-formulieren kunnen worden gedefinieerd. Voor organisaties met goed gestructureerde modules die al in productie zijn, vereist dit pad minimaal extra werk; Door gereedschapsnamen en -beschrijvingen toe te voegen aan de opmaak van bestaande modules, kunnen ontwikkelaars deze modules door agenten opvraagbaar maken. Als uw HTML-formulieren al schoon en goed gestructureerd zijn, bent u waarschijnlijk al voor 80% op weg.
DE Imperatieve API verwerkt meer complexe en dynamische interacties waarvoor JavaScript nodig is. Dit is waar ontwikkelaars rijkere toolschema’s definiëren, conceptueel vergelijkbaar met tooldefinities die naar OpenAI- of Anthropic API-eindpunten worden gepusht, maar volledig aan de clientzijde in de browser worden uitgevoerd. Via RegisterTool() kan een website functies zoals searchProducts (query’s, filters) of orderPrints (kopieën, page_size) weergeven met volledige parameterschema’s en beschrijvingen in natuurlijke taal.
Het belangrijkste inzicht is dat één enkele tooloproep via WebMCP tientallen browsergebruiksinteracties kan vervangen. Een e-commercesite die een searchProducts-tool registreert, stelt de agent in staat een gestructureerde functieaanroep te doen en gestructureerde JSON-resultaten te ontvangen, in plaats van dat de agent door vervolgkeuzelijsten met filters moet klikken, door gepagineerde resultaten moet bladeren en schermafbeeldingen van elke pagina moet maken.
De business case: kosten, betrouwbaarheid en het einde van fragiel schrapen
Voor IT-beslissers die agentische AI-implementaties evalueren, pakt WebMCP tegelijkertijd drie hardnekkige pijnpunten aan.
Kostenreductie het is het meest direct kwantificeerbare voordeel. Door reeksen screenshots, multimodale inferentieoproepen en iteratieve DOM-analyses te vervangen door enkele gestructureerde tooloproepen, kunnen organisaties aanzienlijke verminderingen in het tokenverbruik verwachten.
Betrouwbaarheid verbetert omdat agenten de structuur van de pagina niet meer raden. Wanneer een website expliciet een contract voor een tool publiceert – “hier zijn de functies die ik ondersteun, hier zijn hun parameters, hier is wat ze retourneren” – opereert de agent met zekerheid in plaats van met gevolgtrekkingen. Mislukte interacties als gevolg van wijzigingen in de gebruikersinterface, het dynamisch laden van inhoud of dubbelzinnige itemidentificatie worden grotendeels geëlimineerd voor elke interactie die wordt gedekt door een geregistreerde tool.
Ontwikkelingssnelheid versnelt omdat webteams bestaande front-end JavaScript kunnen gebruiken in plaats van een aparte back-endinfrastructuur te bouwen. De specificatie benadrukt dat elke taak die een gebruiker kan uitvoeren via de gebruikersinterface van een pagina kan worden omgezet in een hulpmiddel door een groot deel van de bestaande JavaScript-code van de pagina te hergebruiken. Teams hoeven geen nieuwe serverframeworks te leren of aparte API-oppervlakken te onderhouden voor agentconsumenten.
Human-in-the-loop door ontwerp, geen bijzaak
Een kritische architectonische beslissing scheidt WebMCP van het volledig autonome agent-paradigma dat de recente krantenkoppen domineert. De standaard is expliciet ontworpen rond coöperatieve en mens-in-de-loop-workflows, en niet op ongecontroleerde automatisering.
Volgens Khushal Sagar, een software-ingenieur bij Chrome, identificeert de WebMCP-specificatie drie pijlers waarop deze filosofie is gebaseerd.
-
Context: Alle dataagenten moeten begrijpen wat de gebruiker doet, inclusief inhoud die momenteel vaak niet zichtbaar is op het scherm.
-
Capaciteit– Acties die de agent namens u kan ondernemen, van het beantwoorden van vragen tot het invullen van formulieren.
-
Coördinatie: beheer de overdracht tussen gebruiker en agent wanneer de agent situaties tegenkomt die hij niet zelf kan oplossen.
Spec-auteurs van Google en Microsoft illustreren dit met een aankoopscenario: een gebruiker genaamd Maya vraagt haar AI-assistent om haar te helpen een milieuvriendelijke jurk voor een bruiloft te vinden. De agent stelt leveranciers voor, opent een browser naar een kledingsite en ontdekt dat de pagina WebMCP-tools zoals getDresses() en showDresses() bevat. Wanneer Maya’s criteria verder gaan dan de basisfilters van de site, roept de agent deze tools aan om productgegevens op te halen, gebruikt hij zijn eigen redenering om ‘geschikte cocktailkleding’ eruit te filteren en roept vervolgens showDresses() aan om de pagina bij te werken met alleen relevante resultaten. Het is een vloeiende cyclus van menselijke smaak en mogelijkheden van agenten, precies het soort samenwerkingsnavigatie waarvoor WebMCP is ontworpen.
Dit is geen standaard voor browsen zonder hoofd. DE specificatie vermeldt dit expliciet dat hoofdloze, volledig autonome scenario’s niet objectief zijn. Voor deze gebruiksscenario’s verwijzen de auteurs naar bestaande protocollen zoals het Agent-to-Agent (A2A)-protocol van Google. WebMCP gaat over de browser, waar de gebruiker aanwezig is, meekijkt en samenwerkt.
Geen vervanging van MCP, maar een aanvulling
WebMCP vervangt het Model Context Protocol van Anthropic niet, ondanks dat het een conceptuele afstamming en een deel van de naam deelt. Het volgt niet de JSON-RPC-specificatie die door MCP wordt gebruikt voor client-server-communicatie. Waar MCP werkt als een backend-protocol dat AI-platforms via gehoste servers met serviceproviders verbindt, werkt WebMCP volledig client-side binnen de browser.
De relatie is complementair. Een reisbureau zou een backend MCP-server kunnen onderhouden voor directe API-integraties met AI-platforms zoals ChatGPT of Claude, terwijl ze tegelijkertijd WebMCP-tools op hun consumentgerichte website kunnen implementeren, zodat browsergebaseerde agenten kunnen communiceren met de boekingsstroom in de context van de actieve sessie van een gebruiker. De twee standaarden dienen verschillende modellen van conflictvrije interactie.
Het onderscheid is belangrijk voor enterprise architecten. Backend MCP-integraties zijn geschikt voor service-to-service-automatisering waarbij de browsergebruikersinterface niet nodig is. WebMCP is geschikt wanneer de gebruiker aanwezig is en bij de interactie gebruik wordt gemaakt van een gedeelde visuele context, die de meeste consumentgerichte webinteracties beschrijft waarin bedrijven geïnteresseerd zijn.
Wat daarna komt: van vlag tot standaard
WebMCP is momenteel beschikbaar in Chrome 146 Canary achter de vlag ‘WebMCP voor testen’ op chrome://flags. Ontwikkelaars kunnen zich aansluiten Chrome early preview-programma om toegang te krijgen tot documentatie en demo’s. Andere browsers hebben nog geen implementatietijdlijnen aangekondigd, hoewel Microsoft’s actieve co-auteurschap van de specificatie suggereert dat Edge-ondersteuning waarschijnlijk is.
Industriewatchers verwachten halverwege tot eind 2026 formele browseraankondigingen, waarbij Google Cloud Next en Google I/O waarschijnlijk de locaties zullen zijn voor bredere lanceringsaankondigingen. De specificaties verschuiven van gemeenschapsincubatie binnen het W3C naar een formeel ontwerp, een proces dat historisch gezien maanden in beslag neemt, maar een teken is van serieuze institutionele betrokkenheid.
De vergelijking die Sagar maakte is leerzaam: WebMCP wil de USB-C worden van de interacties van AI-agenten met het internet. Eén enkele, gestandaardiseerde interface waarmee elke agent verbinding kan maken, ter vervanging van de huidige wirwar van aangepaste scrapingstrategieën en fragiele automatiseringsscripts.
Het realiseren van deze visie is afhankelijk van adoptie, zowel door browserleveranciers als door webontwikkelaars. Maar nu Google en Microsoft gezamenlijk de code leveren, het W3C de institutionele steigers levert en Chrome 146 al achter een banner implementeert, heeft WebMCP de moeilijkste hindernis overwonnen waar elke webstandaard mee te maken heeft: van voorstel naar werkende software.
