WordPress als MCP-Server: Wie AI-Agenten mit Ihrer Website arbeiten

Seit Februar 2026 gibt es den offiziellen WordPress MCP Adapter: Er macht Funktionen Ihrer Website über das Model Context Protocol für KI-Agenten wie Claude oder Cursor nutzbar. Aus einer Website, die man nur besucht, wird damit eine, die eine KI gezielt bedienen kann — Beiträge anlegen, Bestellungen prüfen, Reports ziehen. Der Schlüssel dazu heisst Sicherheit.

MCP ist der Standard, über den KI-Assistenten mit externen Systemen sprechen. Für WordPress ist er kein Zukunftsversprechen mehr, sondern real einsetzbar. Dieser Beitrag erklärt, was dahintersteckt, was ein Agent damit tun kann — und warum die Rechtevergabe über Erfolg oder Risiko entscheidet.

Was ist MCP — und was hat WordPress damit zu tun?

Das Model Context Protocol (MCP) ist ein offener Standard, über den KI-Assistenten mit externen Systemen kommunizieren — statt aus einer Website zu «erraten», was möglich ist, bekommt die KI eine klare Liste von Werkzeugen. In WordPress liefert die Abilities API (seit Core 6.9) das Fundament: Plugins, Themes und der Kern registrieren ihre Funktionen als benannte «Abilities» mit Beschreibung, definierten Ein- und Ausgaben und Rechteprüfung. Der MCP Adapter — ein separates offizielles Plugin, kein Core-Bestandteil — übersetzt diese Abilities in MCP-Werkzeuge, die ein Agent entdecken und aufrufen kann.

Was ein KI-Agent auf Ihrer Website tun kann

Produktiv im Einsatz sind heute vor allem lesende und gut abgegrenzte Aufgaben: Website-Informationen und Statusberichte abrufen, Inhalte entwerfen und anlegen, im Shop Produkte und Bestellungen verwalten, wiederkehrende Massenaufgaben erledigen oder mehrere Seiten aus einer Agentursicht überblicken. Entscheidend ist der Zuschnitt: Ein Agent, der Reports zieht und Entwürfe vorbereitet, ist etwas anderes als einer, der eigenständig löschen darf. Genau hier setzt die Rechtevergabe an.

Sicherheit entscheidet über alles

Ein MCP-Client handelt als eingeloggter WordPress-Benutzer und erbt dessen Rechte — ein Admin-Token gäbe dem Agenten volle Admin-Macht. Die offizielle Empfehlung ist deshalb eindeutig: ein dedizierter Benutzer mit minimalen Rechten (Least Privilege), niemals ein Admin. Für über das Internet erreichbare Seiten rät die Dokumentation zu rein lesendem Zugriff (Diagnostik, Reporting, Inhalte lesen); schreibende oder löschende Werkzeuge gehören nicht offen ins Netz. Dazu kommt ein KI-typisches Risiko: Prompt-Injection — manipulierte Inhalte, die der Agent abruft, können ihn zu unerwünschten Aktionen verleiten. Kurzlebige Tokens, minimale Rechte und lesender Default sind die verantwortbare Grundhaltung.

Für Webseitenbetreiber: Was bedeutet das für Ihre Website?

Sie müssen nicht sofort einen KI-Agenten auf Ihre Seite lassen — aber es lohnt sich zu wissen, was möglich ist. Der sinnvolle Einstieg ist klein und sicher: ein lesender Zugang für Reports oder ein eng umrissener Helfer für wiederkehrende Aufgaben, mit einem eigenen, rechtebeschränkten Benutzer. Genau so ein Setup planen und härten wir — von den Schnittstellen bis zur sicheren Rechtevergabe. Wie sich das in den grösseren KI-Trend einordnet, lesen Sie im Überblick KI in WordPress; einen KI-Assistenten fürs Publikum behandelt der Beitrag KI-Assistent auf der Website.

