Wat is het?
Google heeft zojuist WebMCP als browser-API uitgebracht in Chrome 146. Microsoft heeft de W3C-spec mede opgesteld. Het is de moeite waard om op te letten.
Lees de Chrome-ontwikkelaarsblogpost →Hoe werkt het technisch?
Vandaag de dag communiceren AI-agents op de moeilijke manier met websites. Ze maken screenshots, verwerken die via vision-modellen en raden waar ze moeten klikken. Het is traag, duur en breekt zodra je je UI aanpast.
Waarom is het belangrijk?
WebMCP vervangt dat. Een website registreert tools in zijn frontend JavaScript via navigator.modelContext.registerTool(). De browser stelt die tools beschikbaar aan AI-agents die op het bureaublad van de gebruiker draaien. De agent maakt gestructureerde aanroepen in plaats van blinde klikken.
Waar moet je over nadenken voor implementatie?
Een reissite laat agents vluchten zoeken en boeken. Een e-commercesite laat agents producten vinden en de checkout voltooien. Een supportportaal laat agents gedetailleerde tickets aanmaken. Alles binnen de bestaande geauthenticeerde browsersessie van de gebruiker.
De grotere vraag: hoe zit het met agents zonder browser?
De website-eigenaar bepaalt wat er wordt blootgesteld. Zij schrijven de tooldefinities, de parameterschema's, de beschrijvingen. Niets gebeurt automatisch. Het is een actieve keuze, tool voor tool.
Waar Aimable past
WebMCP draait volledig client-side. De gebruiker bezoekt je website in Chrome. Je JavaScript registreert tools bij de browser. Een AI-agent (zoals Claude Desktop) verbindt met die Chrome-instantie en ziet de beschikbare tools. Wanneer de agent een tool aanroept, wordt deze uitgevoerd in het browsertabblad waar de gebruiker al is ingelogd.
Je webserver merkt het verschil niet. Het ontvangt normale geauthenticeerde verzoeken van de browsersessie, of die nu zijn getriggerd door een mens die klikt of een agent die een tool aanroept.
Dit verschilt van backend MCP-servers of REST APIs. Die verzorgen service-naar-service-communicatie. WebMCP maakt de frontend agent-aanroepbaar, met behulp van de sessie en status die al in de browser bestaan.
Drie redenen.
Ten eerste, efficiëntie. Vroege benchmarks tonen 89% minder tokens vergeleken met screenshot-gebaseerde benaderingen. Taken die 30-60 seconden screen-scraping kostten, worden in minder dan 5 seconden voltooid.
Ten tweede, betrouwbaarheid. Screen-scraping breekt wanneer een UI verandert. Gestructureerde toolaanroepen niet. Jij definieert het contract, de agent roept het aan.
Ten derde, distributie. Als jouw site agent-ready is en die van je concurrent niet, zal elke gebruiker die via een AI-agent werkt naar jou toe komen. Dat is een echt voordeel, en het gaat snel meetellen.
WebMCP is goed ontworpen. Maar een paar dingen zijn het overwegen waard.
Je definieert tools die door externe agents worden aangeroepen. Beperk de scope. Begin minimaal. Denk na over wat er gebeurt wanneer een agent onverwachte parametercombinaties stuurt of tools aanroept in een volgorde die je niet had voorzien.
De agent draait in de sessie van de gebruiker met diens volledige rechten. In gereguleerde sectoren betekent dat begrijpen wat een externe agent op je site kan doen voordat je compliance-team de vraag stelt.
En support: wanneer een agent je site verkeerd gebruikt, neemt de gebruiker contact met je op. Een sectie over agent-interactie in je documentatie opnemen en je supportteam trainen voor deze nieuwe categorie problemen is de moeite waard om vroeg te doen.
Hier wordt het voor ons interessant.
WebMCP dekt één scenario goed: een mens is aanwezig, de browser is open, de agent assisteert in realtime. Dat is waardevol.
Maar de richting waar alles naartoe beweegt is autonome agents. Achtergrondworkflows. Nachtelijke batchverwerking. Agents die acties koppelen over diensten heen zonder dat iemand meekijkt. Die agents draaien niet in Chrome. Ze zijn headless. Ze roepen backend APIs en MCP-servers rechtstreeks aan.
Voor die wereld is WebMCP niet het antwoord. En daar wordt de governance-vraag het meest relevant.