WordPress mit KI-Agenten bauen: Oxygen + MCP

Die Website, auf der Sie diesen Artikel lesen, habe ich nicht im Page-Builder zusammengeklickt. Ich baue und pflege sie mit Claude Code, das über einen WordPress-MCP-Server direkt mit dem Oxygen Builder arbeitet. In diesem Artikel beschreibe ich den Aufbau, die Regeln, die ich den Agenten gebe, und die Stellen, an denen dieser Ansatz Risiken hat.

Ausgangslage: eine Oxygen-Website ohne Theme-Templates

bk-coding.de läuft auf WordPress und ist vollständig mit Oxygen gebaut. Es gibt keine klassischen Theme-Templates: Seiten, Header und Footer sind Elementbäume, die Oxygen in der Datenbank speichert. Ein lokales Repository mit Quellcode, den man baut, testet und deployt, existiert für die Website selbst nicht.

Das hat Folgen für die Arbeit mit einem KI-Agenten. Ein Agent kann hier keine Dateien editieren und einen Pull Request stellen. Er muss mit dem Builder sprechen, und zwar über eine Schnittstelle, die Oxygen versteht. Genau diese Schnittstelle liefert das Model Context Protocol (MCP). MCP ist ein offener Standard, über den ein KI-Agent Werkzeuge und Daten einer Anwendung entdecken und aufrufen kann. Die Anwendung beschreibt, welche Fähigkeiten sie anbietet, und der Agent nutzt sie, ohne dass jemand eine eigene Anbindung für jede Kombination programmieren muss.

Wie die WordPress-MCP-Anbindung technisch aussieht

Seit Version 6.2, die zum Zeitpunkt dieses Artikels noch als Beta vorliegt, kann Oxygen von einem KI-Agenten über MCP gesteuert werden. Der Agent kann Seiten, Templates, Header, Footer, Komponenten, CSS-Selektoren, CSS-Variablen und dynamische Daten anlegen und bearbeiten.

Die Verbindung läuft über das Plugin Agent Connector, das eine Brücke zwischen Agent und WordPress herstellt. Authentifiziert wird mit einem WordPress-Anwendungspasswort. Die Oxygen-Dokumentation sagt dazu offen, dass der Agent damit denselben Zugriff hat wie ein angemeldeter Administrator.

Darunter liegt die Abilities API von WordPress, die mit Version 6.9 in den Core kam. Plugins registrieren dort Fähigkeiten mit typisierten Ein- und Ausgaben und einer Berechtigungsprüfung. Der MCP-Adapter von WordPress macht diese Fähigkeiten für MCP-Clients sichtbar und bringt drei eigene Werkzeuge mit: mcp-adapter-discover-abilities, mcp-adapter-get-ability-info und mcp-adapter-execute-ability.

In meiner Claude-Code-Sitzung tauchen diese Adapter-Werkzeuge auf, dazu eine Reihe von Oxygen-Werkzeugen. Die wichtigsten für den Alltag:

• oxygen-get-instructions liefert die aktuelle Arbeitsanleitung des Builders. Der Server verlangt ausdrücklich, dass dieses Werkzeug vor jedem Bau- oder Bearbeitungswerkzeug aufgerufen wird.
• insert-stylesheet legt globale CSS-Variablen und Klassen an, also das Designsystem.
• html-to-page baut aus semantischem HTML mit <style>-Block einen Oxygen-Elementbaum.
• edit-post ändert gezielt Eigenschaften bestehender Elemente, nachdem das Schema mit get-element-schemas gelesen wurde.
• get-post-tree, preview-post und preview-element dienen der Kontrolle: Baum lesen, Frontend-HTML rendern.

Mit Oxygen 6.2 kamen die Vorschau-Werkzeuge hinzu, damit ein Agent seine Arbeit prüfen kann, ohne die ganze Seite im Browser laden zu müssen.

Der Bauweg: erst Designsystem, dann Seiten

Die Reihenfolge ist keine Geschmacksfrage, sie folgt aus der Anleitung, die der Server selbst liefert.

Zuerst kommt das Designsystem. Die Farb-, Typografie- und Abstands-Tokens aus Figma liegen als CSS-Variablen mit dem Präfix --bk- auf der Website, die wiederverwendbaren Klassen tragen das Präfix bc-. Neue Seiten verwenden diese Klassen, statt Werte neu zu erfinden.

