WordPress en WebMCP: zo maak je je site agent-ready

27 mei 2026

WordPress en WebMCP: zo maak je je site stap voor stap agent-ready

Vorige week schreef ik een overzicht van wat WebMCP is en waarom het ook voor KMO’s telt. De reacties die ik kreeg, hadden bijna allemaal dezelfde vraag: hoe begin ik daar concreet aan? In deze blog beantwoord ik die vraag voor wie op WordPress draait. Dat dekt een groot deel van het Vlaamse KMO-landschap, en WordPress is meteen ook één van de makkelijkste startpunten voor een eerste WebMCP-implementatie.

Geen herbouw, geen migratie. Wel een gestructureerde uitrol in stappen, met een werkende pilot op het einde van een week. Hieronder leg ik uit wat je nodig hebt, welke valkuilen ik in de praktijk al zag, en welke acties echt de moeite waard zijn om als eerste tools te exposen.

Waarom WordPress een goede start is voor WebMCP

Drie redenen waarom WordPress relatief eenvoudig is om mee te beginnen, zelfs in een Draft-stadium van de spec:

1.De WordPress Abilities API. WordPress kreeg in 2025 een eigen Abilities API, een gestandaardiseerde manier om custom acties (een offerteformulier, een productzoekopdracht, een afsprakenboeking) als herbruikbare blokken te exposen. Die infrastructuur ligt klaar om automatisch gekoppeld te worden aan WebMCP.

2.De webmcp-abilities plugin. Code-atlantic publiceerde een bridge-plugin die je WordPress Abilities automatisch beschikbaar maakt als WebMCP-tools via navigator.modelContext. Voor wie geen developer in huis heeft, schakelt dit het hele JavaScript-gedeelte uit handen.

3.De declaratieve API. Voor bestaande contactformulieren of zoekvelden volstaat het om twee HTML-attributen toe te voegen. Geen build-process, geen plugins als je dat niet wil. Je kunt dus heel klein starten en uitbreiden.

Wat heb je nodig voor je begint

→Een WordPress-site op HTTPS. WebMCP werkt enkel op beveiligde verbindingen. Wie nog op HTTP draait, lost dat eerst op.

→WordPress 6.9 of nieuwer en PHP 8.2 of hoger, voor de modernste hooks rond de Abilities API.

→Een origin trial token voor Chrome 149. Gratis aan te vragen via Google Chrome Origin Trials. Plak je vervolgens als meta-tag in de site-header of als HTTP header.

→De Model Context Tool Inspector, een Chrome-extensie waarmee je tools test, JSON-schema’s valideert en simuleert hoe een agent ze aanroept. Onmisbaar tijdens ontwikkeling.

→Een correct opgezette conversie tracking. Vanaf het moment dat agents tools aanroepen, moet je dat meten als apart kanaal, anders weet je nooit wat het oplevert.

Stap 1: kies je eerste twee tools (geen tien)

Een veelgemaakte fout: meteen vijf of zes tools willen registreren omdat dat completer voelt. Doe het niet. Start met één of twee tools waar je echt waarde uit haalt en die je goed kunt testen. Voor een dienstverlener zijn dat doorgaans:

→Een contact_request of request_quote tool, die het bestaande contactformulier exposeert als agent-actie. Read-write, dus altijd met bevestigingsstap.

→Een search_content of search_services tool, die de doorzoekbaarheid van je dienstenpagina’s of blog blootlegt. Read-only, dus geen bevestiging nodig, ideaal voor agents om jouw site te scannen zonder schermafbeeldingen.

Voor een webshop ligt het anders: daar zijn search_products, add_to_cart en eventueel get_product_details de logische eerste set. Begin altijd vanuit wat agent-gedrag jou geld oplevert, niet vanuit wat technisch makkelijk is.

Stap 2: installeer webmcp-abilities

Upload en activeer de webmcp-abilities-plugin via WordPress-admin of via SFTP, afhankelijk van je hosting. Na activatie verschijnt er een nieuw menu-item waar je per ability kunt bepalen of die geëxposeerd wordt als WebMCP-tool. Standaard staat alles uit: je kiest zelf wat je openzet.

Voor wie geen WordPress Abilities heeft (oudere sites, sites zonder custom plugins): de plugin kan ook de standaard Search-functie en geregistreerde contactformulieren van plugins zoals Contact Form 7 en WPForms automatisch herkennen. Klik aanvinken, beschrijving aanpassen, klaar.

Stap 3: schrijf goede tool-beschrijvingen

