WebMCP: De standaard die AI-agenten in staat stelt op websites te handelen

Laatste update: augustus 2026

AI-agenten kunnen al browsen, formulieren invullen en acties uitvoeren op het web. Het probleem zit in hoe ze dat doen. De dominante aanpak - een headless browser opstarten, klikken injecteren via gesynthetiseerde CSS-selectors en gerenderde HTML scrapen - is traag, breekbaar en onbetrouwbaar in productie. WebMCP is de specificatie die dit verandert.

Wat is WebMCP en hoe verschilt het van MCP?

WebMCP breidt Anthropics Model Context Protocol (MCP) - de open standaard die bepaalt hoe AI-agenten gestructureerde tools ontdekken en aanroepen - uit naar op het web gehoste oppervlakken. Waar MCP de agent-naar-server-communicatie in gecontroleerde omgevingen regelt, stelt WebMCP elke website in staat zichzelf te beschrijven als gestructureerde, aanroepbare tools die agenten ontdekken en aanroepen zonder menselijk browsergedrag te simuleren. Het integratieoppervlak verschuift van de DOM naar een gedeclareerd actieschema.

Het praktische verschil: MCP vereist een speciaal gebouwde serverintegratie. WebMCP stelt een publieke website in staat een eigen manifest voor capability discovery te publiceren, op dezelfde manier waarop een REST API zichzelf beschrijft via een OpenAPI-specificatie.

[Voeg een citaat van een Seven Labs-ingenieur in over de operationele kostenreductie van gestructureerde WebMCP-tool-aanroepen versus headless browser-agenten in productie]

Waarom browserautomatisering faalt op enterprise-schaal

Elk team dat AI-agenten op basis van browserautomatisering in productie heeft gebracht, herkent het patroon. De demo werkt. In week drie van productie breekt een frontend-wijziging de agent en niemand merkt het totdat een klant klaagt.

Browser-use-agenten - agenten die een browser besturen om met het web te communiceren - hebben drie structurele faalwijzen die niet bestaan in het WebMCP-model:

1. Selectorfragiliteit. CSS-selectors en XPath-expressies breken bij elke DOM-herstructurering. Het hernoemen van een klasse is een breaking change voor de agent.
2. Rekenkundige overhead. Een Chromium-instantie kost 200–400 MB RAM per sessie. Bij 50 gelijktijdige agent runtime-sessies is dat 10–20 GB verbruikt voordat een enkele zakelijke actie is voltooid.
3. Compliance-risico. Een website benaderen door een menselijke gebruiker te simuleren kan de servicevoorwaarden schenden. Gestructureerd tool calling via een gedeclareerde interface niet.

In meer dan 50 AI-implementaties in productie heeft Seven Labs vastgesteld dat de operationele ondersteuningslast voor browser-gebaseerde agenten ongeveer drie keer hoger is dan voor vergelijkbare gestructureerde API-integraties. De agenten zijn niet het probleem. Het interfacecontract is dat wel.

Hoe WebMCP het interactiecontract tussen agent en website definieert

Een site die WebMCP implementeert publiceert een manifest - doorgaans op

/.well-known/webmcp.json

1{
2  "schema_version": "1.0",
3  "site": "https://example.com",
4  "tools": [
5    {
6      "name": "submit_inquiry",
7      "description": "Submit a product inquiry",
8      "inputSchema": {
9        "type": "object",
10        "properties": {
11          "name": { "type": "string" },
12          "email": { "type": "string", "format": "email" },
13          "message": { "type": "string", "maxLength": 2000 }
14        },
15        "required": ["name", "email", "message"]
16      }
17    }
18  ]
19}

Dit elimineert selectorfragiliteit, vermindert de rekenkundige overhead en creëert een auditeerbare, op toestemmingen gebaseerde interface. Een toegankelijkheidsgraph van wat de agent mag aanraken vervangt een onbeperkte crawl van de volledige DOM.

