Zum Hauptinhalt springen

Wer ein Plugin oder Theme entwickelt, kann dessen Funktionen über die Abilities API (Core seit 6.9) bereitstellen. Damit werden sie für Editor-Integrationen, Automatisierungen und, über den MCP Adapter, für KI-Agenten nutzbar, ohne eigene REST-Routen und eigene KI-Schnittstellen.

Bestandteile einer Ability

  • Name mit Namespace: flake/kb-artikel-statistik
  • Label und Beschreibung: Die Beschreibung liest später ein Sprachmodell. Sie sollte klar sagen, wann die Ability sinnvoll ist.
  • Kategorie zur Gruppierung
  • Input- und Output-Schema (JSON Schema): Eingaben werden validiert, bevor Code läuft.
  • permission_callback: wer die Ability ausführen darf
  • execute_callback: die eigentliche Logik
  • Meta/Annotations: z. B. ob sie nur liest oder destruktiv ist, ob sie in REST erscheint

Beispiel

add_action( 'wp_abilities_api_categories_init', function () {
    wp_register_ability_category( 'flake-kb', [
        'label'       => 'Wissensdatenbank',
        'description' => 'Funktionen rund um die Wissensdatenbank.',
    ] );
} );

add_action( 'wp_abilities_api_init', function () {
    wp_register_ability( 'flake/kb-artikel-statistik', [
        'label'       => 'KB-Artikel zählen',
        'description' => 'Liefert die Anzahl veröffentlichter und entworfener Artikel der Wissensdatenbank. Nur lesend.',
        'category'    => 'flake-kb',
        'input_schema'  => [
            'type'       => 'object',
            'properties' => [ 'post_type' => [ 'type' => 'string', 'default' => 'epkb_post_type_1' ] ],
            'additionalProperties' => false,
        ],
        'output_schema' => [
            'type'       => 'object',
            'properties' => [ 'publish' => [ 'type' => 'integer' ], 'draft' => [ 'type' => 'integer' ] ],
        ],
        'permission_callback' => fn() => current_user_can( 'edit_posts' ),
        'execute_callback'    => function ( array $input ): array {
            $counts = wp_count_posts( sanitize_key( $input['post_type'] ?? 'epkb_post_type_1' ) );
            return [ 'publish' => (int) $counts->publish, 'draft' => (int) $counts->draft ];
        },
        'meta' => [
            'annotations'  => [ 'readonly' => true, 'destructive' => false ],
            'show_in_rest' => true,
        ],
    ] );
} );

Ausführen in PHP: wp_get_ability( 'flake/kb-artikel-statistik' )->execute( [] );. Über REST sind registrierte Abilities unter /wp-json/wp-abilities/v1/ erreichbar, sofern show_in_rest gesetzt ist.

Für MCP freigeben

Damit der MCP Adapter eine Ability für externe Agenten anbietet, muss sie dafür freigegeben werden (je nach Adapter-Version per Meta-Eintrag oder per Server-Konfiguration). Vorgehen und Schlüsselnamen in der aktuellen Adapter-Dokumentation nachschlagen, da sich das Paket noch schnell entwickelt.

Best Practices

  • Kleine, klar abgegrenzte Abilities statt „Mach-alles“-Funktionen. Ein Modell wählt präziser, und Berechtigungen lassen sich feiner steuern.
  • Beschreibungen für Maschinen schreiben: Was tut sie, was nicht, welche Nebenwirkungen hat sie?
  • Strikte Schemas mit additionalProperties: false, Enums und Grenzen. Trotzdem im Callback sanitizen; das Schema ist keine Escaping-Funktion.
  • Permission Callback nie auf __return_true, ausser die Ability ist wirklich öffentlich und harmlos.
  • Destruktive Abilities kennzeichnen und möglichst so bauen, dass sie Entwürfe erzeugen oder in den Papierkorb verschieben statt endgültig zu löschen.
  • Fehler als WP_Error mit verständlicher Meldung zurückgeben. Agenten können darauf reagieren.

Weiterführende Artikel

Quellen und Dokumentation