WordPress Playground + MCP: AI-agents bouwen plugins in een wegwerp-WordPress

Het @wp-playground/mcp-pakket, uitgebracht in maart 2026, doet iets dat twee jaar geleden absurd had geklonken. Je typt een beschrijving van een WordPress-plugin in Claude Code of Gemini CLI, en een AI-agent bouwt hem, installeert hem in een draaiende WordPress-instantie en laat je testen. Die WordPress-instantie draait volledig in je browser. Geen Docker. Geen lokale PHP-installatie. Geen MAMP, geen XAMPP, geen Vagrant. Eén commando om te verbinden, en je bouwt.

TL;DR

• Het @wp-playground/mcp-pakket verbindt AI-agents (Claude Code, Gemini CLI) met WordPress Playground via het Model Context Protocol.
• Setup is één CLI-commando. De MCP-server draait lokaal als Node.js-proces en communiceert met een Playground-instantie in je browser via WebSocket.
• Echt nuttig voor het prototypen van plugins, het leren van WordPress-internals en het snel testen van ideeën. Geen vervanging voor je productie-ontwikkelomgeving.
• Belangrijke beperkingen: SQLite in plaats van MySQL, beperkte netwerkmogelijkheden, geen e-mailtesting, standaard geen persistente state. Het browsertabblad is de server, en een refresh wist alles.

Inhoudsopgave

• Wat MCP is en waarom het hier relevant is
• De verbinding opzetten
• Een plugin bouwen vanuit een prompt
• Wat de agent daadwerkelijk kan
• Waar het spaak loopt
• Het grotere plaatje: WordPress core omarmt AI-tooling
• De kern

Wat MCP is en waarom het hier relevant is

Het Model Context Protocol is een open standaard, oorspronkelijk gemaakt door Anthropic in november 2024 en nu beheerd onder de Agentic AI Foundation van de Linux Foundation. Het standaardiseert hoe AI-applicaties verbinden met externe tools en databronnen. Vergelijk het met een USB-C-poort voor AI: één protocol, veel mogelijke verbindingen. In maart 2026 had MCP 97 miljoen maandelijkse SDK-downloads bereikt en wordt het ondersteund door Anthropic, OpenAI, Google, Microsoft en Amazon.

De architectuur volgt een client-servermodel. De AI-applicatie (Claude Code, in dit geval) is de host. Een MCP-client daarbinnen communiceert met een MCP-server die tools, resources en capabilities aanbiedt. De transportlaag gebruikt JSON-RPC 2.0-berichten, meestal over stdio voor lokale servers.

Waarom is dat relevant voor WordPress? Omdat @wp-playground/mcp een browser-based WordPress-instantie omzet in een MCP-server. Je AI-agent kan bestanden lezen, bestanden schrijven, PHP uitvoeren, pagina's navigeren en sites beheren. Allemaal via een gestandaardiseerd protocol. De agent heeft geen WordPress-specifieke logica nodig. Hij roept gewoon MCP-tools aan.

De verbinding opzetten

Vereisten: Node.js 22 of nieuwer, en Claude Code of Gemini CLI geïnstalleerd.

Voor Claude Code, één commando:

claude mcp add --transport stdio --scope user wordpress-playground \
  -- npx -y @wp-playground/mcp

Voor Gemini CLI:

gemini mcp add wordpress-playground npx -y @wp-playground/mcp

Je kunt de server ook handmatig toevoegen in je .mcp.json (Claude) of settings.json (Gemini):

{
  "mcpServers": {
    "wordpress-playground": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@wp-playground/mcp"]
    }
  }
}

Als je een Claude Code-sessie start en de MCP-server activeert, opent hij een browservenster met WordPress Playground. De server wijst een willekeurige lokale poort toe bij het opstarten en geeft die door aan de browser via een URL-parameter. Een WebSocket-verbinding koppelt het Node.js MCP-serverproces aan de Playground-instantie. Origin-restricties en token-gebaseerde authenticatie voorkomen dat andere tabbladen of browserextensies de verbinding kapen.

Klaar. Geen configuratie in Playground zelf nodig.

Een plugin bouwen vanuit een prompt

