Ervaringen met Elementor MCP: Project Nostimo

Het proces achter Project Nostimo

Ik houd van lekker eten. Ik denk dat dit de drijvende kracht was achter mijn idee om voor de cursus ‘Elementor Pro voor Designers‘ het voorbeeld van een restaurantsite te gebruiken. Bovendien is het ook een leuke oefening hoe je in een website met behulp van Custom Post Types en Custom Taxonomies de content van je website makkelijk beheers- en herbruikbaar maakt.

Het leuke van de cursus Elementor Pro voor Designers was -en is- dat het geen droge theorie met een aantal trucjes uitproberen is, maar dat er vanaf het begin van de cursus wordt gewerkt met een concreet project. Een website voor een restaurant. En wat voor restaurant! Enkele dagen voor de cursus kregen -en krijgen- de cursisten namelijk een mail met als ‘huiswerk vooraf’ om zichzelf voor te stellen dat ze een restaurant zouden openen. Wat voor restaurant zou het zijn? Wat voor keuken? Welke gerechten? Welke prijsklassen?

De cursist wordt uitgenodigd om zijn of haar eigen opdrachtgever te zijn en te beschrijven hoe de website voor haar of zijn restaurant er uit zou moeten zien. En deze natuurlijk gedurende de cursus ook te bouwen.

Tot twee jaar terug kregen ze ook het advies om voor de foto’s voor de website te zorgen, via de Envato Elements site. Destijds kon je namelijk een gratis maand -later gratis twee weken, nu helemaal niet meer- abonnement voor een maand nemen, om ook foto’s uit te zoeken die pasten bij de gerechten en het soort interieur van jouw ideale restaurant.

Het was leuk om enkele jaren van één cursist te horen dat ze juist voor deze cursus gekozen had om Elementor te leren, omdat ze altijd al een restaurant had willen hebben, en nu haar eigen -alhoewel virtueel- restaurant zou kunnen hebben.

Maar de cursusleider dan?

In al die jaren heb ik nooit mijn eigen ‘fantasie restaurant’ gebouwd. Ik heb allerlei losse demopagina’s aan cursisten laten zien, maar nooit iets wat tot een min of meer ‘echt’ restaurant samengevoegd zou kunnen worden.

De Elementor MCP

Enige tijd terug werd de Elementor MCP beschikbaar gesteld voor beta-testers. Ik heb hier in het recente verleden ook over geschreven. Voor degenen die niet weten wat de Elementor MCP is, of in zijn algemeenheid niet weten wat een ‘MCP’ is, je zou het heel simpel gezien als een soort GPS-navigatie voor AI kunnen zien. MCP, wat staat voor Model Context Protocol is een manier van communiceren tussen een server en een AI (coding) agent die vertelt hoe bepaalde zaken gedaan moeten worden voor een bepaalde toepassing.

Een concreet voorbeeld: Een AI-coding agent kan natuurlijk het hele internet afzoeken naar hoe een WordPress plugin gemaakt moet worden, of WordPress zou een server beschikbaar kunnen stellen waar al die informatie in een voor een AI-agent eenvoudig te begrijpen formaat te lezen staat.

Maar het kan ook iets verder gaan. Wanneer we bijvoorbeeld naar de Elementor MCP kijken, dan vertelt deze niet alleen hoe zaken uitgevoerd kunnen worden, maar vertelt ook welke gereedschappen Elementor alvast heeft klaargezet voor een AI agent om te gebruiken.

En wat hier ook belangrijk bij is een aantal van deze gereedschappen zijn bedoeld voor de AI agent om te controleren of de code die hij ontwikkeld heeft ook daadwerkelijk werkt.

Dus behalve ‘hoe het te doen’, weet de AI-agent ook hoe hij het moet testen. Een niet onbelangrijke aanvulling.

Angie en de Elementor MCP

En deze hele configuratie speelt Angie ook een belangrijke rol. Voor veel zaken die door de MCP afgehandeld worden is Angie het eerst voorgestelde aanspreekpunt. Dat wil zeggen, dat de Elementor MCP aangeeft, dat vragen in eerste instantie aan Angie gesteld moeten worden. Is Angie om welke reden dan ook niet bereikbaar, pas dan moet de Agent buiten Angie om een oplossing proberen te vinden.

