Wat is WebMCP? Uitleg in het Nederlands

WebMCP is een voorgestelde open webstandaard waarmee een website eigen functies, zoals een afspraak plannen of een offerte aanvragen, als tools registreert in de browser. Een AI-agent roept die tools rechtstreeks aan binnen de sessie van de bezoeker, in plaats van knoppen en formulieren na te bootsen. De specificatie is nog een concept, geen afgeronde W3C-standaard.

Door Enrico Clein, oprichter van WebMCP.nl. Elke claim op deze pagina verwijst naar een primaire bron of naar een kennisbankartikel waarin die bron staat.

Hoe werkt WebMCP?

Een pagina die WebMCP ondersteunt, registreert een of meer tools op document.modelContext. Elke tool heeft een naam, een feitelijke beschrijving, een inputSchema dat vastlegt welke invoer nodig is, en een execute-functie. Een ondersteunende browser-agent ziet welke tools de pagina aanbiedt, kiest op basis van de vraag van de gebruiker een passende tool en vult de argumenten in volgens het schema. De browser voert daarna de execute-functie uit in de pagina zelf. Die functie roept doorgaans dezelfde backend aan als je gewone formulier, met de sessie en rechten die de bezoeker al heeft. Het resultaat gaat terug naar de agent, die het aan de gebruiker meldt of een volgende stap zet. Zonder ondersteunende browser of agent verandert er niets: de feature-check slaat de registratie over en je site werkt zoals altijd. Daarom bouw je WebMCP als progressive enhancement bovenop je bestaande site.

Het verschil met een agent die je site ‘gewoon’ bedient, zit in die expliciete afspraak. Zonder WebMCP moet een agent je interface afleiden: welk veld is de datum, welke knop verstuurt, wat betekent deze foutmelding? Met WebMCP vertelt je site zelf welke handeling er bestaat, welke invoer die verwacht en wat er terugkomt. Dat maakt een taak voorspelbaarder, maar niet vanzelf correct: een tool maakt bestaande bedrijfslogica niet betrouwbaarder. Als een prijsberekening fout is of een endpoint te ruime rechten accepteert, blijft dat probleem bestaan. De browserlaag maakt de functie toegankelijker voor een agent; jouw applicatie blijft verantwoordelijk voor het resultaat.

Wie staat erachter, en hoe ‘af’ is het?

WebMCP is een voorstel van de Web Machine Learning Community Group. Het document heeft de status Draft Community Group Report: geen W3C Standard en geen standards-track Recommendation. Microsoft is co-auteur van het voorstel; Google draait de eerste origin trial in Chrome. Het voorstel, de issues en de wijzigingsgeschiedenis staan openbaar in de repository webmachinelearning/webmcp op GitHub.

Die geschiedenis laat zien dat de API nog beweegt. Op 5 maart 2026 verdwenen provideContext() en clearContext() uit de spec (PR #132). Op 26 maart 2026 kwam AbortSignal als manier om een registratie op te ruimen en verdween unregisterTool() (PR #147). Op 21 juli 2026 verhuisde de API-root naar document.modelContext; navigator.modelContext is sinds Chrome 150 deprecated maar werkt nog tijdens de origin trial. En Chrome markeert JSON-tekst als invoer voor executeTool vanaf versie 155 als verouderd, ten gunste van een JavaScript-object. Tutorials die een van die oude vormen gebruiken, zijn verouderd. Zo controleer je welke API-versie je code gebruikt.

Twee manieren om tools aan te bieden

Chrome documenteert twee routes: een JavaScript-route (de imperatieve API) en een declaratieve route via HTML-formulieren. Ze lossen hetzelfde probleem op, maar verschillen in controle, onderhoud en ondersteuning door agents.

De imperatieve API: registerTool()

Met document.modelContext.registerTool() registreer je een tool in JavaScript. Je bepaalt zelf de naam, de beschrijving, het invoerschema en wat execute doet. Doe eerst een feature-check, zodat bezoekers zonder ondersteuning niets merken, en koppel execute aan de bestaande backend-logica van je formulier:

// document.modelContext is de actuele API-root.
const mc = document.modelContext;

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

  await mc.registerTool({
    name: "plan_afspraak",
    description: "Plan een afspraak. Retourneert bevestiging en tijdslot.",
    inputSchema: {
      type: "object",
      properties: {
        datum: { type: "string", format: "date" },
        tijd:  { type: "string" }
      },
      required: ["datum", "tijd"]
    },
    async execute({ datum, tijd }) {
      // Dezelfde backend als het gewone formulier.
      const res = await fetch("/api/afspraak", {
        method: "POST",
        body: JSON.stringify({ datum, tijd })
      });
      return { content: [{ type: "text", text: await res.text() }] };
    }
  }, { signal: controller.signal });

  // Verdwijnt deze view (bijv. navigatie in een SPA)? Dan:
  // controller.abort();
}

