Een browseragent ziet een knop en schat de positie ervan in. Dat kan werken. Maar een webapplicatie kan haar betekenis ook explicieter communiceren: deze actie zoekt naar beschikbare afspraken, verwacht een datum en geeft een lijst terug. Juist deze verschuiving van klikpositie naar beschreven tool maakt WebMCP interessant.
Volgens de gedocumenteerde status is WebMCP een experimenteel voorstel. De huidige explainer behandelt imperatieve registratie via JavaScript en document.modelContext. Declaratieve HTML-formuliertools worden apart onderzocht en maken momenteel geen deel uit van deze specificatie. De Chrome-overzichtspagina van 18 mei 2026 is daarom geen reden om in oktober een nieuwe universele browserfunctie te claimen.
Een tool begint met een afgebakende actie
Ons eigen voorbeeld heet “beschikbare afspraken vinden”. De taak ervan eindigt bij informatie. Het maakt geen reservering. De beschrijving zelf moet dit al duidelijk maken, zodat een agent een zoekresultaat niet verandert in een bevestigde afspraak.
De invoer bevat een datum en een aangeboden dienst. Het resultaat noemt dezelfde referentie samen met de beschikbare tijdsloten. Een losse waarde zoals “10:30” zou zwakker zijn: die kan bij een andere dag of dienst horen. Een gestructureerd resultaat is vooral nuttig als de vermeldingen ervan eenduidig te interpreteren zijn.
{
"tool": "find_slots",
"input": {
"date": "2030-04-12",
"service": "intro"
},
"effect": "read_only"
}Dit is ons lesschema, geen WebMCP-registratie die je zo kunt kopiëren. De toekomstige datum en de dienst zijn verzonnen. Het toont het contract dat een daadwerkelijke implementatie zou moeten vastleggen. Voor concrete API-syntaxis is de actuele experimentele documentatie leidend.
Ook fouten hebben een begrijpelijke betekenis nodig
Een ongeldige datum, geen beschikbare afspraken en een dienst die om technische redenen niet bereikbaar is, zijn drie verschillende resultaten. Als ze allemaal gewoon een lege lijst opleveren, zou de agent naar de oorzaak moeten raden. Het antwoord van de tool moet daarom een begrijpelijke status bevatten en de informatie die nodig is voor de volgende beslissing.
Hetzelfde geldt voor gedeeltelijke informatie. Is de zoekopdracht volledig, of ontbreken er nog gegevens? Hoort het antwoord bij het laatste verzoek? Heeft de persoon intussen de datum gewijzigd? Zulke vragen bestaan ongeacht of de interface via een screenshot of via een tool wordt aangesproken.
Een beschrijving is geen toestemming
Een correct invoerschema zegt welke vorm een verzoek moet hebben. Het bepaalt niet of de aanroeper deze informatie mag lezen. De applicatie moet haar eigen regels nog steeds zelf handhaven. Een mooi klinkende toolnaam is geen aanmelding en ook geen toegangscontrole.
Ook de overgang naar boeken heeft een eigen betekenis nodig. “Zoek naar beschikbare tijden” en “reserveer deze tijd voor mij” hebben verschillende gevolgen. Ze mogen niet ongemerkt samensmelten tot één functie. Een daadwerkelijke reservering zou rekening moeten houden met het bevestigde item en de bedoelde instructie.
Voor een eerste, onschuldige ontwerpoefening zijn vaste voorbeeldgegevens daarom voldoende. Beschrijf drie antwoordstatussen en bedenk welke volgende actie in elk geval redelijk zou zijn. Zo kun je testen hoe begrijpelijk het contract is, zonder een echte boeking of een bestaande WebMCP-runtime te veinzen.
WebMCP is niet automatisch een bestaande externe MCP-server
Het woord MCP komt in verschillende technische contexten voor. Een actie die aan de browserkant is beschreven, is alleen daardoor nog niet hetzelfde soort verbinding als een externe toolserver die via HTTP bereikbaar is. Voor een specifieke verbinding tellen de client, het transport, de aanmelding en de tools die daadwerkelijk worden aangeboden.
Bestaande externe MCP-toegang bewijst daarom niet dat een website WebMCP ondersteunt. Evenzo garandeert een experimenteel browservoorstel niet dat elke agent het al kan gebruiken. Dit onderscheid is praktisch: het voorkomt dat een vergelijkbare naam tot het verkeerde integratieplan leidt.
De overdraagbare vraag blijft duidelijk. Kan een applicatie uitdrukken welke actie, met welke invoer, welk resultaat en welk effect heeft? Hoe preciezer dit antwoord, hoe minder een agent hoeft te raden op basis van een positie op het scherm. Goede toolcontracten maken de speelruimte begrijpelijker; de regels van de applicatie blijven niettemin haar eigen verantwoordelijkheid.
Bronnen en status
Onderzoek en documentatie, stand per 25 oktober 2026. WebMCP · WebMCP-explainer.
