Die WordPress Abilities API ist eine Registry für Operationen, die ein Plugin, ein Theme oder der Core selbst in einem einheitlichen, vorhersehbaren Format deklariert: Name, Kategorie, Eingabe- und Ausgabeschema, Berechtigungsprüfung und ausführende Funktion. Diese Seite ist eine Referenz: was die API ist, wie Sie eine Ability registrieren, welche REST-Endpunkte es gibt, wie Berechtigungen funktionieren, was die Versionen 7.0 und 7.1 ergänzt haben und wo der MCP Adapter ins Spiel kommt. Beispiele für Workflows auf Basis von Abilities finden Sie im Artikel WordPress KI-Workflows mit der Abilities API.
Was ist die WordPress Abilities API
Die Dev Note auf make.wordpress.org definiert eine einzelne Ability so:
“Eine Ability ist eine in sich geschlossene Funktionseinheit mit definierten Eingaben, Ausgaben, Berechtigungen und Ausführungslogik.”
Jonathan Bossenger, Make WordPress Core, Abilities API in WordPress 6.9, eigene Übersetzung
Alle registrierten Abilities landen in einer zentralen Registry. Darauf greifen PHP-Code auf dem Server, der JavaScript-Client im Backend, die REST API und KI-Agenten zu, die über den MCP Adapter angebunden sind. Das Plugin beschreibt eine Operation einmal, und jeder dieser Kanäle sieht sie in derselben Form, mit demselben Schema und derselben Berechtigungsprüfung.
Die Release-Ankündigung zu 6.9 betont die Berechtigungsseite:
“Die neue Abilities API bietet ein standardisiertes, maschinenlesbares Berechtigungssystem, das die Tür für KI-gestützte und automatisierte Workflows der nächsten Generation öffnet.”
WordPress News, WordPress 6.9 “Gene”, eigene Übersetzung
Jede Ability gehört zu genau einer Kategorie:
“Jede Ability muss genau einer Kategorie angehören. Kategorien haben einen Slug, ein Label und eine Beschreibung.”
Common APIs Handbook, Abilities API, eigene Übersetzung
Ab welcher WordPress-Version gibt es die Abilities API
Die Abilities API kam mit WordPress 6.9, erschienen am 2. Dezember 2025, in den Core. Das Handbook sagt es direkt im Hinweiskasten oben auf der Seite:
“Die Abilities API ist nur für WordPress 6.9 und höher verfügbar.”
Common APIs Handbook, Abilities API, eigene Übersetzung
Die folgenden Releases haben die API erweitert, ohne ihre Grundlagen zu ändern:
| Version | Datum | Was neu ist |
|---|---|---|
| 6.9 “Gene” | 2. Dezember 2025 | Registry, Kategorien, Schemas, Berechtigungen, Endpunkte wp-abilities/v1 |
| 7.0 | Dev Note vom 24. März 2026 | JavaScript-Client: @wordpress/abilities und @wordpress/core-abilities |
| 7.1 “Mary Lou” | 19. August 2026 | Flag meta.public, vier Filter für den Ausführungszyklus |
Ein Plugin, das auch auf Installationen älter als 6.9 laufen soll, prüft vor der Registrierung, ob die Funktion existiert: Die Dev Note auf make.wordpress.org empfiehlt die Bedingung function_exists( 'wp_register_ability' ), mit der auch das Beispiel weiter unten beginnt.
Den größeren Zusammenhang von Version 7.0, einschließlich der übrigen KI-bezogenen Änderungen, beschreibt unser Leitfaden zu WordPress 7.0 und der KI-Integration.
Ability in WordPress registrieren
Die Registrierung hat zwei Schritte: zuerst die Kategorie, dann die Ability. Jeder Schritt hat seinen eigenen Hook, und die Reihenfolge ist entscheidend.
Kategorie für eine Ability registrieren
“Kategorien müssen vor den Abilities, die auf sie verweisen, über den Hook wp_abilities_api_categories_init registriert werden.”
Make WordPress Core, Abilities API in WordPress 6.9, eigene Übersetzung
Eine Kategorie hat Slug, Label und Beschreibung. Das Argument category ist bei der Registrierung einer Ability Pflicht und muss auf den Slug einer Kategorie zeigen, die bereits in der Registry existiert.
Der Hook wp_abilities_api_init
Die Ability selbst wird auf einer eigenen Action registriert. An anderer Stelle schlägt die Registrierung fehl:
“Abilities müssen am Action-Hook wp_abilities_api_init registriert werden. Der Versuch, Abilities außerhalb dieses Hooks zu registrieren, löst einen _doing_it_wrong()-Hinweis aus, und die Registrierung der Ability schlägt fehl.”
Make WordPress Core, Abilities API in WordPress 6.9, eigene Übersetzung
wp_register_ability Beispiel
Die Signatur der Funktion laut Code Reference:
function wp_register_ability( string $name, array $args ): ?WP_Ability {Quelle: Code Reference, wp_register_ability().
Bei Erfolg gibt die Funktion die registrierte WP_Ability-Instanz zurück, bei einem Fehler null. Ein minimales Beispiel: eine Kategorie und eine schreibgeschützte Ability, die die Anzahl veröffentlichter Beiträge zurückgibt.
if ( function_exists( 'wp_register_ability' ) ) {
add_action( 'wp_abilities_api_categories_init', function () {
wp_register_ability_category( 'moja-wtyczka', array(
'label' => 'Moja wtyczka',
'description' => 'Operacje udostępniane przez Moją wtyczkę.',
) );
} );
add_action( 'wp_abilities_api_init', function () {
wp_register_ability( 'moja-wtyczka/liczba-wpisow', array(
'label' => 'Liczba opublikowanych wpisów',
'description' => 'Zwraca liczbę opublikowanych wpisów.',
'category' => 'moja-wtyczka',
'output_schema' => array( 'type' => 'integer' ),
'permission_callback' => function () {
return current_user_can( 'edit_posts' );
},
'execute_callback' => function () {
return (int) wp_count_posts()->publish;
},
'meta' => array(
'show_in_rest' => true,
'annotations' => array( 'readonly' => true ),
),
) );
} );
}Diese Ability nimmt keine Daten entgegen und hat deshalb kein input_schema. Sie gibt einen Wert zurück, also ist output_schema Pflicht.
Name und Namespace einer Ability
“Das Format sollte namespace/ability-name sein”
Make WordPress Core, Abilities API in WordPress 6.9, eigene Übersetzung
Der Name besteht aus Kleinbuchstaben, Ziffern, Bindestrichen und einem Schrägstrich. Der Namespace ist meist der Slug des Plugins. Das verhindert Kollisionen zwischen Plugins, die ähnliche Operationen registrieren.
input_schema und output_schema
Die Schemas sind keine Beigabe für die Dokumentation. Der Core validiert danach die Eingabe vor der Ausführung und die Ausgabe danach.
“Schemas zu definieren ist Pflicht, wenn ein Wert übergeben oder zurückgegeben wird.”
Make WordPress Core, Abilities API in WordPress 6.9, eigene Übersetzung
Der Validator deckt nicht die vollständige JSON-Schema-Spezifikation ab:
“WordPress implementiert einen Validator auf Grundlage einer Teilmenge von JSON Schema Version 4.”
Make WordPress Core, Abilities API in WordPress 6.9, eigene Übersetzung
In der Praxis heißt das: Schemas in der Syntax von Draft 4 schreiben und mit Schlüsselwörtern außerhalb dieser Teilmenge vorsichtig sein.
Das output_schema hat noch eine zweite Funktion, die bei personenbezogenen Daten relevant wird. Es legt fest, welche Felder eine Ability überhaupt zurückgeben darf. Wer Abilities für KI-Agenten öffnet, sollte die Ausgabe auf die Felder beschränken, die der Agent für seine Aufgabe braucht, statt komplette Benutzer- oder Bestellobjekte durchzureichen. Das ist Datenminimierung im Sinne der DSGVO, umgesetzt an der Stelle, an der die Daten die Website verlassen.
permission_callback und execute_callback
Beide Callbacks sind Pflicht. Die Code Reference beschreibt sie so:
“Erforderlich. Eine Callback-Funktion, die vor der Ausführung die Berechtigungen prüft.”
Code Reference, wp_register_ability(), eigene Übersetzung
“Erforderlich. Eine Callback-Funktion, die ausgeführt wird, wenn die Ability aufgerufen wird.”
Code Reference, wp_register_ability(), eigene Übersetzung
Der Berechtigungs-Callback sieht dieselben Daten wie der Ausführungs-Callback und kann deshalb abhängig von der konkreten Eingabe entscheiden, etwa nur das Bearbeiten eines Beitrags erlauben, dessen Autor der Benutzer ist:
“Sie erhält dieselbe Eingabe wie der Execute-Callback und muss einen Boolean oder WP_Error zurückgeben”
Code Reference, wp_register_ability(), eigene Übersetzung
Für Abilities, die personenbezogene Daten lesen oder ändern, ist genau das der Ort für die Zugriffskontrolle. Ein pauschales current_user_can( 'edit_posts' ) reicht dann oft nicht: Der Callback sollte prüfen, ob der Benutzer, in dessen Namen der Agent handelt, auf genau diesen Datensatz zugreifen darf. Ein Agent bekommt dabei nie mehr Rechte als das Konto, mit dem er sich authentifiziert. Ein eigenes Benutzerkonto mit eng gefasster Rolle für den Agenten ist deshalb sauberer als ein Administrator-Zugang.
Fehlerbehandlung im execute_callback
Ein Fehler wird als Objekt zurückgegeben, nicht als Exception oder leeres Ergebnis:
“Abilities sollten Fehler kontrolliert behandeln, indem sie WP_Error-Objekte zurückgeben:”
Make WordPress Core, Abilities API in WordPress 6.9, eigene Übersetzung
Annotationen readonly, destructive und idempotent
Die Annotationen in meta.annotations beschreiben den Charakter einer Operation. readonly kennzeichnet eine Ability, die nichts verändert:
“Optional. Wenn true, verändert die Ability ihre Umgebung nicht.”
Code Reference, wp_register_ability(), eigene Übersetzung
Die beiden anderen Annotationen sind destructive und idempotent. Sie sind keine Dekoration: Von ihnen hängt die HTTP-Methode beim Aufruf über REST ab, und ein Client, zum Beispiel ein KI-Agent, kann daran erkennen, ob eine Operation wiederholt werden darf.
Auf dieser Website läuft unser eigener MCP-Server, beschrieben in /.well-known/mcp/server-card.json, und er stellt ausschließlich Lese-Tools bereit. Dasselbe Prinzip bewährt sich bei Abilities: Die erste Version einer Agenten-Integration besteht aus Abilities mit readonly: true, aufgerufen per GET. Schreiboperationen kommen später dazu, jede mit eigenem permission_callback.
REST-Endpunkte der Abilities API
In WordPress 6.9 landet eine Ability nicht automatisch in der REST API. Das muss deklariert werden:
“Das ist möglich, indem man beim Registrieren einer Ability das Argument meta.show_in_rest auf true setzt.”
Make WordPress Core, Abilities API in WordPress 6.9, eigene Übersetzung
Die Endpunkte liegen im Namespace wp-abilities/v1: Liste der Abilities, einzelne Ability und Ausführung. Der Ausführungspfad sieht so aus:
GET|POST|DELETE /wp-abilities/v1/abilities/{name}/runQuelle: Make WordPress Core, Abilities API in WordPress 6.9.
Authentifizierung in der Abilities API
“Der Zugriff auf alle REST-API-Endpunkte der Abilities erfordert einen authentifizierten Benutzer.”
Make WordPress Core, Abilities API in WordPress 6.9, eigene Übersetzung
Das gilt auch für die Liste der Abilities. Es funktionieren das Session-Cookie, Application Passwords oder ein eigener Authentifizierungsmechanismus. Ein anonymer Client sieht nicht einmal, welche Abilities auf der Website existieren.
Ability per REST API aufrufen
Die HTTP-Methode für den Endpunkt run ergibt sich aus den Annotationen. Eine readonly-Ability wird per GET aufgerufen, eine Ability, die zugleich destructive und idempotent ist, per DELETE, und in allen anderen Fällen:
“Alle anderen Fälle: verwendet POST”
Jorge Costa, Make WordPress Core, Client-Side Abilities API in WordPress 7.0, eigene Übersetzung
Die REST-Dokumentation im Projekt-Repository stellt klar, dass das für schreibgeschützte Abilities eine Vorgabe ist und keine Empfehlung:
”- Schreibgeschützte Abilities müssen GET verwenden (
readonly: true)”GitHub, WordPress/abilities-api, docs/rest-api.md, eigene Übersetzung
Bei GET und DELETE steht die Eingabe nicht im Request-Body, sondern im Parameter input als URL-kodiertes JSON. Weil Query-Strings häufig in Server- und Proxy-Logs landen, gehören personenbezogene Daten nicht in die Eingabe einer readonly-Ability. Eine ID, über die der Callback den Datensatz selbst lädt, ist die bessere Wahl.
Abilities API in JavaScript
WordPress 7.0 hat einen browserseitigen Client in zwei Paketen ergänzt. @wordpress/abilities ist der eigentliche Store für Abilities, @wordpress/core-abilities lädt die auf dem Server registrierten Abilities über REST:
“Dadurch werden sowohl @wordpress/core-abilities als auch dessen Abhängigkeit @wordpress/abilities geladen, und alle serverseitigen Abilities werden automatisch abgerufen und registriert.”
Jorge Costa, Make WordPress Core, Client-Side Abilities API in WordPress 7.0, eigene Übersetzung
Fehler im JS-Client haben feste Codes. Eine fehlgeschlagene Validierung liefert ability_invalid_input oder ability_invalid_output, eine verweigerte Berechtigung:
“Wenn der Permission-Callback false zurückgibt, wird ein Fehler mit dem Code ability_permission_denied ausgelöst.”
Jorge Costa, Make WordPress Core, Client-Side Abilities API in WordPress 7.0, eigene Übersetzung
Abilities API in WordPress 7.1
Die Release-Ankündigung zu 7.1 fasst die Änderungen in einem Satz zusammen:
“Die Abilities API baut auf der in WordPress 6.9 eingeführten Infrastruktur auf, mit einem filterbaren Ausführungslebenszyklus, eigener Validierung und gemeinsamer Erkennung.”
WordPress News, WordPress 7.1 “Mary Lou”, eigene Übersetzung
Das public-Flag in der Abilities API
WordPress 7.1 hat meta.public eingeführt, ein gemeinsames Freigabe-Flag für Clients. Es befüllt show_in_rest, ein explizit gesetztes show_in_rest hat aber Vorrang, und der Standardwert bleibt false:
$show_in_rest = $meta['show_in_rest'] ?? $meta['public'] ?? false;Quelle: Milana Cap, Make WordPress Core, A unified public exposure flag for Abilities in WordPress 7.1.
Das Flag regelt die Sichtbarkeit, nicht den Zugriff:
“Das Flag public steuert die Auffindbarkeit und die Freigabe für Clients.”
Milana Cap, Make WordPress Core, A unified public exposure flag for Abilities in WordPress 7.1, eigene Übersetzung
Auch eine als öffentlich markierte Ability durchläuft weiterhin den permission_callback. Das Flag public ersetzt ihn nicht.
Filter für den Ausführungszyklus einer Ability
“Die Abilities API stellte bisher die Actions wp_before_execute_ability und wp_after_execute_ability bereit.”
Make WordPress Core, New execution lifecycle filters for the Abilities API in WordPress 7.1, eigene Übersetzung
Zu diesen beiden Actions aus 6.9 hat Version 7.1 vier Filter hinzugefügt:
| Filter | Ausführungsphase |
|---|---|
wp_pre_execute_ability | vor der Ausführung |
wp_ability_normalize_input | Normalisierung der Eingabe |
wp_ability_permission_result | Ergebnis der Berechtigungsprüfung |
wp_ability_execute_result | Ergebnis der Ausführung |
Mit den Actions ließ sich die Ausführung nur beobachten. Mit den Filtern lässt sie sich beeinflussen, etwa um die Eingabe zu normalisieren oder das Ergebnis der Berechtigungsprüfung zu ändern. Über wp_ability_execute_result kann ein Plugin zum Beispiel Felder aus dem Ergebnis entfernen, bevor es an einen Client geht, ohne die Ability selbst anzufassen.
Abilities API und MCP Adapter
Die Abilities API enthält keinen Server für das Model Context Protocol. Diese Rolle übernimmt ein separates Paket:
“Das offizielle WordPress-Paket für die MCP-Integration, das WordPress-Abilities als Tools, Ressourcen und Prompts des Model Context Protocol (MCP) für KI-Agenten bereitstellt.”
GitHub, WordPress/mcp-adapter, README, eigene Übersetzung
Die Standardeinstellung ist zurückhaltend:
“WordPress-Abilities sind standardmäßig privat.”
GitHub, WordPress/mcp-adapter, README, eigene Übersetzung
Damit ein MCP-Client eine Ability sieht, muss meta.public (oder meta.mcp.public) auf true stehen. Der Standardserver des Adapters stellt drei Meta-Tools bereit, über die ein Agent Abilities entdeckt und aufruft. Die Verbindung:
“Verbinden Sie sich per WP-CLI über STDIO, oder richten Sie einen HTTP-Client auf
/wp-json/mcp/mcp-adapter-default-server.”GitHub, WordPress/mcp-adapter, README, eigene Übersetzung
STDIO über WP-CLI passt zur lokalen Entwicklung und zum Staging, HTTP zu einem Agenten, der außerhalb des Servers läuft. In beiden Fällen entscheiden dieselben permission_callback und Annotationen darüber, was der Agent tun darf. Läuft der Agent bei einem externen KI-Anbieter, verlassen die Ergebnisse der Abilities die eigene Infrastruktur. Welche Abilities Sie öffentlich schalten, ist deshalb auch eine Frage für Ihr Verzeichnis von Verarbeitungstätigkeiten, nicht nur für die Entwicklung.
Ausführlicher beschreiben wir die Anbindung von WordPress an KI-Agenten über MCP im Leitfaden MCP- und KI-Integration. Wenn Sie einen eigenen MCP-Server oder ein Set von Abilities für einen konkreten Shop oder eine Website brauchen, finden Sie das auf der Seite MCP-Server-Entwicklung für WordPress.
Prüfen, ob WordPress die Abilities API unterstützt
Am einfachsten im Code: function_exists( 'wp_register_ability' ) gibt ab Version 6.9 true zurück. Von außen genügt mit einem Konto und Application Password eine Abfrage des Namespace wp-abilities/v1 in der REST API der Website. Fehlt er, läuft die Website auf einer Version vor 6.9, oder etwas blockiert die REST API. Die Liste enthält nur Abilities mit show_in_rest oder public auf true. Eine leere Liste bedeutet also nicht, dass Plugins keine Abilities registrieren.
Letzte Prüfung der Quellen: 6. Oktober 2026.