/* design-system.css (Auszug, via insert-stylesheet) */
:root {
  --bk-ink-900: #0B0F14;
  --bk-accent: #2F5BEA;
  --bk-code-bg: #0F141B;
  --bk-container: 1280px;
}

.bc-wrap {
  max-width: var(--bk-container);
  margin-inline: auto;
}

Danach entstehen Seiten und Sektionen als ganz normales HTML. Das hat einen praktischen Grund: Ein Sprachmodell schreibt sauberes, semantisches HTML zuverlässiger, als es einen Elementbaum Knoten für Knoten zusammensetzt. html-to-page übersetzt das HTML in Oxygen-Elemente und Selektoren.

<section class="bc-section">
  <div class="bc-wrap">
    <p class="bc-eyebrow">01 Leistungen</p>
    <h2 class="bc-head">Was ich für Sie baue</h2>
    <div class="bc-grid">
      <article class="bc-card">…</article>
    </div>
  </div>
</section>

Zwei Eigenheiten muss man kennen, sonst richtet der Agent Schaden an. html-to-page hängt immer nur an. Wer es ein zweites Mal aufruft, um etwas zu korrigieren, bekommt die Sektion doppelt. Korrekturen laufen deshalb über edit-post. Und insert-stylesheet ersetzt eine Klasse vollständig für den Breakpoint, auf den es zielt. Wer nur eine Eigenschaft ändern will, muss die Klasse vorher mit get-css-selectors auslesen und die komplette Regel mit der Änderung zurückschreiben. Beides steht in meinen Projektregeln, weil ein vergessener Punkt hier sofort auf der Live-Website sichtbar wird.

Figma als Source of Truth

Das visuelle Soll liegt in Figma. Dort gibt es einen Styleguide-Frame mit Tokens und Gestaltungsprinzipien sowie Frames für Header, Footer und jede Seite. Der Agent liest Figma über den Figma-MCP-Server nur lesend.

Figma ist dabei die einzige Quelle der Wahrheit, und zwar zu 100 %. Was in Figma steht, gilt, und die Website wird daran gemessen, nicht umgekehrt. Änderungen am Design entstehen zuerst in Figma und werden dann in Oxygen nachgezogen. So gibt es keine zweite Wahrheit, über die Agent und Reviewer streiten könnten. Weicht die Website ab, ist das ein Befund und kein Ermessensfall.

Agenten mit getrennten Rollen

Ein einzelner Agent, der plant, baut und sich selbst abnimmt, prüft seine eigenen Annahmen. Ich trenne die Aufgaben deshalb auf spezialisierte Subagenten. Claude Code erlaubt es, Subagenten als Markdown-Dateien unter .claude/agents/ zu definieren und ihnen per Frontmatter gezielt Werkzeuge zu geben oder zu entziehen.

Die Hauptsitzung ist der einzige Orchestrator. Sie plant, verteilt Aufträge und entscheidet, welche Prüfung nötig ist. Darunter arbeiten:

• oxygen-builder: der einzige Agent, der auf die Website schreiben darf.
• visual-reviewer: prüft die gerenderte Seite rein visuell gegen Figma, mit Browser und Figma nur lesend.
• website-reviewer: nimmt die Änderung gegen Plan und Abnahmekriterien ab und fällt als einziger das Gesamturteil.
• content-strategist: bearbeitet Texte und darf nur Dateien lesen.

So sieht die Rollendefinition des Builders aus:

# .claude/agents/oxygen-builder.md (Frontmatter, Auszug)
name: oxygen-builder
description: Einziger Website-Schreiber im freigegebenen Implementierungsplan.
model: inherit
omitClaudeMd: true
skills:
  - oxygen-implementation
disallowedTools: Agent, Task, Write, Edit, Bash

Der Builder hat keinen Zugriff auf lokale Dateien und keine Shell. Er arbeitet nur mit den MCP-Werkzeugen. Weitere Agenten starten kann er ebenfalls nicht. Mit omitClaudeMd: true startet der Subagent ohne die CLAUDE.md-Dateien des Projekts. Das ist Absicht: Jeder Agent bekommt vom Orchestrator nur den Ausschnitt an Projektwerten, den sein Auftrag braucht, etwa die relevanten Tokens und die finalen Texte. Die Projektwerte selbst liegen zentral in einigen YAML-Dateien und werden nicht in die Agentendefinitionen kopiert.