Drie ontwerpregels maken het verschil. Houd schema's strak, met types, enums en verplichte velden, zodat de agent niets hoeft te raden. Schrijf beschrijvingen feitelijk (wat doet de tool, wat komt terug) en nooit als instructiekanaal richting de agent. En geef in een single-page-app een AbortSignal mee, zodat je de tool opruimt wanneer de bijbehorende view verdwijnt. Alleen als je aantoonbaar Chrome 149 moet ondersteunen, is een aparte compatibiliteitslaag voor navigator.modelContext zinvol.

De declaratieve API: je bestaande formulier annoteren

Bij de declaratieve route voeg je attributen toe aan een bestaand HTML-formulier, zoals tooldescription op het formulier en toolparamdescription op de velden. De browser zet die om naar toolmetadata. Dat is aantrekkelijk als je al een goed, gelabeld formulier hebt:

<form id="offerte"
      toolname="vraag_offerte_aan"
      tooldescription="Vraag een vrijblijvende offerte aan. Plaatst geen opdracht.">
  <label for="dienst">Dienst</label>
  <input id="dienst" name="dienst"
         toolparamdescription="De gewenste dienst, bijvoorbeeld onderhoud">
  <label for="email">E-mail</label>
  <input id="email" name="email" type="email">
  <button type="submit">Offerte aanvragen</button>
</form>

Controleer de exacte attribuutnamen in de Chrome-documentatie over de declaratieve API; ook hier beweegt de spec nog. Een open issue gaat bijvoorbeeld over taal en tekstrichting van declaratieve metadata, relevant voor meertalige sites.

De declaratieve route heeft een meetbaar extraatje: bij een door een agent gestarte inzending zet de browser SubmitEvent.agentInvoked. Gebruik dat voor analytics, nooit voor toegang, en tel ‘onbekend’ apart:

const form = document.getElementById("offerte");

form?.addEventListener("submit", (event) => {
  const signal = typeof event.agentInvoked === "boolean"
    ? (event.agentInvoked ? "webmcp" : "not-marked")
    : "unknown";
  console.info("form-submit-observation", { formId: form.id, signal });
});

Welke kies je?

Let vooral op de agent die je wilt bedienen. ChatGPT Site Tools ondersteunt momenteel een subset: JavaScript-tools op de hoofdpagina, zonder declaratieve tools en zonder tools in iframes. Een geannoteerd formulier kan dus binnen de browser-API passen en toch niet door die client worden ontdekt. Wil je vandaag in ChatGPT werken, dan begin je imperatief. De declaratieve route blijft interessant voor eenvoudige formulieren en voor het agentInvoked-signaal, in browsers die de declaratieve API ondersteunen. Lees wat ChatGPT precies ondersteunt.

Browserstatus

WebMCP is geen afgeronde standaard, dus ‘ondersteuning’ betekent per partij iets anders. Onderstaande samenvatting komt uit onze browsersupport-matrix, waar elke claim naast zijn primaire bron staat (laatst gecontroleerd 23 september 2026).

Voor je planning betekent dit: bouw voor wat vandaag echt kan (Chrome en Edge via de origin trial, ChatGPT Site Tools in de desktopapp) en zorg dat elke andere browser gewoon je normale site ziet. Trialdeelname, browserondersteuning en ondersteuning door een agent zijn drie aparte voorwaarden; test ze afzonderlijk.

WebMCP vs MCP vs llms.txt

De namen lijken op elkaar, maar lossen verschillende problemen op. Kort: llms.txt wijst informatie aan, MCP koppelt je backend en WebMCP maakt je site bedienbaar.

