Safari is tegen WebMCP, en de W3C wil het breder maken. Wat betekent dat voor je site?

Door Enrico Clein · Gepubliceerd 7 november 2026 · 7 min lezen

WebMCP draait als proef in Chrome en Edge, en ChatGPT gebruikt het al. Een webstandaard wordt het pas als meer browsermakers meedoen. Eind oktober kwamen de betrokkenen bij elkaar op TPAC, de jaarlijkse bijeenkomst van de W3C, dit jaar in Dublin. Wat vinden Apple, Mozilla en de W3C ervan, wat is er besloten, en wat doe je ermee?

Waar de browsermakers staan

Elke browsermaker legt openbaar vast wat hij van een nieuw voorstel vindt. Voor WebMCP is dat nu het beeld.

Een implementatie in Safari of Firefox is er niet. Welke browsers WebMCP wel ondersteunen, houden we bij op browsersupport.

Waarom Apple tegen is

WebKit nam begin juni het standpunt ‘oppose’ in. De kern: kan een agent een site slecht bedienen, dan ligt dat aan de HTML van die site. Los dat op in HTML en ARIA, de laag die schermlezers gebruiken, zegt WebKit. Daar hebben gebruikers, hulpmiddelen en agents allemaal iets aan. Een aparte laag met JavaScript-tools alleen voor agents vindt WebKit de verkeerde oplossing.

WebKit ziet een agent als een hulpmiddel van de gebruiker, net als een schermlezer. Een site hoort zo'n hulpmiddel niet anders te behandelen. Met WebMCP kan dat wel: een site kan agents iets laten doen wat mensen in de gewone interface niet kunnen, of andersom. Verder kiest de agent een tool nog steeds op basis van een naam en een beschrijving in gewone taal. En onderdelen als toestemming van de gebruiker en de beveiliging tussen sites zijn in de specificatie nog niet uitgewerkt.

Google vroeg welke aanpassingen WebKit wel zou accepteren. Apple antwoordde op 17 juni dat het niet per onderdeel wil onderhandelen. Het stelt voor WebMCP opzij te leggen en eerst in een nieuwe groep vast te stellen wat het probleem precies is: schiet HTML tekort, schrijven sites slechte HTML, of zijn de modellen nog niet goed genoeg?

Waarom Mozilla neutraal is

Mozilla noemt WebMCP een mogelijk waardevolle manier om sites en agents op elkaar af te stemmen, maar met te veel open vragen om het volmondig te steunen. Een kwaadwillende site kan tools aanbieden die iets anders doen dan de pagina laat zien, bijvoorbeeld om gegevens te verzamelen of een agent te misleiden. Mozilla wil op zijn standpunt terugkomen als duidelijk is hoe sites WebMCP echt gebruiken.

Mozilla denkt intussen wel mee. In augustus stelde Mozilla voor om WebMCP breder te maken: een algemene manier om functies aan te roepen tussen vensters, frames en andere software, met agents als één van de gebruikers. Dat voorstel lag in Dublin op tafel.

Welke zorgen de TAG heeft

De TAG let bij de W3C op de samenhang van het web als geheel. Op 26 oktober deelde de TAG haar voorlopige zorgen, met de nadruk dat dit nog geen oordeel is. De TAG ziet de waarde: agents zijn nu traag en foutgevoelig, en tools helpen daarbij. Maar er zijn punten die volgens de TAG opgelost moeten zijn voordat WebMCP in browsers komt.

De grootste zorg is een ‘web voor agents’: tools die mensen en schermlezers niet kunnen bereiken. Sommige TAG-leden vrezen ook dat sites minder moeite doen voor goede, toegankelijke HTML, terwijl agents daar juist ook baat bij hebben. Zij willen daarom dat de formuliervariant van WebMCP eerst af is, vóór de JavaScript-variant.

Een kleiner punt raakt Nederlandse sites direct. Een tool in JavaScript neemt de taal van de pagina over en kan geen eigen taal aangeven. Staat je pagina in het Nederlands en schrijf je de beschrijving van een tool in het Engels, dan klopt die taalinformatie dus niet. Volgens de TAG maakt dat vooral uit voor kleinere modellen, die de taal van de beschrijving moeten beheersen.