Zo ziet een typische interactie eruit. Je opent Claude Code in je terminal en typt zoiets als:

"Bouw een WordPress-plugin genaamd Reading Time die de geschatte leestijd berekent en toont boven elk bericht. Gebruik 200 woorden per minuut als standaard. Voeg een instellingenpagina toe waar de gebruiker de WPM-waarde kan aanpassen."

Claude Code roept de MCP-tools aan om de pluginbestanden te maken (playground_write_file), PHP uit te voeren om hem te activeren (playground_execute_php), en naar een bericht te navigeren om de output te controleren (playground_navigate). Als iets niet werkt, leest de agent de foutmelding, past aan en probeert opnieuw. Je ziet het in real time: file writes in de terminal, de WordPress-site die bijwerkt in je browser.

De feedbackloop is snel. Je zegt "zet de leestijd onder de titel in plaats van erboven." De agent bewerkt het pluginbestand en herlaadt. Geen buildstap. Geen deploy. De iteratiecyclus krimpt tot seconden.

Voor het leren van WordPress-pluginontwikkeling is dit een echte verschuiving. Een beginner kan beschrijven wat hij wil, het zien bouwen, de gegenereerde code inspecteren en begrijpen hoe WordPress hooks en filters werken door ze in context te zien. Dat is hands-on op een manier die documentatie lezen alleen niet biedt.

Wat de agent daadwerkelijk kan

De MCP-server stelt 17 tools beschikbaar, verdeeld over vier categorieën.

Sitebeheer. playground_list_sites, playground_open_site, playground_save_site, playground_rename_site, playground_get_website_url. De agent kan meerdere WordPress-instanties aanmaken en ertussen wisselen.

Bestandssysteem. playground_read_file, playground_write_file, playground_list_files, playground_mkdir, playground_delete_file, playground_delete_directory, playground_file_exists. Volledige lees-/schrijftoegang tot de WordPress-directorystructuur.

Code-uitvoering. playground_execute_php voert willekeurige PHP uit binnen de WordPress-context. playground_request stuurt HTTP-verzoeken naar de Playground-instantie. Hier zit de echte kracht: de agent kan plugins activeren, de database bevragen, WordPress-functies aanroepen en resultaten verifiëren.

Navigatie. playground_navigate, playground_get_current_url, playground_get_site_info. De agent kan de frontend en admin navigeren, controleren wat er zichtbaar is en ernaar handelen.

Combineer deze tools en de agent kan zinvol werk doen. Een plugin installeren vanaf een ZIP-URL, wp_options-waarden wijzigen via PHP, controleren of een shortcode correct rendert op de frontend, en rapporteren.

Waar het spaak loopt

Dit is de sectie die er meer toe doet dan de setupgids. WordPress Playground is een indrukwekkend stuk engineering (PHP gecompileerd naar WebAssembly via Emscripten, draaiend in een Service Worker die HTTP-verzoeken onderschept), maar het blijft een sandbox. En sandboxes hebben muren.

Geen MySQL. Playground gebruikt SQLite met de SQLite Database Integration-plugin die MySQL-queries vertaalt naar SQLite-dialect. De 2.0-vertaallaag slaagt voor 99% van de WordPress-unittests, wat indrukwekkend is. Maar als je plugin iets MySQL-specifieks doet (stored procedures, MySQL-only functies, complexe JOINs die SQLite-randgevallen raken), zie je dat hier niet. Je kunt een plugin bouwen in Playground en dan ontdekken dat hij breekt op een echte MySQL-database.

Beperkt netwerk. Webbrowsers staan niet toe dat WebAssembly-code rechtstreeks internettoegang heeft. Playground kan wp_safe_remote_get-aanroepen vertalen naar JavaScript fetch()-verzoeken, maar libcurl, file_get_contents met URL's en ruwe socketverbindingen werken niet. Als je plugin een externe API aanroept, moet je dat apart testen.

Geen e-mail. wp_mail() heeft nergens naartoe. Er is geen SMTP-server, geen sendmail-binary, geen mailtransport. Als je een plugin bouwt die notificaties verstuurt, kun je de code schrijven maar de aflevering niet testen. En e-mailaflevering is sowieso al een van de lastigste onderdelen van WordPress-development.

