MCP vs WebMCP: praten met een website of publieke dienst via AI.

De vraag verhuist van je website naar de assistent

Twintig jaar lang was het antwoord op "hoe bereiken klanten ons?" een website. Eerst met een telefoonnummer erop, later met een formulier, een webshop, een klantportaal. Wat al die vormen gemeen hebben: de klant komt naar jou toe, leert hoe jouw schermen werken en klikt zich een weg naar het antwoord.

Dat verandert. Steeds meer mensen stellen hun vraag eerst aan een AI-assistent. Niet "ik ga naar de site van de verhuurder", maar: "regel een bestelbus voor zaterdag". De assistent moet dan ergens terechtkunnen. Op dit moment zijn daar drie manieren voor, en ze verschillen enorm in betrouwbaarheid:

• Klikken als een mens. De assistent opent je website en probeert knoppen en formulieren te begrijpen. Dat werkt soms, is traag en breekt bij elke wijziging in je ontwerp.
• Een publieke MCP-server. Jij biedt een set afgebakende handelingen aan die de assistent rechtstreeks kan aanroepen. Betrouwbaar, en het werkt vandaag.
• WebMCP. Je webpagina vertelt in de browser aan de assistent welke handelingen er mogelijk zijn. Veelbelovend, maar nog in de proeffase.

De tweede en derde lijken op elkaar en worden daarom vaak door elkaar gehaald. Dit artikel legt uit wat het verschil is, wat je vandaag al kunt bouwen en in welke volgorde je dat het beste doet.

Wat is een publieke MCP-server?

Het Model Context Protocol is de open standaard die Anthropic eind 2024 introduceerde om AI-modellen aan externe systemen te koppelen. Een MCP-server biedt tools aan: handelingen met een naam, een omschrijving in gewone taal en een vaste set invoervelden. De assistent leest die omschrijvingen en beslist zelf welke tool bij de vraag van de gebruiker past.

De meeste MCP-servers zijn intern: een team dat in gewone taal met de eigen bedrijfsdata praat. Een publieke MCP-server draait dat om. Hij is bedoeld voor mensen buiten je organisatie — klanten, leden, inwoners, partners — die hem aan hun eigen assistent koppelen. Vanaf dat moment is jouw dienst één van de dingen waar hun assistent bij kan, naast hun agenda, hun mail en hun documenten.

Grote softwareleveranciers doen dit al. Stripe host een eigen MCP-server met een officiële connector voor Claude en ChatGPT, en Moneybird biedt een AI-koppeling waarmee klanten hun administratie aan ChatGPT, Claude of Mistral verbinden. Wat voor hen geldt, geldt net zo goed voor een verhuurbedrijf, een groothandel of een zorgaanbieder: klanten willen bij hun eigen gegevens, op de plek waar ze toch al werken.

Een publieke MCP-server is geen chatbot op je website. Het is het omgekeerde: jouw dienst wordt beschikbaar in de assistent die je klant al gebruikt.

Praten met een dienst: hoe dat eruitziet

Het helpt om het concreet te maken. Een paar voorbeelden van vragen die een klant aan de eigen assistent stelt, en die via een publieke MCP-server bij jouw systeem terechtkomen:

• Verhuur en reserveringen — "Wat is er zaterdag nog vrij, en zet een bestelbus in optie tot morgen." De assistent vraagt beschikbaarheid op, legt de optie vast en zet de afspraak in de agenda van de klant.
• Webshop en groothandel — "Bestel hetzelfde als vorige maand, maar dan met dubbel zoveel koffiebonen." De assistent haalt de vorige order op, past hem aan en legt hem ter bevestiging voor.
• Afspraken en planning — "Verzet mijn afspraak van dinsdag naar een middag later in de week." Geen wachtrij aan de telefoon, geen inlogscherm.
• Klantportaal — "Welke facturen staan er nog open en wanneer vervalt de eerste?" Dezelfde gegevens als in het klantportaal, zonder dat de klant hoeft te weten waar het staat.
• Publieke diensten — "Wanneer wordt het oud papier opgehaald op mijn adres?" of "Welke vergunning heb ik nodig voor een dakkapel?" Openbare informatie, waar geen inlog voor nodig is.
• Kennis en advies — Onze eigen server op coding.agency/mcp doorzoekt de kennisbank en berekent een prijsindicatie. Wie een softwareproject overweegt, kan dat de eigen assistent laten uitzoeken.

Het patroon is steeds hetzelfde: de klant formuleert een doel, de assistent combineert jouw tools met wat hij verder weet — de agenda, eerdere gesprekken, andere diensten — en rondt het af. Voor de klant voelt dat als praten met je bedrijf. Voor jou is het een nieuw kanaal naast telefoon, mail en website, dat dag en nacht openstaat en geen wachttijd kent.