Zoals altijd met medewerkers, iedere medewerker verwacht betaald te worden. Angie biedt haar diensten niet gratis aan (nou ja, tegen het einde van dit artikel lees je, dat ze dit min of meer wel doet), dus je moet credits hebben voor zowel je coding agent als voor Angie. Hoe dit zit met Angie en haar credits kan je lezen in het artikel over Angie wat ik enige tijd geleden heb gepubliceerd.

Ik heb de Elementor MCP uitgetest met- en zonder Angie. Omdat de agent geen schrijfrechten heeft als Angie niet actief is, zal veel van de functionaliteit die nodig is in een aparte plugin wordt gestopt, die de ontwikkelaar handmatig moet uploaden. Wanneer Angie en de Agent samenwerken is het heel wat leuker werken.

En nu… tromgeroffel: Mijn ervaringen met de Elementor MCP

Laten we eens een volledige site bouwen!

Ik had de MCP in eerste instantie vooral uitgeprobeerd als ‘beta tester’, met als de bedoeling zoveel mogelijk edge-cases te vinden, waar de MCP de fout in schiet. En geloof me, die waren er in eerste instantie meer dan genoeg,maar in de uiteindelijke productiesituatie lijken ze allemaal opgelost.

Waar ik echter helemaal geen idee van had, was hoeveel tijd en tokens (=geld) het kost om een daadwerkelijke website te bouwen. Dus ik besloot een klein ‘intern’ project te starten. En aangezien ik toch al een leuke opdrachtbeschrijving had, besloot ik een restaurantsite te gaan bouwen met behulp van een AI agent, de Elementor MCP en Angie.

Nostimo – Mijn ideaal Grieks Restaurant

Ik houd van lekker eten. Ik denk dat met betrekking tot de mediterrane keuken de Griekse keuken wel het meest onderbelicht is.

Hoewel de Griekse keuken juist uitblinkt door vis, zeevruchten en vegetarische gerechten lijkt in Nederland het overgrote deel van de menukaart gedomineerd te worden door een veelheid aan vlees.

Dus ik besloot mijn virtuele restaurant, Nostimo, wat ‘smakelijk’ of ‘lekker’ betekent, niet in het bekende blauw-wit te presenteren, geen schalen vol vlees, maar als een ingetogen traditionele taverna, zoals je die in Griekenland tegenkomt, met echt traditionele gerechten, en niet de typische ‘Nederlands-Griekse’ grote vlees schotels.

En de website voor dit virtuele restaurant -mocht je al trek krijgen, terwijl je de pagina’s bekijkt, moet ik je teleur stellen, het bestaat (nog?) niet- was de inspiratie voor mijn test met de Elementor MCP

1. Eén uitgangspunt, twee agents

Ik heb zelf goede ervaringen met Claude Code wanneer het gaat over het programmeren in Laravel. Ik heb ook goede ervaringen met ChatGPT wanneer het gaat over het genereren van afbeeldingen. Maar tijdens mijn eerste experimenten met de Elementor MCP kwam ik er toch achter, dat Elementor aansturen via een Code Agent een totaal andere skillset voor de developer zelf vereist. Ik wilde dus beide coding agents ‘iets serieus’ laten doen op een manier waarbij de onderlinge resultaten vergeleken kunnen worden. En dat kan alleen, wanneer je uitgaat van eenzelfde uitgangspunt.

Beide agents krijgen exact dezelfde gedetailleerde briefing. Eén met zo min mogelijk vrijheidsgraden. En hoe gaan ze daar mee om.

Om eenzelfde briefing te krijgen kan ik natuurlijk doodgewoon dezelfde prompt in twee chatvensters kopieëren. Maar daar laat ik teveel vrijheden open. Want het is verdraaide moeilijk om goede, duidelijke, gedetailleerde prompts te schrijven. Gelukkig kunnen we onze onvolmaakte prompt voorleggen aan een willekeurige AI chat met het verzoek om kritische vragen te stellen. En op deze manier niet alleen een prompt, maar ook de nodige ‘skills’ en ‘requirements’ door kunnen geven aan de beide code agents.

