Wat is WebMCP en waarom heeft je website het nodig

De manier waarop AI-agents met websites omgaan verandert. Tot voor kort moest een agent die op je site een vlucht wilde boeken of een catalogus wilde doorzoeken de accessibility tree of een screenshot lezen, raden welke knop wat deed, klikken, wachten en herhalen. WebMCP, een W3C-voorstel dat door engineers van Google en Microsoft wordt geredigeerd, geeft websites een standaardmanier om hun functionaliteit als gestructureerde tools aan te bieden die een agent direct kan aanroepen, in de eigen browsersessie van de gebruiker.

In februari was dit een Chrome-flag en een draft. Sinds augustus is het iets wat een agent echt gaat gebruiken: de desktop-browser van ChatGPT en Codex roepen WebMCP-tools aan op pagina's die zulke tools aanbieden, Shopify zette tools aan voor elke Liquid-storefront, en Chrome en Edge draaien origin trials. WebKit heeft zich formeel tegen het voorstel uitgesproken en Mozilla is neutraal, dus beklonken is het ook niet.

Wat WebMCP is

WebMCP (Web Model Context Protocol) is een browser-API, in ontwikkeling bij de W3C Web Machine Learning Community Group als Draft Community Group Report. Een pagina kan er tools mee registreren: benoemde functies met een omschrijving, een JSON Schema voor de input en een execute-callback. Een agent die in of naast de browser draait leest die definities en roept de tools aan in plaats van de pagina via de UI te bedienen. Het voorstel kwam in augustus 2025 van het Edge-team van Microsoft; het Chrome-team van Google redigeert mee.

De naam nodigt uit tot een misverstand, dus een verduidelijking van een van de auteurs, Patrick Brosset: de browser wordt geen MCP-server. WebMCP dekt de laag van de primitieven, de tooldefinities, en laat het protocolwerk aan browser en agent. Met andere woorden: jij schrijft JavaScript-functies en omschrijft ze; MCP spreek je zelf nooit.

Waarom WebMCP ertoe doet

Een typische browser-use-sessie ziet er vandaag zo uit: de agent maakt een snapshot van de pagina, vraagt een model welk element hij moet aanklikken, klikt, wacht tot de pagina tot rust komt en herhaalt dat, vaak tientallen keren voor één taak. Elke ronde kost tokens en kan stuklopen op een verschoven knop of een laat ladende modal. Vanuit je server gezien is het verkeer niet te onderscheiden van een scraper.

Met WebMCP is dezelfde taak één aanroep. Een winkel die een tool search_products registreert, krijgt een gestructureerd verzoek en geeft gestructureerde resultaten terug, en de agent komt nooit bij de filterdropdowns. Jij bepaalt welke functies bestaan en wat ze accepteren, en alles draait in de sessie van de bezoeker zelf, met dezelfde cookies en dezelfde autorisatie die je knoppen al gebruiken.

Zoals Christian Heilmann het verwoordde toen de Chrome-preview uitkwam: "agents have become first-class citizens of the world wide web." In plaats van tegen de infrastructuur van het web te vechten, kunnen agents ermee samenwerken, en de site-eigenaar houdt de controle over wat er wordt aangeboden.

Twee API's: declaratief en imperatief

WebMCP biedt twee manieren om tools aan te bieden. De declaratieve API annoteert HTML-formulieren; de imperatieve API registreert tools vanuit JavaScript. Je kunt er een of allebei gebruiken.

De declaratieve API: attributen op formulieren

De declaratieve aanpak is de snelste instap. Je zet een paar attributen op een bestaand formulier en de browser maakt er een tooldefinitie van die agents kunnen ontdekken en invullen. Geen JavaScript nodig.

<form
  id="search-flights"
  toolname="searchFlights"
  tooldescription="Search for available flights by origin, destination, and date"
  toolautosubmit="true"