Wat is WebMCP?

WebMCP lost een verwant, maar ander probleem op. Het uitgangspunt is niet "de klant opent je site niet", maar juist "de klant heeft je site open, en laat een AI-agent in de browser het werk doen". Zo'n agent moet nu raden: welk veld is de voornaam, is dit een datumprikker, wat gebeurt er als ik op deze knop klik?

Google omschrijft WebMCP als een voorgestelde webstandaard waarmee een pagina gestructureerde tools aanbiedt aan AI-agents, zodat die niet meer de opbouw van de pagina hoeven uit te pluizen. Dat kan op twee manieren: declaratief, door bestaande HTML-formulieren van extra informatie te voorzien, en imperatief, door tools in JavaScript te registreren. Hoe die twee vormen werken, staat uitgebreid in ons artikel over Google WebMCP.

Het grote voordeel: de tools hangen aan de logica van je applicatie, niet aan het ontwerp. Je kunt je site opnieuw vormgeven zonder dat een agent de weg kwijtraakt. En omdat alles in de browser gebeurt, werkt de agent binnen de sessie van de bezoeker — die is al ingelogd, dus er is geen aparte koppeling of toestemming nodig.

MCP en WebMCP naast elkaar

Google is er zelf duidelijk over: WebMCP is geen uitbreiding of vervanging van MCP. Het zijn partners die verschillende behoeften dekken. MCP is op elk platform en op elk moment beschikbaar. WebMCP bestaat alleen op je website, en alleen zolang iemand die open heeft.

Een eenvoudige vuistregel: gaat het om iets dat de klant wil regelen zonder naar je toe te komen, dan is het MCP. Gaat het om een agent die de klant helpt terwijl die op je site is — een ingewikkeld formulier, een configurator, een boekingsproces in vijf stappen — dan is het WebMCP.

Hoe ver is WebMCP?

Hier is nuchterheid op zijn plaats. Google kondigde op 9 juni 2026 aan dat WebMCP vanaf Chrome 149 als origin trial beschikbaar is. Een origin trial is een tijdelijk programma: je registreert je domein, krijgt een token en kunt de functie aanzetten voor bezoekers met een geschikte Chrome-versie. Voor lokaal testen is er een vlag in Chrome.

Dat betekent ook wat het niet is:

• Geen vaste standaard. De documentatie zegt zelf dat de specificatie nog in discussie is en kan veranderen. Wat je nu bouwt, moet je mogelijk aanpassen.
• Alleen Chrome. Andere browsers ondersteunen het nog niet. Bezoekers met Safari of Firefox merken er niets van.
• Er moet een mens bij zijn. De agent moet je site daadwerkelijk bezoeken om de tools te ontdekken, en volledig onbemand gebruik wordt niet ondersteund.
• Technische eisen. WebMCP werkt alleen in documenten met origin-isolatie en valt onder een eigen permissions policy; ingesloten pagina's van een ander domein hebben expliciete toestemming nodig. Google heeft de beveiliging van WebMCP-tools apart uitgewerkt.

Kortom: het is het moment om ermee te experimenteren en je architectuur erop voor te bereiden, niet om er je klantcontact van afhankelijk te maken.

Wanneer kies je wat?

In de praktijk is het geen keuze tussen twee, maar een volgorde.

Stap één: een MCP-server. Die werkt vandaag, in de assistenten die mensen al gebruiken. Je bouwt hem bovenop de logica die je al hebt: dezelfde regels voor beschikbaarheid, prijzen en rechten als je website en je API. Het meeste werk zit niet in het protocol, maar in het kiezen van de juiste tools en het schrijven van omschrijvingen die een taalmodel goed begrijpt. Meer daarover in een MCP-server bouwen voor je website.

Stap twee: WebMCP als dunne laag. Heb je die tools eenmaal, dan is WebMCP weinig meer dan dezelfde handelingen ook in de browser aanbieden. "Controleer beschikbaarheid" is dezelfde functie, of hij nu door een MCP-server of door een pagina wordt aangeboden. Wie stap één netjes doet, heeft stap twee grotendeels cadeau.

Wat je in beide gevallen nodig hebt is een applicatie waarin de logica los staat van de schermen. Zit je beschikbaarheidscontrole verweven in de code van één formulier, dan is hij voor geen van beide bruikbaar. Dat is de echte voorbereiding op het "agent-ready" web: niet een nieuw protocol leren, maar zorgen dat je bedrijfsregels op één plek staan.

Veiligheid: je zet een deur open naar buiten