In mijn aanvankelijke prompt nam ik ook op, wat het doel van de chat was. Niet om tot een website ontwerp te komen, maar tot een gedetailleerde set prompts, skills en requirements om de samenwerking tussen de coding agent en Elementor MCP te testen.

Ik wil bij wijze van experiment de Elementor MCP gebruiken voor het bouwen van een WordPress website. Ik wil in ChatGPT de website beschrijven, vragen ontvangen, en uiteindelijk twee producten als eindresultaat voor de chat kunnen gebruiken, Een stylekaart en een serie SKILL en REQUIREMENT bestanden die door Codex of Claude Code gebruikt kunnen worden. 

Het algemene idee voor de site is een denkbeeldig restaurant in Amsterdam. Het is een Griekse Taverne met authentiek Griekse gerechten. De site bestaat uit een homepage, een 'Over Ons' Pagina, een pagina met een sfeerimpressie van het restaurant, een menukaart en recensies.

De menukaart, de sfeerimpressie (basicly een portfoliopagina) en de recensies worden opgeslagen in custom post types. 

De sfeer van de site zelf moet niet in het typische Griekse blauw en wit zijn, maar passen bij de warme sfeer van het interieur van een Griekse taverne. 

Het is een restaurant, zich vooral richtend op mensen met een inkomen van twee keer modaal. Pas voor de invulling van de menukaart de prijzen aan op de doelgroep.

LET OP: Deze beschrijving is niet, wat je moet gaan bouwen, maar geeft aan welke instructies gegeven moeten worden in de beginprompt, de requirements en de skills. Alleen deze bestanden en de stylecard zijn daadwerkelijke eindproducten voor deze sessie. 

Stel aanvullende vragen om tot een goed ontwerp te kunnen komen. 

Stel meer vragen ter verduidelijking

Dat leidde dus tot 78 vragen ter verduidelijking. De meeste vragen hadden voor mij heel voor de hand liggende antwoorden. Maar wat je nimmer moet vergeten, is dat alles wat niet expliciet wordt afgebakend, een AI model vrijheden geeft, die we mogelijk niet willen.

Maar na het beantwoorden van die 78 vragen riepen die antwoorden weer vragen op. Hierdoor kreeg ik nog 30 vragen om te beantwoorden.

Ik had dus 108 vragen beantwoord, sommige met een simpele keuze als A, B, of C, andere met een langer verhaal, bijvoorbeeld hoe een restaurant-menu pagina technisch opgebouwd moet worden.

Maar uiteindelijk was ChatGPT klaar en had ik als eindresultaat een ZIP bestand met de nodige markdown bestanden die ik binnen de beide projecten kon gaan gebruiken.

2. Dezelfde opdracht, een ander proces

Beide coding agents hebben een zogenaamde ‘plan mode’, waarbij je de agent nog niets laat doen, maar uit laat zoeken hoe hij het wil doen. Want in de uiteindelijke projectbrief stond wel dat ze voor bepaalde zaken via Angie AI moeten werken, maar niet hoe. Dus beide agents gingen aan de slag op een ‘kale’ WordPress website, waar alleen Elementor, Elementor Pro, Angie en ACF geïnstalleerd waren.

Voor de test gebruikte ik Claude Opus 5 vs GPT-5.6 Sol, beide modellen die goed geschikt zijn voor deze toepassing, beide met vrijwel identieke capaciteiten. Claude Opus 5 is ca. 17% goedkoper dan GPT-5.6 Sol.

Het werd al snel duidelijk, dat het ‘plan van aanpak’ van beide agents behoorlijk grote onderlinge verschillen vertoonde. Het voorstel van Codex sloot het meest aan bij mijn eigen werkwijze, De Claude Code aanpak was niet verkeerd, maar het zou niet de volgorde zijn die ik zelf zou kiezen.