>
  <label for="origin">From</label>
  <input
    type="text"
    id="origin"
    name="origin"
    required
    toolparamdescription="Departure airport code (e.g. AMS, JFK, LHR)"
  />

  <label for="destination">To</label>
  <input
    type="text"
    id="destination"
    name="destination"
    required
    toolparamdescription="Arrival airport code (e.g. CDG, SFO, NRT)"
  />

  <label for="date">Date</label>
  <input
    type="date"
    id="date"
    name="date"
    required
    toolparamdescription="Departure date in YYYY-MM-DD format"
  />

  <button type="submit">Search Flights</button>
</form>

De attributen, zoals beschreven in de explainer van de declaratieve API:

• toolname: de identifier van de tool (bijvoorbeeld searchFlights)
• tooldescription: een omschrijving in gewone taal van wat de tool doet, die de agent gebruikt om te beslissen wanneer hij hem aanroept
• toolparamdescription: een omschrijving per invoerveld, zodat de agent weet welke waarde hij moet invullen
• toolautosubmit: optioneel, laat de agent het formulier na het invullen zelf versturen

De imperatieve API: tools registreren vanuit JavaScript

Voor alles wat verder gaat dan een formulier registreert de imperatieve API tools op document.modelContext. Elke tool heeft een naam, een omschrijving, een inputschema, optionele annotaties en een execute-callback. De getter verhuisde in mei 2026 van navigator naar document, omdat tools aan een document gebonden zijn en een window langer kan leven dan één document; Chrome 150 markeert de oude locatie als deprecated maar houdt hem als alias, en de browser van OpenAI biedt de nieuwe aan.

if (typeof document.modelContext?.registerTool === "function") {
  const controller = new AbortController();

  await document.modelContext.registerTool(
    {
      name: "search_products",
      description: "Search the product catalog by keyword, category and maximum price",
      inputSchema: {
        type: "object",
        properties: {
          query: { type: "string", description: "Search keywords" },
          category: {
            type: "string",
            description: "Product category filter",
            enum: ["electronics", "clothing", "home", "sports"],
          },
          maxPrice: { type: "number", description: "Maximum price in EUR" },
        },
        required: ["query"],
        additionalProperties: false,
      },
      annotations: { readOnlyHint: true },
      execute: async ({ query, category, maxPrice }) => {
        const params = new URLSearchParams({ q: query });
        if (category) params.set("category", category);
        if (maxPrice) params.set("max_price", String(maxPrice));
        const res = await fetch(`/api/products?${params}`);
        return { results: await res.json() };
      },
    },
    { signal: controller.signal }
  );

  // Later, bijvoorbeeld als de component unmount:
  // controller.abort(); // meldt de tool af
}

Drie details in dat fragment doen ertoe. De feature check is verplicht, want buiten de origin trials, de Chrome-flag, het experiment van Brave en de ChatGPT-browser is document.modelContext undefined. Afmelden gaat via een AbortSignal in de options, het enige verwijdermechanisme in de huidige spec. En een tweede tool met dezelfde naam registreren wordt geweigerd met een InvalidStateError, dus houd namen uniek.

Dezelfde interface biedt ook getTools(), dat de op de pagina geregistreerde tools opsomt, en executeTool(), dat er een uitvoert. Daarmee inspecteert een agent, een extensie of een testopstelling je tools en roept ze aan. Het options-object accepteert een lijst exposedTo met origins, die bepaalt welke documenten in de frame tree een tool kunnen zien.

Welke API gebruik je?

In de praktijk gebruik je allebei: declaratief voor de formulieren die je al hebt, imperatief voor functionaliteit zonder formulier.

Toestemming, bevestiging en wat de browser afdwingt

De spec is beknopt over toestemming van de gebruiker. Wat er wel in staat: de API is alleen beschikbaar in secure contexts (HTTPS), toegang loopt via een permissions-policy-feature tools met 'self' als standaard-allowlist, tools zijn met exposedTo tot origins te beperken, en elke tool kan een annotatie readOnlyHint dragen die de agent vertelt dat hij niets verandert. Een ingebouwde bevestigingsdialoog, of een API waarmee een tool halverwege een vraag aan de gebruiker stelt, bestaat niet.