Standaard vluchtig. Het browsertabblad vernieuwen vernietigt de instantie. Playground biedt een Save-knop die state opslaat in IndexedDB, maar dat gaat niet automatisch en is nog in ontwikkeling. Je kunt 20 minuten werk verliezen door per ongeluk Cmd+R te drukken.

Gaten in PHP-extensies. De WebAssembly-build bevat de 17 meest gebruikte extensies (libxml, OpenSSL, mbstring, GD, Intl, zLib en meer), wat de overgrote meerderheid van WordPress-plugins dekt. Maar als je imagick, redis of pthreads nodig hebt, is het er niet.

Geen WP-CLI. Niet alle standaard WP-CLI-commando's werken in de browseromgeving. De agent werkt hieromheen door playground_execute_php direct te gebruiken, maar het betekent wel dat je een WP-CLI-workflow niet kunt repliceren.

Voor het prototypen van een instellingenpagina, een custom post type, een Gutenberg-block of een REST API-endpoint? Playground + MCP werkt prima. Voor het testen van databasemigraties, e-mailflows, externe API-integraties of performance onder belasting? Dan heb je nog steeds een echte server nodig.

Het grotere plaatje: WordPress core omarmt AI-tooling

De Playground MCP-server is geen losstaand experiment. WordPress core bouwt AI-toolinginfrastructuur op meerdere niveaus.

De Abilities API, geïntroduceerd in WordPress 6.9, biedt een gemeenschappelijke interface waarmee AI-agents, automatiseringstools en plugins met WordPress kunnen communiceren. Elke ability heeft een namespace, getypeerde input-/outputschema's (JSON Schema draft-04) en permission callbacks. WordPress 7.0 breidde dit uit naar de clientzijde met twee JavaScript-packages (@wordpress/abilities en @wordpress/core-abilities), wat de basis legt voor browser-agents die WordPress-capabilities direct kunnen ontdekken en uitvoeren.

De MCP Adapter-plugin verbindt deze abilities met het Model Context Protocol. Hij stelt drie tools beschikbaar: mcp-adapter-discover-abilities (ontdek wat de site kan), mcp-adapter-get-ability-info (details opvragen) en mcp-adapter-execute-ability (de actie uitvoeren). Dit is iets anders dan Playground MCP. De Adapter verbindt met een echte, draaiende WordPress-installatie. Hij ondersteunt STDIO-transport voor lokale ontwikkeling en HTTP-transport voor remote sites.

De richting is duidelijk. WordPress wil dat AI-agents eersteklas consumenten worden van zijn API's. De Playground MCP-server is het laagdrempelige startpunt: wegwerp, veilig, geen configuratie. De MCP Adapter is het productiepad: beveiligd, met permissies en geïntegreerd met welke WordPress-abilities je site ook aanbiedt. Als je de veranderingen in WordPress 7.0 hebt gevolgd zonder de Abilities API mee te nemen, dan is dit het stuk dat je miste.

De kern

• @wp-playground/mcp koppelt AI-agents aan wegwerp-WordPress-instanties in je browser. Setup is één CLI-commando. Echt nuttig voor prototyping en leren.
• De agent kan bestanden lezen/schrijven, PHP uitvoeren, pagina's navigeren en sites beheren via 17 MCP-tools. De feedbackloop tussen prompt en werkende code is seconden, geen minuten.
• De beperkingen zijn reëel en specifiek: SQLite in plaats van MySQL, geen uitgaand netwerk voor libcurl/file_get_contents, geen e-mail, vluchtige state en een subset van PHP-extensies. Ken deze voordat je begint.
• WordPress core bouwt AI-infrastructuur op elk niveau: de Abilities API (6.9+), de clientside-uitbreiding (7.0) en de MCP Adapter voor productiesites. Playground MCP is de sandbox; de Adapter is het productiepad.
• Dit verandert hoe developers WordPress-plugins leren en prototypen. Het vervangt geen echte ontwikkelomgeving voor productiewerk. Beide dingen zijn waar.