Beim visual-reviewer ist die Werkzeugliste abschließend: Navigation, Fensterbreite, Seitenlesung und Screenshots im Browser, dazu Figma lesend. Formulare absenden, speichern oder sich anmelden ist ausdrücklich verboten. Erlaubt sind nur Interaktionen, die beim Neuladen verschwinden, etwa ein Menü öffnen oder Hover auslösen.

Single Writer und Freigabe vor jedem Schreibzugriff

Es gibt für bk-coding.de keine Staging-Umgebung. Jeder Schreibzugriff trifft die Live-Website. Daraus leiten sich die strengsten Regeln des ganzen Aufbaus ab:

1. Geschrieben wird nur mit einem freigegebenen Plan. Analyse und Planung dürfen vorher lesend laufen, die Freigabe gebe ich selbst.
2. Nur der Builder schreibt, und es läuft immer höchstens ein Schreibauftrag. Das gilt auch für verschiedene Seiten, weil sie sich Klassen und Templates teilen.
3. Kein Review startet, solange das Ziel noch verändert wird.

Prüfung: wie viel Review eine Änderung braucht

Nicht jede Änderung braucht denselben Prüfaufwand. Vor jedem Review lege ich deshalb einen von drei Werten fest:

• NONE: keine sichtbare Wirkung, etwa Meta-Daten. Dann prüft nur der website-reviewer Planerfüllung und Funktion.
• MINOR: lokale sichtbare Änderung in einer Sektion, ohne geteilte Klassen oder Templates. Der visual-reviewer prüft eng nur diese Sektion.
• SIGNIFICANT: neue Seite oder Sektion, geteilte Klassen, Tokens, Header oder Footer. Dann folgt eine volle visuelle Prüfung über alle Viewports plus Regressionsseiten, auf denen die geänderten Klassen ebenfalls vorkommen.

Im Zweifel gilt die höhere Stufe. Befunde bekommen eine stabile ID und sind entweder eine Abweichung von einer belegten Vorgabe oder eine Empfehlung ohne konkretes Soll. Nur Abweichungen dürfen eine Korrekturrunde auslösen. Empfehlungen sammle ich und entscheide selbst.

Korrekturschleifen sind begrenzt: höchstens zwei Nachläufe pro Aufgabe und höchstens zwei erfolglose Korrekturversuche pro Befund. Danach stoppt der Ablauf und die Entscheidung liegt bei mir. Ohne diese Grenze kann ein Agent sehr lange an einem Pixel drehen, den er aus technischen Gründen nicht treffen kann.

Grenzen und Risiken

Dieser Aufbau funktioniert für mich, er hat aber klare Schwachstellen.

Live-Schreibzugriffe. Ohne Staging gibt es keinen Probelauf. Ein doppelt ausgeführtes html-to-page oder eine unvollständig zurückgeschriebene Klasse ist sofort öffentlich sichtbar. Die Regeln oben verringern das Risiko, sie beseitigen es nicht.

Verifikation ist Pflicht, und sie ist unvollständig. Der Builder prüft nach jeder Änderung Baum und Vorschau. Das ersetzt kein unabhängiges Review. Auch das Review hat Lücken: Die Browser-Werkzeuge liefern keine verlässlich festen Viewport-Breiten. Deshalb muss jede Breite nach dem Umstellen gemessen werden. Eine nicht bestätigte Breite gilt als „nicht geprüft“, weder als bestanden noch als durchgefallen. Ein Werkzeug für reproduzierbare Viewports ist in Arbeit, aber noch nicht Teil des Ablaufs.

Veraltete Regeln. Auch die Agentenregeln altern. Das Werkzeug entwickelt sich weiter, und eine Annahme, die beim Schreiben einer Regel stimmte, kann später falsch sein. Die Projektdokumentation muss deshalb regelmäßig gegen den tatsächlichen Zustand geprüft werden, genau wie Code.

Abhängigkeit von Betaversionen. Die MCP-Werkzeuge von Oxygen sind neu, die hier eingesetzte Version ist eine Beta. Werkzeugnamen, Parameter und Verhalten können sich ändern. Die Pflicht, zuerst oxygen-get-instructions aufzurufen, fängt einen Teil davon ab, weil die Anleitung vom Server kommt und nicht aus meinem Gedächtnis.