Het grote verschil zat in de opbouw: Codex stelde voor eerst de componenten die nodig waren te definieren en te testen op aparte losse pagina’s en pas later deze componenten samen te voegen op de pagina’s.

Claude Code die stelde voor, om pagina voor pagina te bouwen.

Beide zijn geldige benaderingen. En beide benaderingen zijn slechts voorstellen. In het geval van Claude Code zei ik dus vriendelijk, dat ik het voorstel verwierp, en als eerste de componenten, daarna pas de pagina’s wilde bouwen.

3. Eerst uitzoeken welke route werkt

De Elementor MCP schrijft niet voor hoe je dingen moet doen, maar vertelt welke tools beschikbaar zijn hoe je dingen kan doen. En daarom is het goed een aantal dingen te testen of en hoe ze werken. De eerste uitdaging kwam met het gebruik van ACF (Advanced Custom Fields). Voor de websites moesten custom post types gemaakt worden, en ik had aangegeven dat dit niet middels code, maar middels de ACF plugin moest. Voor Codex bleek dit een kleine hindernis te zijn. Er was geen informatie beschikbaar hoe ACF aangestuurd kon worden en vroeg om toestemming om een plugin te schrijven die de custom post types en taxonomies zou toevoegen. Claude Code vroeg of hij via Angie mocht proberen of de ACF post types via Angie aangemaakt konden worden.

Voor mij is dit een prachtig voorbeeld, hoe twee verschillende AI code agents voor hetzelfde probleem een andere oplossing zoeken. Overigens beide oplossingen werken! Het grote verschil is echter wel, dat voor de Codex oplossing ik door Codex gemaakte plugin handmatig op zou moeten loaden en voor ieder extra veld de code van de plugin aan zou moeten passen, terwijl de Claude Code oplossing geen menselijke handelingen verwachtte om door te gaan. Toen ik Codex overigens de hint gaf Angie te gebruiken, verliep dat verder ook goed.

Wat dit mij echter wel duidelijk maakte, is dat beide AI-agents af en toe een ‘duwtje in de rug’ nodig hebben om de meest effectieve wijze te vinden. AI-agents zijn soms net mensen.

Overigens, in alle gevallen waar ik een vergelijk tussen Codex en Claude Code maak, dan heb ik het specifiek over de eerder genoemde Claude Opus 5 en GPT-5.6 Sol modellen, die als ‘gelijkwaardige modellen’ worden gezien. Het is heel goed mogelijk dat in oudere of toekomstige modellen weer totaal andere ‘wegen’ worden gezocht en gevonden.

4. De technische basis vastleggen

Op het moment dat duidelijk is dat het technisch ook mogelijk om te doen wat je wilt, is het tijd om de technische basis in te richten. Global classes, kleuren, typografie enzovoort werden in het ontwerpsysteem van Elementor vastgelegd. Hier heeft de AI agent geen vrijheidsgraden voor eigen interpretatie en het verbaasde mij dan ook niets, dat beide agents tot eenzelfde resultaat kwamen hier.

5. Componenten bouwen en direct controleren

Hier werden de terugkerende pagina onderdelen als secties, headers, kaarten, menuonderdelen en andere terugkerende elementen binnen Elementor opgebouwd. Wat hier heel belangrijk bleek, is dat je niet alleen controleert of de elementen er goed uitzien, maar ook of de opbouw logisch is voor wat betreft de class-hiërarchie. Wanneer je in de specificaties hebt staan, dat alle ‘image’ atomic-elements afgeronde hoeken moeten hebben, dan verwacht je dat er één ‘hogere’ class is die bepaald, dat de afbeelding afgeronde hoeken heeft, en de overige kenmerken vast liggen in een lagere class. Claude Code was op dit gebied vrij slordig. Door in de REQUIREMENTS bestanden voor afbeeldingen dit extra nadruk te geven, ging Claude het goed doen.

