AI-assisted
Dit artikel is met behulp van AI opgesteld en geredigeerd. De ervaringen, voorbeelden en technische inhoud zijn van mijzelf.
Ik ben de afgelopen tijd wat aan het experimenteren met het koppelen van WordPress-installaties aan AI-chatapps. Het idee is interessant: niet alleen een AI-chatbot over je website laten praten, maar een AI-client daadwerkelijk toegang geven tot WordPress via het Model Context Protocol (MCP).
WordPress heeft daar sinds versie 7.1 ook steeds meer bouwstenen voor gekregen. Daarmee wordt het interessanter om WordPress als databron of zelfs als onderdeel van een AI-workflow te gebruiken.
Maar voordat je zover bent, moet je natuurlijk eerst verbinding maken.
En daar liep ik tegen een probleem aan.
Even terug naar augustus
Op 18 augustus deed ik een eerste poging om een WordPress-installatie via MCP aan Claude Desktop te koppelen. Ik had inmiddels wat gelezen over MCP en OAuth en het leek allemaal redelijk overzichtelijk.
De WordPress-kant had alleen nog geen standaard MCP-server die je zomaar kunt activeren. Ik volg verschillende Nederlandse WordPress-ontwikkelaars op social media en zo was ik eerder ook de Albert AI Butler plugin van Mark Jansen van YourMark tegengekomen.
De plugin zag er technisch interessant uit en het uitgangspunt was eigenlijk precies wat ik zocht: een MCP-server voor WordPress, inclusief OAuth-authenticatie.
Het idee was simpel:
- Installeer Albert op een WordPress-site.
- Gebruik de MCP-server-URL in je AI-client.
- De client ontdekt dat authenticatie nodig is.
- Je logt in op WordPress.
- Klaar.
Dat klonk goed.
In de praktijk was het minder eenvoudig.
Ik heb verschillende clients geprobeerd, waaronder Claude Desktop, de ChatGPT desktop-app, Jan en Open WebUI. Met een WordPress Application Password kreeg ik sommige dingen wel aan de praat, maar voor een minder technisch persoon is dat niet bepaald de ideale gebruikerservaring.
OAuth is hier veel logischer.
Alleen kreeg ik die OAuth-flow niet goed werkend.
“Dit zou toch gewoon moeten werken?”
Op 9 september kwam ik een post van Remkus de Vries tegen over precies dit onderwerp:
Daarin werd ook Albert AI Butler genoemd.
Dat maakte me opnieuw nieuwsgierig. Als dit inmiddels daadwerkelijk gebruikt en beschreven wordt, zou de OAuth-flow toch gewoon moeten werken?
Ik besloot het nog eens te proberen.
Dat leverde onder andere deze melding op in Claude:
Couldn’t register with sign-in service.
Ik begon daarom wat verder te graven en kwam uiteindelijk ook bij de MCP Inspector terecht. Dat hielp om iets beter te begrijpen wat er achter de schermen allemaal gebeurt, maar ik was zelf nog relatief nieuw met MCP en OAuth.
Dus op 14 september besloot ik Mark maar eens een berichtje te sturen.
Even de maker vragen
Ik ken Mark een beetje vanuit de WordPress-community. We hadden elkaar eerder gesproken via de WordPress Nederland Slack (wpnl.slack.com), dus ik stuurde hem daar een bericht met mijn bevindingen.
Mijn eerste vraag was eigenlijk heel simpel: zou Cloudflare of SiteGround misschien roet in het eten gooien?
Ik gaf hem mijn MCP-endpoint en de foutmelding uit Claude.
Mark gebruikte zelf primair Claude Desktop als MCP-client en dook er direct in. Al snel bleek dat Claude ondertussen iets aan zijn kant had veranderd in de manier waarop custom connectors en OAuth worden afgehandeld.
Dat was interessant, maar nog geen verklaring waarom het bij mij niet werkte.
We testten vervolgens een demo-installatie van Albert. Met de demo-URL kon ik wel door de OAuth-flow heen.
Claude stuurde me naar de Claude-loginpagina en daarna leek de flow verder goed te gaan.
Daarmee werd het zoekgebied kleiner.
Het zat dus waarschijnlijk niet fundamenteel in Albert, Claude of OAuth.
Wat was dan het verschil tussen de demo en mijn eigen WordPress-installatie?
Hallo /.well-known/
Bij OAuth en MCP spelen een aantal discovery-endpoints een belangrijke rol. Een client kan daarmee automatisch ontdekken waar authenticatie geregeld wordt en welke endpoints daarvoor beschikbaar zijn.
Een van die endpoints zit onder:
/.well-known/
En laat dat nou net een directory zijn waar SiteGround zelf iets mee doet.
Ik testte bijvoorbeeld:
https://www.remcotolsma.nl/.well-known/oauth-protected-resource
Maar in plaats van de JSON-response van WordPress kreeg ik een SiteGround 404.
Ik heb SiteGround vervolgens gevraagd hoe zij omgaan met /.well-known/.
Het antwoord kwam, zoals dat tegenwoordig vaker gaat, van de AI-supportbot.
De uitleg kwam er kort gezegd op neer dat SiteGround een Nginx reverse proxy gebruikt die verzoeken naar /.well-known/ rechtstreeks probeert af te handelen. Als er geen fysiek bestand op de server staat, krijgt de request een 404 voordat Apache of WordPress überhaupt aan de beurt komt.
De voorgestelde oplossing was dan ook: maak de benodigde JSON-bestanden fysiek aan in public_html/.well-known/.
Technisch gezien zou dat kunnen werken.
Maar dat voelde niet als een oplossing die je wilt voorschrijven voor een WordPress-plugin.
Een WordPress-plugin die bij installatie bestanden in een specifieke directory op de server moet gaan schrijven, alleen omdat een hostingplatform /.well-known/ op een bepaalde manier afhandelt, opent weer een hele nieuwe doos met problemen.
Zoals Mark het verwoordde:
“Opening up a whole other can of worms haha”
Daar was ik het wel mee eens.
Een andere route
Mark ging verder zoeken in de MCP-specificatie en de manier waarop clients discovery uitvoeren.
Daar bleek een interessante mogelijkheid te zitten.
Een goede MCP-client kan discovery in meerdere stappen uitvoeren. De /.well-known/-routes hoeven daarbij niet noodzakelijk rechtstreeks in de root van het domein te staan.
Mark paste Albert daarop aan.
In plaats van de discovery-informatie op een plek te zetten die door veel hostingplatforms wordt onderschept, werd het pad aangepast zodat de benodigde /.well-known/-informatie onder een subdirectory van de MCP-server beschikbaar komt.
Mark stuurde me vervolgens een beta van versie 1.4.1 om te testen.
Ik installeerde hem op mijn site, koppelde dezelfde MCP-server opnieuw aan Claude en dit keer werkte de OAuth-flow wel.
Geen Application Password, geen handmatig geknutsel met OAuth-gegevens. Gewoon de MCP-server-URL toevoegen, OAuth laten detecteren en door de login-flow heen.
Precies zoals ik in eerste instantie verwachtte dat het zou werken.
Van probleem naar release
De wijziging is uiteindelijk onderdeel geworden van Albert AI Butler 1.4.1.
Interessant daarbij is dat het probleem niet specifiek voor SiteGround bleek te zijn. Tijdens het testen bleek dat Remkus tegen een vergelijkbaar probleem aanliep bij Servebolt. Ook daar werkte de aangepaste oplossing.
Mijn experiment met MCP had daarmee niet alleen op mijn eigen installatie resultaat.
Wat dit voor WordPress interessant maakt
Voor mij wordt het vanaf hier eigenlijk interessanter.
De MCP-koppeling is één ding, maar uiteindelijk gaat het natuurlijk om wat je ermee kunt doen.
WordPress heeft inmiddels ook een Abilities API. Daarmee kunnen plugins functionaliteit op een gestandaardiseerde manier beschikbaar stellen aan andere systemen. In combinatie met MCP wordt dat interessant voor AI-clients.
Dat betekent bijvoorbeeld dat je niet alleen algemene WordPress-functionaliteit beschikbaar kunt maken, maar ook functionaliteit uit je eigen plugins.
Dat is voor mij een stuk interessanter dan alleen vragen stellen over pagina’s en berichten.
Zo hebben we voor een klant bijvoorbeeld een behoorlijk complexe Twinfield-schaduwdatabase binnen WordPress gebouwd. Daarin wordt financiële informatie uit Twinfield verwerkt en beschikbaar gemaakt voor de applicatie die we rondom WordPress hebben gebouwd.
Als je daar vervolgens relevante abilities voor definieert, ontstaat ineens de mogelijkheid om vanuit een AI-client vragen te stellen over die Twinfield-data.
Bijvoorbeeld niet alleen:
“Welke berichten staan er op mijn website?”
maar veel meer richting:
“Welke ontwikkelingen zie je in de financiële gegevens van deze administratie?”
Of:
“Welke transacties vallen op als ik de afgelopen periode vergelijk met dezelfde periode vorig jaar?”
Daarmee wordt WordPress niet alleen een CMS waar een AI-client toevallig wat data uit kan lezen. Het kan ook een interface worden naar functionaliteit en data die specifiek voor een bepaalde toepassing in WordPress is gebouwd.
En dat vind ik een stuk interessanter.
Zeker omdat systemen als Twinfield zelf op dit vlak nog lang niet altijd dezelfde mogelijkheden bieden. Als je de relevante data al via een eigen WordPress-applicatie beschikbaar hebt, kun je daar met abilities en MCP een nieuwe interface bovenop zetten.
Eerst maar eens verder experimenteren
Mijn eerste doel was eigenlijk vrij bescheiden: een WordPress-installatie koppelen aan Claude via MCP.
Dat bleek iets meer uitzoekwerk te zijn dan verwacht.
Uiteindelijk leverde het wel een werkende OAuth-koppeling op, een verbetering aan Albert AI Butler en voor mij vooral een beter beeld van hoe MCP, OAuth, WordPress en hosting zich tot elkaar verhouden.
De volgende stap is voor mij dan ook niet zozeer nóg een WordPress-installatie aan Claude koppelen.
Ik ben vooral benieuwd wat er gebeurt als je eigen WordPress-plugins functionaliteit beschikbaar gaan stellen via de Abilities API en je die vervolgens via MCP aan een AI-client kunt aanbieden.
Daar begint het wat mij betreft pas echt interessant te worden.