Bevestiging ligt bij de agent. De implementatie van OpenAI geeft elke tool-aanroep een safety review, past de gewone bevestigingsregels toe op ingrijpende acties zoals aankopen, berichten, verwijderingen en permissiewijzigingen, en toont gebruikers een "Site tools"-paneel met elke tooldefinitie en een log van wat er is aangeroepen. De documentatie stelt ook dat "website-provided tool definitions and results are untrusted content", en dat is de juiste houding. Aan jouw kant geldt het omgekeerde: een agent-aanroep is een verzoek uit een browser die je niet beheert, dus hij krijgt dezelfde validatie en autorisatie als een form post.

Discovery: wat er is en wat er niet is

Tools die met een van beide API's zijn geregistreerd, zijn te ontdekken zodra een agent de pagina open heeft in een browser die WebMCP ondersteunt; daar is getTools() voor. Dit is het enige discovery-mechanisme dat de spec definieert.

Discovery op siteniveau, een manier voor een agent om te weten wat je site biedt voordat hij een pagina opent, is een open discussie in de community group zonder voorstel in de spec. Geen enkele browser of agent documenteert dat hij een manifest leest, en de deployments van Shopify en OpenAI publiceren er geen. Onze scanner gaf tot voor kort punten voor een bestand op /.well-known/webmcp.json; sinds 27 augustus niet meer, omdat er niets is waar zo'n bestand aan kan voldoen en niemand het leest. ChatGPT doet er niets mee. Het gevolg, dat ik in het augustus-artikel behandel, is dat je tools van buiten een geschikte browser onzichtbaar zijn.

Waar WebMCP vandaag draait

WebMCP is een Draft Community Group Report en staat niet op het W3C-standaardentraject. De stand van zaken op 27 augustus 2026:

Twee platforms deden meer voor de adoptie dan welke browser ook. Op 5 augustus zette Shopify WebMCP aan voor elke Liquid-storefront, tien tools van search_catalog tot proceed_to_checkout, zonder dat merchants iets hoefden te installeren. Op 6 augustus opende Cloudflare een developer preview die aan de edge een bridge-script injecteert en tools registreert op document.modelContext voor sites die een schakelaar omzetten. Googles eigen lijst van bedrijven die met WebMCP experimenteren, van I/O 2026, noemt Expedia, Booking.com, Shopify, Credit Karma, TurboTax, Redfin, Etsy, Instacart en Target.

Wat nog open staat

In februari schreef ik een tijdlijn die via de browsers liep. Dat was het verkeerde kader. Adoptie wordt beslist door platforms en agent-leveranciers, en de browsers volgen. Wat echt nog open staat:

• Standaardentraject. De spec is nog een Community Group-rapport, en het verzet van WebKit maakt een stap naar het standaardentraject lastiger.
• Safari. Zolang WebKit tegen is, hebben Safari-gebruikers geen WebMCP-route. Reken erop dat agent-leveranciers hun DOM-gestuurde fallback nog jaren houden.
• API-verschuivingen. De getter is al één keer verhuisd; getTools() en executeTool() kwamen er in juli en augustus bij. Doe overal een feature check en houd de fallback-shim.
• Discovery. Zolang de spec geen antwoord op siteniveau heeft, leren agents je tools alleen kennen door langs te komen, en blijft zichtbaarheid in zoekmachines bepalen wie bezocht wordt.

Zo implementeer je WebMCP vandaag

Je hoeft niet te wachten op brede browsersupport. De declaratieve API kost een paar attributen, de imperatieve API een kleine module, en allebei doen ze niets in browsers zonder de API. Stap voor stap:

Stap 1: annoteer je bestaande formulieren

Pak je belangrijkste formulieren (zoeken, contact, boeken, inloggen) en voeg de attributen toe. Minuten per formulier:

<form
  action="/search"
  method="get"
  toolname="searchProducts"
  tooldescription="Search products by keyword. Returns matching products with prices and availability."