Het is echter heel belangrijk om vroeg in het proces dit al te ontdekken. Wanneer je bij een compleet afgebouwde site achteraf zou bepalen, dat je toch geen ronde hoeken bij de foto’s wilt, zou je in de ‘Claude’ oplossing alle foto’s aan moeten passen, terwijl je in de Codex oplossing de aanpassing slechts op één plaats hoeft te doen.

6. Eerst testen op een losse pagina

Voordat de volledige site werd opgebouwd, werden enkele componenten gecombineerd op testpagina’s. Dat maakte fouten relatief goedkoop: wanneer iets technisch niet goed werkte, hoefde niet direct een complete pagina opnieuw opgebouwd te worden.

Hier bleek vooral Claude Code af en toe te willen ‘smokkelen’, door in plaats van een Elementor component een ‘HTML atomic element’ te gebruiken. Visueel kreeg ik precies wat ik wilde, maar onder de motorkap was het geen Elementor maar pure HTML. Dat was opgelost na een expliciet requirement om te VERBIEDEN dat HTML widgets en elements gebruikt zouden worden.

Pas nadat deze proefopstellingen stabiel waren, begon de echte sitebouw.

7. Pagina voor pagina opbouwen

Daarna werden de definitieve pagina’s één voor één samengesteld. Daarbij werden de eerder gemaakte componenten en globale instellingen hergebruikt. Na iedere pagina volgde opnieuw een controle, zodat problemen niet pas aan het einde van het project naar boven kwamen.

Een interessante situatie deed zich voor op de pagina voor de ‘sfeerimpressie’. Wanneer ik ‘hoverde’ over de actieve filter knop van de Codex versie, dan werd de tekst slecht leesbaar, omdat bij het hoveren de achtergrond licht wordt, en de tekst licht bleef.

Op zich was dit geen fout. De knop vertoonde exact het beschreven gedrag. Interessant is echter dat in de automatische ‘visuele’ controle van de Claude versie gesignaleerd werd, dat in deze situatie de tekst onleesbaar is, en mij gevraagd werd, of de tekst ook donker mocht worden.

Hier was het dus Codex die exact deed wat gevraagd werd, evenals Claude, maar bij een ‘visuele’ controle ontdekte Claude dat de tekst onleesbaar was, Codex deed dat niet.

Een klein detail, maar ik vond het toch interessant te ontdekken.

Laadsnelheid als onderdeel van de automatische test

In de specificaties was ook duidelijk een verwachting uitgesproken over de laadsnelheid van de pagina’s. De laadsnelheid -inclusief de foto’s- mag niet groter zijn dan 2,5 seconden, de gemiddelde laadsnelheid niet groter dan 1,5 seconden. Daar waar de laadsnelheid structureel te groot was, keken we naar mogelijke oplossingen.

8. Losse pagina’s worden één site

Tot nu toe waren alle pagina’s losse pagina’s. Geen enkele verwijzing naar een andere pagina werkte nog. Toen de pagina’s afzonderlijk goed werkten, werden ze met elkaar verbonden: navigatie, interne links, knoppen en eventuele verwijzingen naar dynamische content. Op dat moment verschoof de controle van “werkt deze pagina?” naar “werkt de site als geheel?”

Dit is ook een goed moment om te ontdekken of de navigatie ook logisch is. Want ‘werkend’ en ‘logisch’ is niet hetzelfde.

9. Automatische controles plus menselijke eindcontrole

Tijdens het proces voerden de agents ook automatische controles uit. Afhankelijk van de stap ging het bijvoorbeeld om het controleren of elementen daadwerkelijk waren aangemaakt, of classes en instellingen aanwezig waren, of links naar bestaande pagina’s verwezen en of de gegenereerde structuur technisch geldig bleef. Zulke controles zijn nuttig, maar vervangen geen visuele beoordeling. Daarom volgde aan het einde nog een aparte controle op ontwerp, inhoud, consistentie, navigatie en details.

En Taadaaaaa, hier is-tie dan!

Wil je bekijken wat uiteindelijk mijn favoriete versie van de site is geworden, dan kan je dit hier bekijken

Niemand heeft gewonnen… en niemand heeft verloren