Tot slot de naam. Volgens de TAG suggereert ‘WebMCP’ een band met MCP, het protocol van Anthropic, terwijl het voorstel alleen over het aanmelden van tools gaat. De TAG vraagt of er nog tijd is om het om te dopen, bijvoorbeeld tot ‘Tools’. Mozilla zei in juni hetzelfde. Besloten is daarover niets.

Wat er in Dublin is besloten

Op 27 oktober vergaderde de W3C-groep die WebMCP ontwikkelt. Uit de notulen halen we drie besluiten die voor site-eigenaren tellen.

De groep gaat onderzoeken of WebMCP een algemener hulpmiddel kan worden om functies aan te roepen, met agents als één van de gebruikers. Daarbij kijkt ze naar beveiliging en naar wat standaard geldt als een site een tool aanmeldt. Eerst komen er schetsen van de nieuwe vorm. Die moeten laten zien dat de API voor agents niet slechter wordt en voor ontwikkelaars niet lastiger.

De formuliervariant blijft een apart voorstel. Hij gaat pas terug de specificatie in als er ervaring is met echte gebruikers. Chrome brengt eerst de JavaScript-variant uit; dat schreven we op 15 oktober al.

De proeven in Chrome en Edge zijn verlengd. Volgens de voorzitter kwamen er voor de WebMCP Challenge, de wedstrijd van OpenAI en partners, meer dan 5000 inzendingen binnen. Over ChatGPT en WebMCP schreven we eerder.

Wat dit betekent voor je site

WebMCP gaat niet weg, maar ligt ook nog niet vast. De naam, de vorm van de API en de standaardinstellingen kunnen veranderen, en Safari doet voorlopig niet mee. Vier dingen kun je nu al doen.

Houd je tools dun. Laat een tool je bestaande formulier of functie aanroepen, zoals Kin doet met zijn offertetool. Verandert de API, dan pas je alleen de aanmelding aan en blijft je logica staan.

Meld alle tools op één plek aan. Dan is een wijziging in de API één aanpassing, in één bestand.

// tools.js: de enige plek waar je site WebMCP-tools aanmeldt.
// Verandert de vorm van de API, dan pas je alleen dit bestand aan.
export function meldToolAan(tool) {
  const context = document.modelContext;
  if (typeof context?.registerTool !== "function") return false;
  context.registerTool(tool);
  return true;
}

// De tool roept dezelfde functie aan als het formulier op de pagina.
import { berekenPremie } from "./premie.js";

meldToolAan({
  name: "calculate_premium",
  description: "Calculate the monthly premium for a Dutch postcode and house number. Uses the same calculation as the form on this page.",
  inputSchema: {
    type: "object",
    properties: {
      postcode: { type: "string" },
      huisnummer: { type: "string" },
    },
    required: ["postcode", "huisnummer"],
  },
  execute: (invoer) => berekenPremie(invoer),
});

Maak je gewone site goed bruikbaar. Safari-gebruikers krijgen voorlopig geen WebMCP, en agents zonder WebMCP lezen je pagina zoals hij is. Duidelijke labels bij velden, knoppen die echte knoppen zijn en formulieren met een naam helpen hen allemaal. Daar vragen WebKit en de TAG ook om. De gratis scan controleert onder meer of invoervelden een label hebben en knoppen een duidelijke tekst.

Geef agents niets wat mensen niet kunnen. Elke tool hoort bij een handeling die een bezoeker ook in de gewone interface kan doen. Precies daar maken WebKit en de TAG zich zorgen over, en het is het uitgangspunt van onze WebMCP-pagina: dezelfde taak, twee ingangen.

Wat je nu doet

Loop je eigen tools langs met deze vragen.

Hoe je klein begint zonder je hele site om te bouwen, lees je in wanneer een WebMCP-pilot de investering waard is. Op de Agentic Web Radar volgen we welke browsers en bedrijven WebMCP aanzetten.