>
  <label for="q">Search</label>
  <input
    type="search"
    id="q"
    name="q"
    required
    toolparamdescription="Search keywords, for example: wireless headphones"
  />
  <button type="submit">Search</button>
</form>

Stap 2: registreer imperatieve tools

Voor functionaliteit zonder formulier, zoals voorraad checken, producten vergelijken of verzendkosten berekenen, registreer je tools vanuit een module:

const mc = document.modelContext ?? navigator.modelContext; // shim zolang Chrome 150 de alias houdt

if (typeof mc?.registerTool === "function") {
  await mc.registerTool({
    name: "check_availability",
    description: "Check whether a product is in stock at a store near a postal code",
    inputSchema: {
      type: "object",
      properties: {
        productId: { type: "string", description: "Product SKU or ID" },
        postalCode: { type: "string", description: "Postal code for the store lookup" },
      },
      required: ["productId"],
      additionalProperties: false,
    },
    annotations: { readOnlyHint: true },
    execute: async ({ productId, postalCode }) => {
      const res = await fetch(`/api/availability/${encodeURIComponent(productId)}?postal=${encodeURIComponent(postalCode ?? "")}`);
      if (!res.ok) {
        return { error: "Unknown product ID. Use the SKU shown on the product page." };
      }
      return await res.json();
    },
  });
}

Stap 3: behandel formulieren die een agent verstuurt anders

Als een agent een formulier verstuurt, wil je waarschijnlijk gestructureerde data teruggeven in plaats van een redirect, en de interactie apart loggen. Daar zijn SubmitEvent.agentInvoked en respondWith() uit de declaratieve explainer voor:

document.getElementById("search-form").addEventListener("submit", (event) => {
  if (!event.agentInvoked) {
    return; // mensen krijgen de normale navigatie
  }

  event.preventDefault();
  const formData = new FormData(event.target);
  const results = performSearch(formData.get("q"));

  event.respondWith({ results, total: results.length });
});

Stap 4: test in een echte agent

• Open de pagina in de ChatGPT desktop-app (ChatGPT Work of Codex) en bekijk "Site tools" in de adresbalk; daar staat elke tooldefinitie die de pagina registreerde
• Zet in Chrome chrome://flags/#enable-webmcp-testing aan en installeer de extensie Model Context Tool Inspector om tools op te sommen en handmatig aan te roepen
• Voor productieverkeer meld je je aan voor de origin trial van Chrome (vanaf 149) of die van Edge (150)
• Roep elke tool aan met verkeerde en ontbrekende input en controleer of de foutmeldingen een agent helpen herstellen

Wat WebMCP implementeren je oplevert

Een agent die de taak op je site afmaakt in plaats van halverwege af te haken, bij de agents die WebMCP ondersteunen, en dat betekent vandaag de desktop-browser van ChatGPT, het experiment van Brave en wat de trials van Chrome en Edge gebruikt. Ik heb nog geen gepubliceerde conversiecijfers gezien, en ik zou cijfers die zo vroeg opduiken wantrouwen.

Responsive sites wonnen in het mobiele tijdperk. Ik verwacht dat aanroepbare sites hetzelfde doen in het agent-tijdperk, en de winkels die deze maand zonder iets te doen WebMCP van Shopify kregen zijn de eerste test van die stelling.

Wie moet WebMCP implementeren?

• E-commerce: catalogus doorzoeken, productdetails, winkelwagen en checkout. Op een standaard Shopify Liquid-thema heb je deze al; kijk wat Shopify namens jou heeft aangezet.
• Reizen en horeca: zoeken naar vluchten, hotels en huurauto's. Meerstapsboekingen werken, maar elke stap is een tool-aanroep op de pagina waar de agent is, want een paginaoverstijgende flow-definitie zit niet in de spec.
• SaaS-platforms: accountbeheer, configuratie, supporttickets. Laat agents beheertaken doen via goed gedefinieerde tools, met je bestaande permissies.
• Financiële dienstverlening: rekeningoverzichten, transactiehistorie, rekentools. Markeer read-only tools eerlijk en laat alles wat geld verplaatst aan de bevestigingsflow van de agent.
• Zorg: afspraken plannen, zorgverleners zoeken, herhaalrecepten. Gestructureerde tools met duidelijke inputschema's verminderen fouten in workflows waar een verkeerde klik gevolgen heeft.
• Vastgoed: woningen zoeken, hypotheekberekeningen, bezichtigingen inplannen.
• Uitgevers: ook read-only sites hebben baat bij de declaratieve API op hun zoekformulier.