• llms.txt is een voorstel voor een tekstbestand dat bruikbare informatie aanwijst. Leesvoer, geen loket, en een voorstel, geen standaard; Google Search heeft het niet nodig.
• MCP (Model Context Protocol) verbindt een AI-applicatie via een server met tools en data. Jij regelt authenticatie en rechten; agents kunnen erbij, ook als niemand op je site is.
• WebMCP brengt dat idee naar de browser: je pagina biedt tools aan die een agent gebruikt binnen de sessie van je bezoeker, met diens rechten.

Je hebt ze niet automatisch alle drie nodig. De beslisregel: wil je agents systeem-tot-systeem bedienen, dan past een MCP-server; wil je dat de agent van je bezoeker je formulieren betrouwbaar kan gebruiken, dan registreer je WebMCP-tools. Vaak delen ze dezelfde backend-logica. De volledige vergelijking, met tabel en veelgestelde vragen, staat op WebMCP vs MCP vs llms.txt. Heb je al een API, lees dan ook wanneer WebMCP daar iets aan toevoegt.

Veiligheid

Een tool geeft een agent macht over je site, dus begrens die macht. De belangrijkste maatregelen uit onze kennisbank en de Chrome-beveiligingsgids:

• Schakel WebMCP uit waar je het niet nodig hebt. De conceptspecificatie documenteert sinds 15 september 2026 (PR #275) expliciet de responseheader Permissions-Policy: tools=(). Die blokkeert de API voor het document en alle onderliggende frames. Controleer de werking in je doelbrowser.
• Houd je browser bij. Chrome 153 (Stable op 8 september 2026) repareerde CVE-2026-87521, een informatielek in WebMCP dat een al gecompromitteerd rendererproces veronderstelde.
• Reken op indirecte promptinjectie. Tekst die een tool teruggeeft, bijvoorbeeld een supportticket, kan instructies bevatten. Geef een leestool daarom geen verzendrechten en lever alleen de data die de taak vraagt.
• Autoriseer op de server, bij iedere actie. Een bestaande sessie is geen toestemming voor elk dossier, en een door de agent meegegeven account-ID mag nooit de autorisatie bepalen.
• Annotaties zijn uitleg, geen beveiligingsgrens. untrustedContentHint en consequentialHint helpen de client risico's te herkennen, maar vervangen geen controles in je applicatie.
• Uitsluiten is niet hetzelfde als maskeren. Een gemaskeerd toolresultaat bewijst niet dat een gevoelige waarde buiten het model bleef. Heeft de agent een waarde niet nodig, ontwerp dan dat hij haar niet ontvangt.

Verder lezen: WebMCP beveiligen en gevoelige velden uitsluiten of maskeren.

Aan de slag

Begin klein, met één taak waarvan je de uitkomst eenvoudig kunt controleren, en bouw pas daarna tools met klantgegevens of gevolgen. Een verstandige volgorde:

1. Meet waar je staat. De gratis AI-Ready Scan laat zien of je site al tools registreert en hoe de technische basis eromheen ervoor staat.
2. Kies de juiste tools. Begin bij het doel van de gebruiker, niet bij je formulieren: van klantdoel naar toetsbare toolset.
3. Test lokaal en daarna in de origin trial. Het stappenplan begint met een alleen-lezen demo en scheidt een lokale test van een test met een echte agent.
4. Controleer het resultaat, niet alleen de aanroep. Testen vanuit de terminal met agent-browser laat zien waarom een geslaagde uitvoering nog geen correct resultaat is.
5. Betrek je webbouwer. Stuur de technische one-pager door: actuele spec-surface, origin trial, valkuilen en voorbeeldcode.

Verdieping: alle WebMCP-artikelen per onderwerp

De kennisbank gaat per onderwerp dieper in op WebMCP. Elk artikel heeft een eigen bronnenlijst en een zichtbare wijzigingsdatum.

WebMCP gaat over bruikbaar zijn voor agents. Wil je eerst weten of AI-assistenten je überhaupt vinden en citeren, lees dan over AI-vindbaarheid.

Doe de gratis AI-Ready ScanStuur dit naar je webbouwer