Für Agenturen und Entwickler: die Technik

Die serverseitige Abilities API ist seit WordPress 6.9 im Core (7.0 ergänzte eine clientseitige JS-Variante). Eine Ability registriert man mit wp_register_ability() inklusive permission_callback — den man immer setzen sollte, damit jede Aktion die minimal nötige Berechtigung prüft (etwa edit_posts statt manage_options). Der offizielle wordpress/mcp-adapter (Plugin oder Composer-Package, WP 6.9+/PHP 7.4+) exponiert eine Ability nur dann als MCP-Werkzeug, wenn meta.mcp.public auf true steht (Default: privat), und stellt STDIO- sowie HTTP-Transport bereit. Der ältere Automattic/wordpress-mcp ist seit Januar 2026 archiviert — kanonisch ist der Adapter. Als Drittanbieter-Option bringt «Agent Abilities for MCP» (auf wordpress.org, self-hosted) 153 kuratierte, standardmässig deaktivierte Abilities mit. Wichtig: Der Adapter ist noch 0.x mit dokumentierten Breaking Changes — für den Produktiveinsatz die Version pinnen.

Konkret sieht eine minimale, rein lesende Ability so aus — registriert am Hook wp_abilities_api_init, mit einem permission_callback, der nur die nötige Capability prüft, und meta.mcp.public, das die Ability überhaupt erst zum MCP-Werkzeug macht:

add_action( 'wp_abilities_api_init', function () {
    wp_register_ability( 'wpprofis/site-status', array(
        'label'         => 'Website-Status abrufen',
        'description'   => 'Kernversion, aktive Plugins und offene Updates.',
        'category'      => 'wpprofis',
        'output_schema' => array(
            'type'       => 'object',
            'properties' => array(
                'core_version'    => array( 'type' => 'string' ),
                'pending_updates' => array( 'type' => 'integer' ),
            ),
        ),
        'execute_callback'    => 'wpprofis_site_status',
        'permission_callback' => function () {
            return current_user_can( 'edit_posts' ); // minimal, kein manage_options
        },
        'meta' => array(
            'show_in_rest' => true,
            'mcp'          => array( 'public' => true ), // erst dadurch MCP-Werkzeug
            'annotations'  => array( 'readonly' => true ),
        ),
    ) );
} );

Von der Ability zum verbundenen Client sind es dann vier Schritte: (1) den mcp-adapter installieren (Version pinnen); (2) einen dedizierten Benutzer mit schlanker Rolle anlegen — z. B. nur read und edit_posts, kein manage_options — und dafür ein Application Password erzeugen; (3) der Adapter stellt den Endpunkt /wp-json/mcp/mcp-adapter-default-server bereit; (4) im Client (z. B. Claude Desktop) den lokalen Proxy @automattic/mcp-wordpress-remote eintragen, der die Verbindung vermittelt. Zwei Sicherheits-Schichten greifen dabei zusammen: die Benutzerrolle und der permission_callback jeder Ability. Und der Transport entscheidet über das Risiko — STDIO (lokal via WP-CLI) ist unkritisch, HTTP ist übers Netz erreichbar und gehört darum auf read-only und minimale Rechte beschränkt.

Fazit

WordPress wird zu einem System, das KI-Agenten nicht nur lesen, sondern gezielt bedienen können — über einen offiziellen, offenen Standard. Das eröffnet echte Effizienzgewinne, verlangt aber Disziplin bei den Rechten: eigener Benutzer, minimale Berechtigungen, lesender Default, kurzlebige Tokens. Wer klein und sicher startet, nutzt die Chance, ohne die Kontrolle abzugeben.

Häufig gestellte Fragen zu WordPress und MCP

Quellen

• WordPress Developer News — From Abilities to AI Agents: Introducing the WordPress MCP Adapter (2026)
• Make WordPress Core — Abilities API in WordPress 6.9 (2025)
• OWASP — MCP Security Cheat Sheet