Begin met je drukst gebruikte formulier. Een zoekformulier met WebMCP-attributen kost vijf minuten en maakt je belangrijkste functionaliteit aanroepbaar.

WebMCP versus andere agent-protocollen

Deze protocollen vullen elkaar aan. WebMCP regelt client-side browserinteracties, MCP regelt backend-toolverbindingen, A2A regelt coördinatie tussen agents, en OpenAPI documenteert je REST-API's.

Best practices

• Feature-detect, altijd. document.modelContext is bijna overal undefined; een kale aanroep geeft een error.
• Werkwoordgebaseerde, unieke namen: search_flights, book_hotel, submit_ticket. Een dubbele naam laat de registratie mislukken.
• Schrijf omschrijvingen voor een lezer die je site nog nooit gezien heeft. De omschrijving is het enige wat de agent heeft om te beslissen of hij de tool aanroept.
• Houd de lijst kort. Elke geregistreerde tool is context die de agent bij elk bezoek moet lezen. Bied de taken aan waar mensen echt voor komen.
• Accepteer ruwe invoer en normaliseer die zelf: datums in gewone taal, losse formaten, veelgemaakte typefouten.
• Geef fouten terug waar een agent iets mee kan, zoals "Invalid airport code. Expected a 3-letter IATA code like AMS or JFK" in plaats van een kale 400.
• Gebruik readOnlyHint naar waarheid, en nooit als manier om een bevestiging over te slaan die de gebruiker zou willen.
• Hergebruik je bestaande endpoints en checks. Een tool is een tweede voordeur naar logica die je al hebt. Hij mag geen achterdeur worden die om je autorisatie heen loopt.

Aan de slag

Je hoeft niet alles tegelijk te doen, dus hier de volgorde met het meeste rendement:

1. Zet WebMCP-attributen op je zoekformulier, de verandering met de meeste impact en de minste moeite
2. Annoteer je contact- en loginformulieren
3. Registreer imperatieve, read-only tools voor de opzoekacties waar mensen het vaakst om vragen: voorraad, prijzen, orderstatus
4. Open je site in de ChatGPT desktop-app en lees wat "Site tools" een agent laat zien
5. Voeg pas daarna tools toe die state veranderen, en zorg dat elke tool dezelfde checks doorloopt als de knop die hij vervangt

Bronnen

• WebMCP-specificatie (W3C Web Machine Learning Community Group-draft, augustus 2026)
• WebMCP declarative API explainer
• WebMCP implementation status (bijgewerkt 26 augustus 2026)
• Move the modelContext getter to Document (gemerged 27 mei 2026)
• WebKit-standpunt over WebMCP: oppose (juni 2026)
• Mozilla-standpunt over WebMCP: neutral (2026)
• Join the WebMCP origin trial (Chrome for Developers, juni 2026)
• WebMCP developer guide (Chrome for Developers)
• 15 updates from Google I/O 2026 (Chrome for Developers, lijst van bedrijven die met WebMCP experimenteren)
• WebMCP updates, clarifications, and next steps (Patrick Brosset, Microsoft, februari 2026)
• WebMCP: a much needed way to make agents play with rather than against the web (Christian Heilmann, februari 2026)
• Site tools, ChatGPT-documentatie (OpenAI, augustus 2026)
• WebMCP support for Liquid and Hydrogen storefronts (Shopify developer changelog, 5 augustus 2026)
• Give any website a WebMCP interface (Cloudflare, 6 augustus 2026)