Op dit moment “gebruikt” een AI-agent je website zoals een toerist een stad bekijkt vanuit een helikopter: hij doorzoekt je DOM, parseert screenshots en raadt wat elke knop waarschijnlijk doet. WebMCP is de overstap van helikopter naar voordeur. De website geeft de agent een echte sleutel. Het is een browser-native API waarmee een website gestructureerde tools registreert via navigator.modelContext.registerTool, die een in-browser AI-agent vervolgens bij naam aanroept. Google kondigde het aan op Google I/O 2026, en het landde in mei als een Chrome 149 origin trial. Deze post gaat over wat het is, wat ik deze week op GuardingWP heb geshipt, het productinzicht dat niemand bespreekt, en het eerlijke antwoord op “maar niets roept het nog aan.” Zie het als onderdeel van moderne websites bouwen voor een agentic web.
Wat WebMCP eigenlijk doet (en wat het vervangt)
Hoe agents vandaag browsen, is omslachtig. De agent maakt een screenshot, loopt door de DOM, pookt in de accessibility tree en raadt. WebMCP draait het model om. De website declareert haar mogelijkheden als benoemde tools, en de agent roept ze direct aan met gestructureerde input.
De API is compact. Je roept navigator.modelContext.registerTool(tool, { signal }) aan, waarbij tool een object is met name, description, inputSchema en een execute-callback. Die callback ontvangt de gestructureerde input en geeft een Promise terug. Ik heb het MCP-style content block teruggegeven, { content: [{ type: “text”, text }] }, wat de server-side MCP-conventie spiegelt. De spec zelf schrijft alleen Promise<any> voor, dus die vorm is mijn keuze, geen verplichting.
De status is minstens zo belangrijk als de API. WebMCP is een W3C Draft Community Group Report gedateerd 20 mei 2026 (spec). Dat is incubatie. Het is nadrukkelijk geen W3C Standard en staat niet op het Recommendation Track. Het is mede-geredigeerd door Google (Khushal Sagar, Dominic Farolino) en Microsoft (Brandon Walderman), heeft op dit moment 87 open issues, en minstens twee secties staan nog als TODO gemarkeerd, waaronder requestUserInteraction. Waarom er dan toch op wedden? Chrome en Edge samen hebben ongeveer 73,55% van de browsermarkt (Statcounter, april 2026). Beide zijn Chromium-based, en beide leveranciers hebben de spec mede-geschreven. Zelfs als formele cross-browser standaardisatie stagneert, is een de-facto standaard op driekwart van de browsers zijn eigen soort realiteit.
Wat ik op GuardingWP heb geshipt
Eén tool. GuardingWP, een SaaS die ik bouwde voor het scannen van WordPress-beveiliging, registreert nu scan-wordpress-security({ url }) client-side, achter een feature check.
De tool zelf
De input is één WordPress-site-URL. De output is bewust dun: WordPress ja of nee, een letterrapportcijfer, een numerieke score, de zwaarste bevinding, en een deep link naar het volledige rapport. Dat is alles.
Het interessante zit achter de schermen. De execute() van de tool roept exact hetzelfde /api/report-endpoint aan dat mijn gewone scanner gebruikt. Alle beveiliging die ik al had gebouwd werkt dus automatisch: de 55 seconden cooldown, de SSRF URL-validatie, de per-host rate limit, de resultaatcache, de concurrency slot. Geen nieuw serveroppervlak voor aanvallen, want er is geen nieuwe servercode. De tool is een wrapper.
Het geheel is feature-detected met if (navigator.modelContext). Op de browsers die de API vandaag ondersteunen, wat bijna nul zijn, registreert de tool. Op elke andere browser gebeurt er niets en merkt niemand iets. Dat is pure progressive enhancement: geen degraded experience, geen fallback om te onderhouden, geen risico voor de bestaande scanner.
Het funnel-disintermediatie-inzicht
Dit is het deel dat geen enkele uitleg behandelt, en het deel dat er volgens mij echt toe doet.
WebMCP kan rustig je eigen funnel opeten. Als je tool de agent alles geeft, verbruikt de agent je hele waardepropositie en belandt de gebruiker nooit op je pagina. Ze krijgen je antwoord in een chatvenster. Jij krijgt niets: geen bezoek, geen aanmelding, geen relatie, geen idee dat het is gebeurd. Hoe beter je tool, hoe erger dit wordt. Dat is disintermediatie, en je veroorzaakt het zelf op het moment dat je te veel teruggeeft.
Dus ik ontwierp de output om terug naar mij te leiden. De tool geeft een teaser terug, niet het rapport. Een rapportcijfer en de zwaarste bevinding zijn genoeg signaal om het resultaat echt te laten voelen en een klik te verdienen. Ze zijn niet genoeg om de volledige scan te vervangen, en daar zit de echte waarde en de conversie. De agent krijgt een nuttig, eerlijk antwoord. De gebruiker krijgt een reden om naar de site te komen.
Daarna sloot ik de klik-lus. Ik voegde een ?url=-deep-link toe die de scanner vult en automatisch start. Wanneer de agent zijn headless scan via de tool uitvoert, warmt dat mijn vijf-minuten-resultaatcache op. Wanneer de gebruiker de link volgt, is het volledige rapport meestal al berekend en verschijnt het direct. De aanroep van de agent betaalt voor de wachttijd van de gebruiker.
Dit is geen slimme truc die je er achteraf aan vastplakt. Het is de eerste-principes-vraag die je bij elke tool moet stellen die je blootstelt: verdient deze output de volgende stap, of geeft hij alles weg? De data onderbouwt het instinct. Walmart zag een conversie die ruwweg 3x lager was bij AI-aankopen in chat vergeleken met doorsturen van gebruikers naar de eigen site (Commercetools agentic commerce research). De klik is geen wrijving die je moet weghalen. Voorlopig is dat nog steeds waar het geld zit.
Het eerlijke deel: bijna niets kan dit nog aanroepen
Laat ik direct zijn over het verkeer. Het is bijna nul.
Gemini in Chrome kondigde WebMCP-ondersteuning aan als “binnenkort beschikbaar” op Google I/O 2026 op 19 mei. Het is nog niet geshipt. Geen andere grote agent heeft toegezegd deze tools aan te roepen: Anthropics 2026 MCP-roadmap heeft geen expliciete WebMCP-vermelding, en ChatGPT heeft ook geen toezegging gedaan. Dit is een door Google aangestuurde weddenschap, en ik wil dat hardop zeggen in plaats van een brede industrie-adoptie te impliceren die niet bestaat.
Er zijn twee eerlijke kampen over WebMCP. De optimisten wijzen op de Google I/O-spotlight, de live demo van Expedia, en een echte lijst met trial-adopters: Booking.com, Shopify, Etsy, Instacart, Target, Credit Karma, TurboTax, Redfin. De sceptici wijzen op alleen-Chrome-ondersteuning, 87 open issues, kritieke spec-secties die nog TODO zijn, en het feit dat niets deze tools vandaag in productie aanroept. Beide kampen hebben gelijk, wat het vreemde deel is: het bull-scenario en het bear-scenario zijn tegelijk waar.
Beide kampen beantwoorden de verkeerde vraag. Ze debatteren over “wint het,” wat niemand nog kan beantwoorden. De vraag die ik kan beantwoorden is “is de verwachte waarde positief gegeven mijn bouwkosten.” De mijne waren een paar uur om een endpoint te wrappen dat ik al had. Downside als het sterft: ik verlies die uren en een tool registreert voor niemand. Upside als het agentic web landt: ik sta vroeg op infrastructuur die mijn concurrenten nog niet hebben aangeraakt. De agentic AI-markt stond op ongeveer 8,5 miljard dollar in 2026 en wordt geprojecteerd op bijna 35 miljard dollar in 2030 (Deloitte/Gartner via Wix AI Search Lab). Gartner verwacht dat 15% van de dagelijkse werkbeslissingen in 2028 autonoom door agents wordt genomen. Ik hoef die cijfers niet exact goed te hebben. Ik hoef alleen de upside het waard te vinden voor een dunne wrapper. Dat is het. Dezelfde redenering geldt voor GEO: je bereidt het oppervlak voor voordat het verkeer komt, want de voorbereiding is goedkoop en de inhaalslag is dat niet.
Waarom een beveiligingsscanner de perfecte match voor WebMCP is
Niet elke feature op je website vertaalt zich netjes naar een tool. Een scanner wel, en de redenen maken een handig filter voor je eigen site. Een goede WebMCP-tool heeft drie dingen nodig:
- Duidelijke gestructureerde input. Eén ondubbelzinnige parameter die de agent kan invullen. Een URL-string voldoet. “Help me mijn reis plannen” niet.
- Deterministische gestructureerde output. Het resultaat is data die de agent kan teruggeven, geen stateful flow. Een rapportcijfer en een bevinding voldoen.
- Read-only, geen bevestiging vereist. De tool leest en rapporteert. Hij koopt niet, muteert niet en committeert niets namens de gebruiker.
scan-wordpress-security scoort op alle drie. Input is een URL, output is een rapportcijfer plus een bevinding, en een scan verandert niets, dus requestUserInteraction heb ik nooit nodig. Wat handig is, want dat deel van de spec staat nog als TODO. Checkout en abonnementswijzigingen zijn het tegenovergestelde geval: die muteren state en hebben gebruikersbevestiging nodig, en dus de bevestigingsgate die er nog niet is. Ship die vandaag niet als tools. Ship de read-only varianten.
De voorbereiding is nu nog goedkoop.
Het agentic web is geen toekomstige staat waar je je op voorbereidt. Het is een infrastructuurweddenschap in het heden die je vandaag goedkoop kunt plaatsen. Een website bouwen die een AI-agent kan bedienen is nu iets wat je in de praktijk doet, niet iets wat je theoretiseert, en het kost ongeveer een middag voor een read-only tool. Als je een website wilt laten bouwen met dit soort infrastructuur in gedachten, zo bouw ik.
De voorbereiding is nu nog goedkoop.