Gestructureerde webinteractie maakt ook intentieherkenning op serverniveau mogelijk - de website weet wat de agent probeert te doen voordat die het doet, wat rate limiting, auditlogging en human-in-the-loop-escalatiepaden mogelijk maakt die onmogelijk zijn wanneer agenten als anonieme browsersessies binnenkomen.

WebMCP vs MCP vs browserautomatisering: een vergelijking

Wat verandert WebMCP aan agentisch productontwerp?

WebMCP verandert agentisch productontwerp door agenttoegankelijkheid tot een eersteklas productvereiste te maken - niet als een achterafgedachte over scraping. Elk webproduct dat in 2026 AI-agentverkeer verwacht, heeft een WebMCP-manifest nodig als het wil dat die agenten betrouwbaar kunnen communiceren. Zonder manifest vallen agenten terug op computer-use-simulatie - wat langzamer, duurder is en de site geen zicht of controle geeft over hoe de interface wordt geconsumeerd.

Voor teams die bouwen op onze AI-platform- en agentengineering-services, behandelen we op agenten gerichte interfaces al als een apart productoppervlak. Hetzelfde geldt voor ons werk aan automatiseringssystemen, waar agenten moeten communiceren met externe webtools in meerstappenworkflows - en een gebroken selector midden in een workflow een operationeel incident is, niet zomaar een demomislukking.

De verschuiving is vergelijkbaar met mobiel: teams die mobile in 2012 als eersteklas interface behandelden, hoefden in 2015 niet alles van de grond af aan te herbouwen. Teams die agenttoegankelijkheid nu als prioriteit behandelen, hoeven in 2028 niet te migreren van browserautomatisering.

Hoe moeten engineeringteams zich voorbereiden op WebMCP?

Engineeringteams moeten zich voorbereiden op WebMCP door te controleren welke weboppervlakken AI-agenten al bezoeken, en vervolgens gestructureerde manifesten voor die oppervlakken te publiceren voordat agenten standaard terugvallen op browsersimulatie.

Concrete stappen:

1. Inkomend agentverkeer controleren. Serverlogs doorzoeken op GPTBot, ClaudeBot, PerplexityBot, Google-Extended en Applebot-Extended. Als ze uw site bezoeken, proberen agenten al structuur uit uw pagina's te halen.
2. Hoogwaardige interactieoppervlakken identificeren. Contactformulieren, boekingsflows, zoekeindpunten en productaanvraagpagina's zijn de voornaamste kandidaten.
3. Een
   textCopy

   /.well-known/webmcp.json

   -manifest publiceren. Begin met twee à drie tools. Het manifest hoeft niet elke pagina te dekken - alleen de oppervlakken waar betrouwbare agentinteractie van belang is.
4. Authenticatiebereiken definiëren. Specificeer welke tools inloggegevens vereisen en in welk formaat agenten deze moeten aanleveren.
5. Testen met een MCP-compatibele runtime. Claude, GPT-4o met tool-use en open-source agentframeworks waaronder LangGraph ondersteunen allemaal MCP-compatibel tool calling, dat WebMCP uitbreidt.

Dit sluit direct aan op de orkestratiepatronen in ons multi-agentsystems-engineeringwerk - WebMCP is het complement op weblaagniveau van de agent-naar-agent-coördinatielaag.

Is WebMCP nu al gereed voor productie?

WebMCP is in opkomst maar implementeerbaar. De specificatie wordt actief ontwikkeld en sluit al aan op de bestaande tool-calling-conventies van MCP, die vandaag in productie worden gebruikt. Het implementeren van een

webmcp.json

Het risico zit niet in vroeg implementeren. Het risico zit in het bouwen van de volgende twee jaar aan agentisch productoppervlak op browserautomatisering om vervolgens te moeten migreren wanneer de standaard rijpt en uw concurrenten al schone, gestructureerde interfaces hebben.

Seven Labs ontwerpt en levert productie-agentsystemen, inclusief op agenten gerichte webinterfacearchitectuur. Als uw product betrouwbaar moet kunnen communiceren met AI-agenten - of voor hen toegankelijk moet zijn - start dan een gesprek met ons team.