Een interne MCP-server wordt gebruikt door collega's die je kent. Een publieke server staat open voor iedereen, en voor elk AI-model. Dat vraagt om meer dan goede bedoelingen.

• Openbaar en persoonlijk scheiden. Openingstijden, beschikbaarheid en productinformatie kunnen zonder inloggen. Alles wat over één specifieke klant gaat, vraagt om inloggen. De MCP-standaard schrijft daarvoor OAuth voor: de klant geeft de assistent toestemming, en kan die ook weer intrekken.
• Nooit meer dan het portaal. De assistent mag precies zien en doen wat de klant zelf in het klantportaal zou kunnen. Geen tool mag daar een uitzondering op zijn.
• Bevestigen voordat het telt. Een bestelling plaatsen, een afspraak annuleren, geld terugstorten: de assistent bereidt voor, de mens bevestigt. Stripe doet dit bij zijn eigen MCP-server ook: voor handelingen als terugbetalingen is een menselijke goedkeuring nodig.
• Limieten. Een model dat in een lus raakt, kan in een minuut honderden aanroepen doen. Beperk het aantal aanroepen per gebruiker en de hoeveelheid gegevens per antwoord.
• Tekst is geen opdracht. Alles wat een tool teruggeeft — een productomschrijving, een notitie van een klant — kan door een model als instructie worden opgevat. Lees meer over prompt injection en hoe je het beperkt.
• Loggen. Leg vast welke tool wanneer door wie is aangeroepen. Bij een geschil wil je kunnen laten zien wat er is gebeurd.

Voor de AVG verandert er minder dan je zou denken: de klant kiest zelf een assistent en geeft die toegang tot de eigen gegevens. Jouw verantwoordelijkheid is dat je niet meer prijsgeeft dan nodig is, dat toegang intrekbaar is en dat je vastlegt wat er is opgevraagd.

Hoe vindt een assistent je server?

Dit is het onderdeel dat het minst is uitgekristalliseerd. Op dit moment voegt een gebruiker een MCP-server meestal zelf toe als connector, met een adres dat jij publiceert — op je website, in je klantportaal, in de bevestigingsmail. Daarnaast kun je de server vindbaar maken met een bestand op je eigen domein en via llms.txt, en ontstaan er openbare registers van MCP-servers.

Het lijkt op de begintijd van zoekmachines: wie vroeg vindbaar is, heeft een voorsprong zodra assistenten zelf op zoek gaan naar diensten. Hoe wij discovery hebben ingericht voor onze eigen server, staat in dit artikel.

Hoe wij het zelf doen

We schrijven hier niet over vanaf de zijlijn. De website van Coding Agency heeft een publieke MCP-server in productie, gebouwd in Laravel. Wie hem koppelt, kan de kennisbank doorzoeken, een prijsindicatie voor een softwareproject laten berekenen en een contactverzoek indienen. Geen van die tools vraagt om inloggen, omdat ze alleen openbare informatie ontsluiten — precies de scheiding die we hierboven beschrijven.

Sinds kort doen we ook stap twee. Dezelfde alleen-lezen tools bieden we via WebMCP in de browser aan: bij het laden van de pagina vraagt een klein script de toollijst op bij onze MCP-server en registreert die tools bij de browser. Elke aanroep gaat terug naar dezelfde server. Er staat dus geen tweede versie van de logica in JavaScript. Het contactformulier hebben we declaratief leesbaar gemaakt: een agent vult de velden in, maar de bezoeker klikt zelf op verzenden. Dat is precies de volgorde die we hierboven aanraden, en het bewijs dat WebMCP een dunne laag is als de MCP-server er al staat.

Voor klanten bouwen we dezelfde opzet op hun eigen applicatie: eerst de tools die alleen lezen, daarna handelingen met een bevestigingsstap, met inloggen voor alles wat persoonlijk is. Wat er op die manier allemaal mogelijk is — ook voor je eigen team — staat op de pagina over de MCP-koppeling.

Conclusie

MCP en WebMCP worden vaak in één adem genoemd, maar ze beantwoorden verschillende vragen. Een publieke MCP-server maakt je dienst bereikbaar in de assistent van je klant, altijd en overal. WebMCP helpt een agent die al op je site is om je schermen te begrijpen. De eerste werkt vandaag en is de moeite van het bouwen waard. De tweede is een experiment in Chrome dat je in de gaten moet houden.

De verstandige volgorde is daarmee ook duidelijk: zorg dat je bedrijfslogica los staat van je schermen, bouw een MCP-server met een handvol goed gekozen tools, en voeg WebMCP toe zodra browsers het breed ondersteunen. Wie nu begint, is vindbaar op het moment dat klanten hun assistent vragen om het te regelen.