In mijn vergelijk van Claude Code met Codex kan ik eigenlijk weinig anders zeggen, dan ‘soms gaat de één, dan gaat de ander’ de fout in. Er is geen duidelijke winnaar. Tenminste, niet wat betreft het gebruik van de Elementor MCP. Ok, je moet de ene AI coding agent vertellen dat Angie bestaat, de andere coding agent moet je vertellen dat het toch echt niet ok is om een ‘widget te faken’ door een HTML widget in te zetten, maar wanneer je dit expliciet duidelijk maakt, gaat het allemaal toch goed.

Wat voor mij wel duidelijk is geworden, is dat je vooral aan de begin van een project veel en vaak bij moet sturen. Het is naïef te verwachten, dat AI je problemen oplost. Sterker nog, AI zal je problemen versterken, wanneer je niet goed -en regelmatig- bijstuurt.

Waarom verschilt dit project van een ‘echt klanten project’?

Bij het calculeren van de werkelijke kosten van een project moet natuurlijk ook het gebruik van AI in de calculaties moeten worden meegenomen. Tijdens dit project maakte ik gebruik van een OpenAI Plus abonnement en een Claude Max abonnement. Hierbij werd direct duidelijk hoe groot het verschil is tussen het ‘kleine’ en het ‘grote’ abonnement met betrekking tot de continuïteit van de werkzaamheden. Regelmatig moest ik met het OpenAI Plus abonnement de werkzaamheden ‘neerleggen’, omdat Codex de limiet had bereikt. Bij het Claude abonnement ben ik geen enkele keer tegen een limiet aangelopen bij de realisatie van het project.

Wil je structureel met code agents als Codex of Claude Code gaan ontwikkelen, dan moet je minimaal rekenen op maandelijkse abonnementskosten rond de 100 euro ex BTW per AI dienst.

Tijdens mijn test project liet ik de AI-coding agents tekst en afbeeldingen genereren. In een werkelijke situatie zal een restaurant over eigen foto’s en eigen teksten beschikken, waardoor het aantal werkelijk bestede credits waarschijnlijk heel wat lager uit zou komen.

Waarin het ook verschilt van een echt klanten project dat de specificaties vanaf het moment dat de bouw echt begint ‘bevroren’ zijn. Er wordt gebouwd waar ik om gevraagd heb. Het overkomt mij maar zelden, dat een klant tijdens het proces geen veranderingen wil. Door een goede opzet van de class-structuur kan je -zonder AI te gebruiken- heel eenvoudig een aantal zaken centraal aanpassen.

• Kan dat rood iets dieper?
• Kunnen de knoppen iets groter?
• Ik wil toch een ander lettertype voor de knoppen!

voor wat grotere veranderingen kan het het overwegen waard zijn om AI ook bij de veranderingen in te zetten. Gezien de tijd -en credits- die het kost om je coding agent opnieuw de gegevens in te laten lezen om ‘klaar te zijn’ voor de klus, zou ik alleen voor AI ondersteunde ontwikkeling kiezen voor grotere aanpassingen.

AI ondersteuning wordt pas potentieel lonend, wanneer een activiteit je minimaal 20 minuten zou kosten.

Zelf met Elementor MCP aan de slag?

Het Nostimo-project laat vooral zien dat werken met Elementor MCP iets anders is dan een AI-agent vragen om “even een website te bouwen”. De echte winst ontstaat wanneer je een goede briefing vertaalt naar requirements, het werk opdeelt in controleerbare stappen en tijdens het hele proces zelf de regie houdt.

Precies daar draait mijn tweedaagse training Elementor MCP voor Webdesigners om. Je leert werken met Claude Code en/of Codex binnen een professionele Elementor-workflow: van briefing en context tot requirements, skills, opdrachten, uitvoering en controle. Niet als vervanging van je kennis als webdesigner, maar als een manier om die kennis veel effectiever in te zetten.

De training is bedoeld voor webdesigners en WordPress-professionals die Elementor al kennen; programmeerkennis is niet vereist.

Bekijk de training Elementor MCP voor Webdesigners en meld je aan