WordPress Playground mit WebMCP: AI-Agenten im Browser
Die technische Änderung
- WordPress Playground stellt Funktionen jetzt als WebMCP-Werkzeuge für kompatible Browser-Agenten bereit.
- Ein Agent ruft beschriebene Funktionen auf, statt Buttons und Formulare zu erraten.
- WebMCP ist ein Community-Group-Entwurf und Chrome-Origin-Trial – noch kein fertiger W3C-Standard.
- Die Arbeit bleibt in einer isolierten Testinstanz im Browser, nicht auf der produktiven Website.
WordPress Playground kann seine Funktionen jetzt als Werkzeuge für kompatible AI-Agenten im Browser bereitstellen. Ein Agent muss dadurch nicht mehr erraten, welcher Button oder welches Formularfeld gemeint ist: Er kann eine klar beschriebene Funktion aufrufen und das Ergebnis direkt in einer laufenden WordPress-Testseite zeigen.
Die Verbindung heißt WebMCP. Sie ist technisch interessant, aber noch experimentell. WebMCP ist ein Entwurf aus einer W3C Community Group und kein verabschiedeter W3C-Standard. Trotzdem zeigt die Integration, wie sich die Arbeit mit WordPress verändern kann: Ein Mensch beschreibt das Ziel, ein Agent bedient definierte Werkzeuge und beide sehen denselben Stand im Browser.
Was ist WordPress Playground?
WordPress Playground startet eine vollständige WordPress-Instanz direkt im Browser. PHP läuft dabei über WebAssembly, die Datenbank basiert auf SQLite. Sie müssen weder einen Webserver einrichten noch PHP oder MySQL lokal installieren.
Playground eignet sich deshalb für Aufgaben, bei denen eine isolierte WordPress-Umgebung gebraucht wird:
- ein Plugin oder Theme ausprobieren,
- verschiedene WordPress- und PHP-Versionen testen,
- einen Fehler reproduzieren,
- eine Demo vorbereiten,
- eine Seite als Prototyp bauen,
- WordPress lernen, ohne eine echte Website zu verändern.
Die Instanz ist eine Testumgebung, keine automatisch veröffentlichte Website. Neue Playgrounds werden je nach Startart im Browser gespeichert oder bewusst temporär angelegt. Wichtige Ergebnisse sollten Sie dauerhaft im Browser speichern oder als ZIP beziehungsweise über die vorgesehenen GitHub-Funktionen exportieren.
Was ist MCP?
MCP steht für Model Context Protocol. Der offene Standard verbindet AI-Anwendungen mit externen Systemen. Ein MCP-Server kann beispielsweise Dateien bereitstellen, eine Datenbank abfragen oder eine Funktion zum Erstellen eines Beitrags anbieten.
Für einen Agenten sind vor allem drei Bausteine wichtig:
- Tools: ausführbare Funktionen, etwa „Beitrag als Entwurf anlegen“.
- Resources: Daten, die als Kontext gelesen werden können.
- Prompts: vorbereitete Arbeitsanweisungen für wiederkehrende Aufgaben.
Statt jeder AI-Anwendung eine eigene Spezialintegration zu bauen, beschreibt MCP ein gemeinsames Verfahren zum Entdecken und Aufrufen dieser Funktionen.
WordPress besitzt dafür inzwischen eine eigene Grundlage. Die seit WordPress 6.9 im Core enthaltene Abilities API erlaubt Plugins, klar definierte und berechtigungsgeprüfte Funktionen zu registrieren. Der separate WordPress MCP Adapter kann solche Abilities für Anwendungen wie Cursor, Claude oder VS Code als MCP-Werkzeuge zugänglich machen.
Was ist WebMCP – und was ist anders?
WebMCP verfolgt dieselbe Grundidee, nutzt aber einen anderen Verbindungsweg.
Bei klassischem MCP verbindet sich eine AI-Anwendung mit einem lokalen oder entfernten MCP-Server. Bei WebMCP stellt eine bereits geöffnete Webseite ihre Werkzeuge über eine Browser-API bereit. Ein kompatibler Browser-Agent entdeckt diese Werkzeuge im aktuellen Seitenkontext und kann sie dort ausführen.
Ein Beispiel: Ein Buchungsformular kann ein Werkzeug termin_buchen mit Feldern für Datum, Uhrzeit und Personenzahl anbieten. Der Agent muss dann nicht das Layout analysieren und mehrere Klicks simulieren. Er erhält einen Namen, eine Beschreibung und ein festes Eingabeschema.
Das soll drei typische Fehlerquellen verringern:
- Der Agent verwechselt ähnlich beschriftete Schaltflächen.
- Ein geändertes Layout zerstört eine visuelle Automatisierung.
- Freie Texteingaben landen im falschen Feld oder Format.
Klassisches MCP
WebMCP im Browser
Klassisches MCP: Die AI-Anwendung verbindet sich mit einem lokalen oder entfernten Server.
WebMCP im Browser: Die geöffnete Webseite stellt ihre Werkzeuge über eine Browser-API bereit.
Klassisches MCP: Läuft unabhängig davon, ob gerade eine Seite sichtbar ist.
WebMCP im Browser: Braucht eine geöffnete Browserseite und denselben sichtbaren Stand.
Klassisches MCP: Eignet sich für Hintergrundaufgaben ohne menschliche Kontrolle im Moment.
WebMCP im Browser: Ist für sichtbare Abläufe gedacht, bei denen ein Mensch den Verlauf prüfen kann.
WebMCP benötigt eine geöffnete Browserseite. Es ist primär für sichtbare Arbeitsabläufe mit einem Menschen im Prozess gedacht. Ein klassischer MCP-Server kann dagegen auch unabhängig von einer geöffneten Seite verwendet werden.
Ein Agent muss nicht mehr erraten, welcher Button gemeint ist: Er ruft eine klar beschriebene Funktion auf und zeigt das Ergebnis in derselben WordPress-Testseite.
Wie WordPress Playground WebMCP nutzt
Playground zeigt WordPress innerhalb verschachtelter Frames an. Das schützt die Laufzeit, erzeugt aber ein Problem: Ein Browser-Agent auf der äußeren Seite sieht Werkzeuge innerhalb der eingebetteten WordPress-Seite nicht automatisch.
Die Playground-Integration löst das mit einem Proxy:
Playground starten
Playground startet WordPress im Browser.
Werkzeuge registrieren
Die innere WordPress-Seite registriert verfügbare Werkzeuge.
Proxy sichtbar machen
Der Proxy macht diese Werkzeuge auf der äußeren Playground-Seite sichtbar.
Agent auswählen
Der Agent wählt ein passendes Werkzeug und übergibt strukturierte Eingaben.
Aufruf weiterleiten
Der Proxy leitet den Aufruf in die WordPress-Instanz weiter.
Ergebnis prüfen
Das Ergebnis erscheint in derselben Browser-Sitzung.
Zu den eingebauten Werkzeugen gehören derzeit Funktionen für:
- Playground-Sites auflisten, öffnen, umbenennen und speichern,
- innerhalb der Testseite navigieren,
- Informationen zur aktuellen Site abrufen,
- PHP ausführen und interne Anfragen stellen,
- Dateien lesen, schreiben, anlegen und löschen.
Plugins können eigene WebMCP-Werkzeuge ergänzen. Eine registrierte WordPress Ability erscheint allerdings nicht automatisch als WebMCP-Tool. Das Plugin muss sie ausdrücklich für WebMCP verpacken. Alternativ kann ein Agent über Playgrounds Request-Werkzeug auf Abilities zugreifen, die über die WordPress REST API freigegeben sind.
Praktische Einsatzfelder
1. Landingpages als überprüfbaren Prototyp bauen
Ein Agent kann eine Seite direkt im Block-Editor anlegen, Inhalte strukturieren und das Ergebnis im Frontend öffnen. Sie beurteilen nicht nur einen Textvorschlag, sondern eine funktionierende Seite in WordPress.
Prüfe zuerst die verfügbaren Site Tools. Erstelle danach in WordPress
Playground eine responsive Landingpage für eine Steuerberatung. Verwende
nur Core-Blöcke. Lege die Seite als Entwurf an und öffne anschließend
die Frontend-Vorschau. Veröffentliche nichts außerhalb von Playground.2. Plugins ohne Risiko testen
Playground kann ein Plugin in einer frischen Instanz installieren und typische Abläufe prüfen. Die echte Website bleibt unverändert.
Installiere das bereitgestellte Plugin ausschließlich in WordPress
Playground. Aktiviere es, dokumentiere neue Menüpunkte und führe einen
grundlegenden Funktionstest durch. Ändere keine produktive Website.
Speichere Fehlermeldungen und die verwendete WordPress-/PHP-Version.Das eignet sich für Vorprüfungen, ersetzt aber keine vollständigen Tests mit dem produktiven Theme, Hosting, Cache und echten Schnittstellen.
3. Fehler reproduzierbar machen
Supportfälle scheitern häufig daran, dass niemand denselben Ausgangszustand herstellen kann. Ein Playground mit definierter WordPress-Version, PHP-Version, Plugin-Liste und Beispieldaten lässt sich speichern und weitergeben.
Erstelle eine saubere Playground-Instanz mit derselben WordPress- und
PHP-Version wie im Fehlerbericht. Installiere nur die genannten Plugins.
Versuche den Fehler Schritt für Schritt zu reproduzieren. Dokumentiere
den kleinsten Aufbau, bei dem er noch auftritt.4. Kompatibilität über mehrere Versionen prüfen
Entwickler können einen Fix gegen verschiedene WordPress- oder PHP-Versionen testen. Playground unterstützt auch ältere WordPress-Versionen und erleichtert damit die Frage: Seit welchem Release tritt ein Fehler auf?
5. Interaktive Plugin-Demos anbieten
Ein Plugin-Anbieter kann Interessenten eine vorbereitete Testseite öffnen lassen. Ein Blueprint installiert das Plugin, erzeugt Beispieldaten und setzt die benötigten Optionen. WebMCP kann zusätzliche Plugin-Aktionen als verständliche Werkzeuge anbieten.
Ein Event-Plugin könnte beispielsweise ein Tool „Entwurfsveranstaltung erstellen“ registrieren. Der Agent fragt Titel, Datum und Ort ab, legt die Veranstaltung in Playground an und öffnet die Vorschau. Der Nutzer muss das Plugin nicht auf einer eigenen Website installieren.
6. Schulungen und Dokumentation ausführbar machen
Anleitungen können mit einer vorbereiteten WordPress-Instanz verbunden werden. Lernende bitten einen Agenten um einen Aufbau, untersuchen das Ergebnis und ändern es anschließend selbst. Der Agent arbeitet in einer begrenzten Umgebung, während die Benutzeroberfläche sichtbar bleibt.
Was heute noch nicht funktioniert
- Kleine, reversible Aufgaben in einer isolierten Playground-Instanz.
- Sichtbare Prototypen, Plugin-Vorprüfungen und reproduzierbare Fehlerberichte.
- Eigene Werkzeuge mit klarer Berechtigung und Bestätigung für schreibende Aktionen.
- WebMCP ist noch kein allgemein verfügbarer Webstandard.
- Chrome führt die API als Origin Trial; Support in AI-Anwendungen ist ungleich.
- Playground bildet nicht jedes Produktionssystem vollständig ab.
Chrome führt die API als Origin Trial; lokale Tests benötigen eine passende Browserversion und gegebenenfalls ein experimentelles Flag. Unterstützung in AI-Anwendungen hängt vom jeweiligen Produkt, Modell, Konto und Rollout ab.
Auch die API selbst verändert sich noch. Ältere Beispiele verwenden navigator.modelContext, während die aktuelle Spezifikation document.modelContext beschreibt. Code für produktive Websites sollte deshalb nicht ohne Versionsprüfung übernommen werden.
Playground bildet außerdem nicht jedes Produktionssystem vollständig ab. Externe Netzwerkzugriffe, große Plugins, spezielle Servermodule und manche WP-CLI-Befehle sind eingeschränkt. Ein erfolgreicher Playground-Test beweist nicht automatisch, dass ein Plugin auf jedem Hosting funktioniert.
Sicherheit: Ein Werkzeug ist mehr als ein Button
WebMCP kann Funktionen zum Schreiben von Dateien, Ausführen von PHP oder Ändern von Inhalten bereitstellen. Diese Fähigkeiten müssen enger behandelt werden als eine reine Chat-Antwort.
Für eigene Werkzeuge gelten mindestens diese Regeln:
Auch moderne Agenten bleiben anfällig für Prompt Injection: Eine manipulierte Webseite kann Anweisungen enthalten, die das ursprüngliche Ziel des Nutzers verändern sollen. Die WebMCP-Sicherheitsdokumentation empfiehlt deshalb Hinweise für schreibende oder folgenreiche Tools und eine bewusste Benutzerbestätigung.
Playground begrenzt den möglichen Schaden, weil die Arbeit in einer isolierten Testinstanz stattfindet. Diese Sicherheit darf nicht ungeprüft auf eine produktive WordPress-Website übertragen werden.
So können Sie WebMCP ausprobieren
Playground öffnen
Öffnen Sie WordPress Playground in einer aktuell unterstützten WebMCP-Umgebung.
Instanz laden lassen
Warten Sie, bis die WordPress-Testseite vollständig geladen ist.
Site Tools öffnen
Öffnen Sie in der AI-Anwendung die verfügbaren Website- oder Site-Tools.
Nur auflisten
Lassen Sie den Agenten zuerst nur die verfügbaren Werkzeuge auflisten.
Kleine Aufgabe geben
Geben Sie eine kleine, klar überprüfbare Aufgabe.
Selbst kontrollieren
Kontrollieren Sie Dateien, Inhalte und Frontend selbst.
Erst dann speichern
Speichern oder exportieren Sie die Instanz erst nach der Prüfung.
Beginnen Sie nicht mit „Baue mir eine komplette Website“. Ein sinnvoller erster Test ist eine Entwurfsseite mit wenigen Blöcken oder die Installation eines bekannten Plugins. So erkennen Sie, welche Schritte der Agent tatsächlich über Werkzeuge ausführt und wo weiterhin manuelle Kontrolle nötig ist.
Warum diese Entwicklung wichtig ist
Bisher mussten Browser-Agenten Websites hauptsächlich wie Menschen bedienen: Oberfläche ansehen, Elemente deuten, klicken und hoffen, dass sich das Layout nicht geändert hat. WebMCP ergänzt diese visuelle Ebene um explizite, maschinenlesbare Handlungen.
Für WordPress treffen damit drei Entwicklungen zusammen:
- Playground stellt eine sofort verfügbare Testumgebung bereit.
- Die Abilities API beschreibt WordPress-Funktionen einheitlich.
- MCP und WebMCP geben AI-Agenten unterschiedliche Wege, diese Funktionen aufzurufen.
Noch ist das ein Experimentierfeld. Für Plugin-Entwickler, Agenturen und technische Teams ist jetzt trotzdem ein guter Zeitpunkt, kleine, reversible Arbeitsabläufe zu testen. Entscheidend ist nicht, ob ein Agent WordPress irgendwie bedienen kann, sondern ob er klar definierte Aufgaben nachvollziehbar und mit passenden Berechtigungen ausführt.
Häufige Fragen
Nein. Beide stellen Agenten strukturierte Werkzeuge bereit. MCP verbindet eine AI-Anwendung mit einem lokalen oder entfernten Server. WebMCP stellt Werkzeuge innerhalb einer geöffneten Browserseite bereit.
Nicht bei einem normalen Test in WordPress Playground. Der Agent arbeitet in der Browser-Instanz. Achten Sie darauf, die Playground-Umgebung nicht mit Zugangsdaten oder Schnittstellen einer produktiven Website zu verbinden.
Zum Ausprobieren eingebauter Playground-Werkzeuge nicht zwingend. Eigene WebMCP-Tools für ein Plugin zu entwickeln erfordert JavaScript, strukturierte Eingabeschemas sowie eine saubere Berechtigungs- und Sicherheitslogik.
Nein. Browser- und Client-Unterstützung sind noch begrenzt, die Spezifikation kann sich ändern. WebMCP sollte derzeit als progressive Erweiterung und Experiment behandelt werden, nicht als einzige Bedienmöglichkeit.
Weiterführende Inhalte
- WordPress Playground öffnen
- Offizielle Playground-Dokumentation
- Teil1 Schema Manager: Was er löst und wie Sie ihn nutzen
- Was ist Schema.org?
Quellen
- WordPress Playground: WordPress Playground and WebMCP
- WordPress Developer Blog: September 2026
- WordPress Playground – offizielle Dokumentation
- WordPress Playground – Einschränkungen
- Chrome for Developers: WebMCP
- WebMCP Community Group Draft
- Model Context Protocol – Einführung
- WordPress Abilities API
- WordPress MCP Adapter