Dit is het deel waar de meeste mensen te snel over willen. De beschrijving die je aan een tool meegeeft, bepaalt of een AI-agent jouw tool kiest boven die van een concurrent, en of hij ze correct gebruikt. Dit nieuwe vakgebied heet ondertussen TDO of Tool Description Optimization. Het wordt de derde laag in je zichtbaarheidsstrategie, naast klassieke SEO en AI Search Optimization.

Drie principes die in mijn eerste tests al verschil maakten:

→Wees specifiek over wat de tool doet. Niet “verstuur formulier”, wel “vraag een offerte aan voor SEO-, Google Ads- of conversiediensten”.

→Beschrijf wanneer de tool te gebruiken. Een agent kiest tussen tools op basis van context. Vermeld expliciet “voor wie een prijsindicatie of voorstel op maat wenst”, zodat de agent weet wanneer dit de juiste keuze is.

→Maak de input-velden zelfsprekend. Velden zoals email of phone zijn duidelijk. Velden zoals message verdienen een korte description die uitlegt wat je verwacht (“korte omschrijving van het project of de vraag”).

Stap 4: test met de Tool Inspector vóór je live gaat

Installeer de Model Context Tool Inspector in Chrome, open je site, en bekijk welke tools de browser ziet. Roep ze één voor één aan met testdata. Controleer drie dingen: vuurt de tool zoals verwacht, klopt het antwoord dat je terugstuurt, en geeft de browser de juiste permission prompt bij schrijfacties.

Een valkuil die ik al zag: een formulier dat normaal door Akismet of een captcha beschermd wordt, faalt stil wanneer een agent de tool aanroept. Werk je beveiliging eerst zo bij dat agent-inzendingen wel doorkomen (of waar nodig expliciet geweigerd worden met een leesbare foutmelding). Je wil niet dat een agent denkt dat hij een offerte heeft aangevraagd terwijl er niets in je inbox is beland.

Stap 5: meet agent-interacties als apart kanaal

Vanaf het moment dat agents tools aanroepen, ontstaat er een nieuw kanaal dat je analytics standaard niet zien. Voeg in elke tool een logging-stap toe naar bijvoorbeeld GA4 of je eigen database: welke tool, welke parameters, welke uitkomst, hoe vaak. Zonder die meting weet je niet of WebMCP rendement oplevert, en kun je je tool-beschrijvingen niet bijsturen.

Dit raakt ook aan de bredere problematiek van conversiemeting in een agent-tijdperk. Ik schreef daar eerder over in deze blog over client-side tracking-problemen. Agents zijn nog onvoorspelbaarder dan browsers wat betreft cookies en consent, dus een server-side meetopzet maakt het verschil tussen weten en gokken.

Veelvoorkomende valkuilen

→Te veel tools tegelijk. Een agent die kiest uit drie heldere tools werkt veel beter dan een agent die door dertien moet ploegen. Begin klein.

→Read en write door elkaar. Markeer tools die alleen data ophalen expliciet als readOnlyHint: true. Dat voorkomt onnodige permission prompts en verbetert de gebruikerservaring drastisch.

→Vage descriptions kopiëren van een tutorial. Letterlijke voorbeelden uit de documentatie zien er goed uit, maar werken slechter dan eigen, contextspecifieke beschrijvingen.

→Vergeten dat dit GDPR-relevant is. Een tool die een naam en e-mailadres ontvangt via een agent, vraagt om een doordachte consent- en bewaarpolicy. Werk samen met wie je DPO of privacy-aanspreekpunt is.

→Tools live zetten zonder fallback voor browsers die geen WebMCP ondersteunen. Firefox en Safari blijven voorlopig zonder support. Je formulieren moeten blijven werken voor menselijke bezoekers, los van WebMCP.

Wat een eerste implementatie realistisch kost

Voor een WordPress-site met twee tools (een contact_request en een search_content), volledig getest en met basis-analytics: reken op 2 à 4 dagen werk. Dat is inclusief de plugin installeren, descriptions schrijven en testen, een origin trial token aanvragen, en analytics opzetten. Voor een webshop met drie tot vijf tools (productzoek, productdetails, winkelmandje) loopt dat op tot een werkweek of twee, afhankelijk van hoe goed je productdata gestructureerd is.

Wat het oplevert is moeilijker te becijferen vandaag, omdat het volume aan agent-verkeer nog gering is. Maar het schaalmodel is wel duidelijk: hoe meer mensen Gemini, ChatGPT of Claude gebruiken om dingen voor zich te laten regelen, hoe meer voorsprong je hebt als jouw tools al klaarstaan. Mijn inschatting: in 12 maanden zal het verschil tussen agent-ready en niet-agent-ready in sommige sectoren al zichtbaar zijn op de bottom line.