WordPress 7.0 brengt de AI Client. De Abilities API en MCP Adapter zijn waar pluginontwikkelaars eerst tijd in moeten steken.

WordPress 7.0 verschijnt vandaag, 20 mei 2026. De headline-feature in elk persbericht is de AI Client, een provider-onafhankelijke PHP-API waarmee plugins via één interface met Anthropic, Google en OpenAI kunnen praten. Heel handig, en het is het stuk waar elke demo deze week omheen gebouwd wordt. Maar het is niet de belangrijkste AI-infrastructuur die WordPress de afgelopen zes maanden heeft uitgebracht. De Abilities API, die in november 2025 stilletjes in WordPress 6.9 landde, en de MCP Adapter, die nog steeds een aparte plugin is, vormen samen de architecturale gok. Als je pluginontwikkelaar bent, zou ik daar mijn eerste leerweken in stoppen, niet in de AI Client.

TL;DR

• De AI Client (nieuw in 7.0) maakt van WordPress een aanroeper van AI-providers. Drie regels code, direct zichtbaar resultaat, geen ecosysteemwerk vereist.
• De Abilities API (sinds 6.9 in core) en de MCP Adapter (aparte plugin, nu v0.5.0) maken van WordPress een aanroepbare partij die externe AI-agents zoals Claude, Cursor en ChatGPT kunnen ontdekken en aanroepen.
• Die aanroepbare interface overleeft elke individuele providerrelatie. De AI Client is een dunne abstractie die concurreert met wat een goede HTTP-library al doet.
• Core levert nul kostenbeheersing en nul rate limits voor AI Client-gebruik. Spendinglimieten bij de provider zelf zijn nog steeds je enige vangnet. API-keys worden onversleuteld in de database opgeslagen (ticket #64789).

Inhoudsopgave

• Wat is nieuw op 20 mei en wat was er al
• De AI Client is het stuk waar iedereen mee gaat demonstreren
• De Abilities API is het primitief dat ertoe doet
• Een ability bouwen die het waard is om te delen
• Met MCP wordt de ability een tool die agents kunnen aanroepen
• Het gat in kostenbeheersing dat nog niemand dicht heeft
• De beveiligingsgaten waar je omheen moet ontwerpen
• Wat pluginontwikkelaars eerst moeten leren
• Belangrijkste punten

Wat is nieuw op 20 mei en wat was er al

Een verrassend groot deel van het WordPress AI-verhaal zit al een half jaar verstopt in het zicht. De Abilities API zit sinds WordPress 6.9 in november 2025 in de core. Het is de functie waarmee een plugin of theme een afzonderlijk stuk functionaliteit kan registreren (denk aan: "vat een post samen", "plan een refund", "tag een afbeelding") inclusief permission-check, input-schema en output-schema. Niets daarvan is AI-specifiek. Het is gewoon een schone, herbruikbare beschrijving van wat je code kan.

WordPress 7.0 voegt vandaag drie dingen toe boven op die basis. Eerst de PHP AI Client (wordpress/php-ai-client, op dit moment v1.3.1), die nu in core gebundeld is, met een WordPress-wrapper die je via wp_ai_client_prompt() aanroept. Dan de Connectors API, die sitebeheerders een Settings > Connectors-pagina geeft om provider-credentials in te stellen. En tot slot twee JavaScript-packages (@wordpress/abilities en @wordpress/core-abilities) die abilities ook in de blockeditor brengen.

De MCP Adapter zit niet in core. Dat is een aparte plugin, op dit moment v0.5.0, die het AI-team bewust op een eigen release-cadens houdt. De oudere Automattic/wordpress-mcp-repo is op 19 januari 2026 gearchiveerd; WordPress/mcp-adapter is voortaan de canonieke implementatie.

Voor context over wat de release van 20 mei betekent voor de eindgebruiker is mijn WordPress 7.0-overzicht de versie voor site-eigenaren. Dit artikel is de pluginontwikkelaarsversie.

De AI Client is het stuk waar iedereen mee gaat demonstreren

De AI Client is onweerstaanbaar om mee te demonstreren omdat hij in drie regels zichtbaar resultaat oplevert:

$result = wp_ai_client_prompt(
    'Summarize this article in 2-3 sentences: ' . $post_content
)
    ->using_max_tokens( 200 )
    ->using_temperature( 0.5 )
    ->generate_text();

if ( is_wp_error( $result ) ) {
    return $result;
}

Het volledige builder-oppervlak staat in de introductie-post. Daar zitten ook using_model_preference(), with_system_instruction(), as_json_response(), generate_image(), is_supported_for_text_generation() en een GenerativeAiResult als return-type, met token-verbruik in de metadata. (Belangrijk: ik citeer dit van het gedocumenteerde API-oppervlak tijdens de RC-cyclus. Lees je dit na een 7.0.1-patch, kijk dan even of de signatures nog kloppen in het handbook.)

Credentials komen in deze code niet voor. De sitebeheerder configureert keys onder Settings > Connectors, en de AI Client lost ze op tijdens de aanroep. Dat is netjes ontworpen. Als pluginontwikkelaar beschrijf je wat je nodig hebt (een tekstgeneratie, een temperatuur, een max-tokencount) en core regelt de rest.

Maar drie dingen krijg je hier níet. Je krijgt geen manier waarop een externe AI-agent jouw plugin kan aanroepen. Je krijgt geen budget. En je krijgt geen manier waarop een andere plugin kan ontdekken dat jouw "vat een post samen"-feature überhaupt bestaat. Voor alle drie heb je de Abilities API nodig.

De Abilities API is het primitief dat ertoe doet

De Abilities API doet één ding goed. Hij laat je een getypeerde, permission-bewaakte, schema-gevalideerde functie bij WordPress registreren, en laat vervolgens iedereen (je eigen UI, de REST API, een MCP-client, de blockeditor) hem ontdekken en uitvoeren.

Klinkt bescheiden. Is het niet. De reden dat het ertoe doet, is dat "iedereen" ook dingen omvat die WordPress vandaag nog niet kent. Een AI-agent die nu nog niet bestaat, gemaakt door een vendor die nu nog niet bestaat, kan zich straks verbinden met een WordPress-site die vijf jaar geleden zijn abilities heeft geregistreerd, en uitvogelen wat die site kan. Dat is wat de Abilities API je geeft, en wat de AI Client je niet geeft.

Een handige manier om hiernaar te kijken: de AI Client maakt van WordPress een aanroeper. Abilities + MCP maken van WordPress een aanroepbare partij. Die aanroepbare interface overleeft de provider-volatiliteit. Anthropic, Google en OpenAI gaan de komende jaren stijgen, dalen, hernoemen en elkaar opkopen. De afspraak "WordPress-sites beschrijven wat ze kunnen via abilities, en agents roepen die abilities aan via MCP" is precies het soort conventie dat één vendor overleeft.

Belangrijke nuance: dit is een architectuurargument, geen marktwaarneming. Op dit moment, mei 2026, is de AI Client wat AI-functies binnen WordPress mogelijk maakt. De combinatie Abilities + MCP heeft het ecosysteem nodig dat zinvolle abilities registreert voordat de waarde echt gaat compounden. Doen pluginontwikkelaars dat werk niet, dan heeft de architectuur niets om aan te bieden. De spine van dit artikel is dus niet "negeer de AI Client". Het is "als je maar tijd hebt voor één ding om grondig te leren, leer dan de Abilities API, want dat is het stuk dat WordPress als AI-native platform vasthoudt, ongeacht welke provider wint".

Een ability bouwen die het waard is om te delen

Een echte ability heeft vier bewegende delen: een stabiele genamespace-de ID, een input-schema, een permission-callback en een execute-callback. Zo ziet een geloofwaardige "vat een post samen"-ability eruit:

add_action( 'wp_abilities_api_init', function () {
    wp_register_ability(
        'acme-summarizer/summarize-post',
        array(
            'label'       => __( 'Summarize a post', 'acme-summarizer' ),
            'description' => __(
                'Generates a 2-3 sentence summary of a published post.',
                'acme-summarizer'
            ),
            'category'    => 'content',
            'input_schema' => array(
                'type'       => 'object',
                'properties' => array(
                    'post_id' => array(
                        'type'        => 'integer',
                        'description' => 'The published post ID to summarize.',
                    ),
                ),
                'required'   => array( 'post_id' ),
            ),
            'output_schema' => array(
                'type'       => 'object',
                'properties' => array(
                    'summary' => array( 'type' => 'string' ),
                ),
            ),
            'execute_callback'    => 'acme_summarize_post',
            'permission_callback' => function ( $input ) {
                return current_user_can( 'edit_post', $input['post_id'] );
            },
            'meta' => array(
                'show_in_rest' => true,
                'mcp'          => array( 'public' => true ),
            ),
        )
    );
} );

Een paar dingen verdienen een eigen alinea.

De namespace-prefix (acme-summarizer/) is in de praktijk niet optioneel. Er is geen globaal abilities-register, maar wp_get_abilities() levert wel alles wat op de site is geregistreerd, en een platte namespace produceert botsingen op het moment dat twee plugins allebei een summarize-post-ability shippen. Gebruik gewoon je plugin-slug.

De permission_callback draait vóór de uitvoering en krijgt de gevalideerde input mee. Behandel hem als de enige regel tussen een externe agent en je data. current_user_can( 'edit_post', $input['post_id'] ) klopt, omdat het de check koppelt aan de specifieke post die wordt samengevat, en niet aan een algemene "gebruiker mag iets bewerken". De Abilities API maakt nog geen onderscheid tussen "deze aanroep komt van een ingelogde admin in de blockeditor" en "deze aanroep komt van Claude Desktop via MCP". Je callback ís het hele toegangsoppervlak.

Het input_schema werkt tegelijk als documentatie voor de AI-provider die deze ability uiteindelijk gaat aanroepen. Een slordig schema verwart modellen. Een helder, goed beschreven schema wordt een heldere, goed gevormde function call. Behandel het als een publiek API-contract, want voor elke agent die ooit met deze site verbindt, is dat exact wat het is.

De flags meta.show_in_rest en meta.mcp.public bepalen hoe deze ability bereikbaar wordt. De eerste opent een endpoint op POST /wp-json/wp-abilities/v1/abilities/acme-summarizer/summarize-post/run. De tweede is wat de MCP Adapter zoekt.

Met MCP wordt de ability een tool die agents kunnen aanroepen

De MCP Adapter, op dit moment v0.5.0, is een aparte plugin die je naast je code installeert. Het contract is simpel: elke geregistreerde ability met meta.mcp.public => true wordt automatisch een MCP-tool op de default-server (mcp-adapter-default-server). Externe agents die via MCP verbinden, ontdekken hem, zien het input-schema en kunnen hem aanroepen.

Er zijn twee transports. STDIO is voor lokale ontwikkeling via WP-CLI en past natuurlijk bij de workflow die ik behandelde in WordPress Playground + MCP. HTTP is voor productiesites en gebruikt de MCP-specificatie 2025-06-18, met application passwords als primair authenticatiemechanisme. Een first-party OAuth-oplossing voor self-hosted sites is er nog niet.

Heb je meer controle nodig dan de default-server biedt (bijvoorbeeld een subset van abilities scopen op een specifieke MCP-client, of een eigen server draaien met strengere validatie), dan biedt de adapter een mcp_adapter_init-hook en een $adapter->create_server()-methode. Voor de meeste pluginontwikkelaars is de default-server met selectief geplaatste meta.mcp.public-flags genoeg.

Eén voetangel is het noemen waard. Anthropic's function calling verwacht tool-namen die matchen op ^[a-zA-Z0-9_-]{1,64}$, maar ability-namen gebruiken slashes (acme-summarizer/summarize-post). De praktijk (J.CV's uitwerking over agentic loops is het helderste stuk dat ik erover gelezen heb) heeft zich gevormd rond het mappen van / naar __ zodra je abilities aan Anthropic-modellen doorgeeft. Bouwt je plugin een eigen agent-loop boven op de AI Client en Abilities, dan loop je hier tegenaan. De MCP Adapter doet die mapping zelf voor MCP-clients, dus dit speelt vooral bij in-process function calling, niet bij externe agents.

Het gat in kostenbeheersing dat nog niemand dicht heeft

Dit is de sectie die ik elke pluginontwikkelaar voor 21 mei wil laten internaliseren.

WordPress 7.0 levert nul kostenbeheersing in core. Geen maandbudget in tokens, geen spendinglimiet per plugin, geen rate limit, geen admin-dashboard dat laat zien welke plugins hoeveel verbruiken. De AI Client geeft je using_max_tokens() om één request te begrenzen. Dat is het.

De enige hek-achtige controle is de filter wp_ai_client_prevent_prompt, die een prompt volledig kan blokkeren op basis van rol, plugin-identiteit of een willekeurige andere conditie. Hij is binair. Blokkeren of doorlaten. Niet "blokkeren nadat deze gebruiker deze maand 50.000 tokens heeft verbruikt".

add_filter( 'wp_ai_client_prevent_prompt', function ( $prevent ) {
    if ( ! current_user_can( 'edit_others_posts' ) ) {
        return new WP_Error(
            'ai_disabled',
            __( 'AI features are unavailable for this role.', 'acme-summarizer' )
        );
    }
    return $prevent;
}, 10 );

Daarbuiten is je enige betrouwbare vangnet een spendinglimiet bij de provider zelf. Stel een harde maandlimiet in bij OpenAI, Anthropic en Google voordat je ooit een key in Settings > Connectors plakt. De AI Contributor Weekly Summary van 9 april bevestigde dat rate limits en fallback-gedrag "larger themes requiring asynchronous discussion" zijn, wat de beleefde manier is om te zeggen: het staat op de roadmap maar haalt de release van 20 mei niet. Ticket #64706 houdt een configuratie-constante bij om AI volledig uit te schakelen, maar dat is een kill switch, geen budget.

Gaat je plugin op enige schaal AI Client-aanroepen doen, schrijf dan vandaag nog je eigen quotum per gebruiker en je eigen maandbudget in de wp_ai_client_prevent_prompt-filter. Voordat hij ship. De plugins die de eerste golf ontevreden AI-rekeningen overleven, zijn de plugins die zelf de remmen hebben ingebouwd.

De beveiligingsgaten waar je omheen moet ontwerpen

Twee zijn het waard om te kennen en omheen te ontwerpen.

API-keys worden onversleuteld in de database opgeslagen, alleen gemaskeerd in de admin-UI. Ticket #64789 houdt het encryptiewerk bij, en de Connectors API ondersteunt drie credential-bronnen in volgorde van prioriteit: environment variable, PHP-constante en pas dan de database. Ship je plugin aan klanten waar je environment variables van vertrouwt, raad die route dan aan in je readme. Voor zwaardere deployments is een database-dump uit een gecompromitteerde backup een credential leak.

Sandboxing voor MCP-aangeroepen abilities bestaat niet. Je permission_callback is het hele toegangsoppervlak, en hij kan niet zien of hij wordt aangeroepen vanuit een ingelogde editor in de blockeditor, een geauthenticeerd REST-verzoek of een MCP-client die met een application password verbindt. Doet je ability iets destructiefs, schrijf de permission-check dan alsof elke aanroeper vijandig kan zijn. current_user_can( 'edit_post', $post_id ) is goed. return true; is een toekomstig incidentrapport.

De MCP Adapter-readme is verder duidelijk over de Jetpack Autoloader, die "highly recommended" is om versieconflicten te voorkomen wanneer meerdere plugins van de adapter afhangen. Levert je plugin de MCP Adapter mee als dependency, volg dat advies dan ook gewoon op.

Wat pluginontwikkelaars eerst moeten leren

Heb je één weekend, lees dan de Abilities API-handbook en schrijf drie abilities voor een bestaande plugin. Pak de drie operaties die een AI-assistent het meest plausibel zou willen aanroepen ("maak een concept van een outline", "tag een afbeelding", "plan een post"). Krijg de input-schemas op orde. Krijg de permission-callbacks op orde.

Heb je een tweede weekend, installeer dan de MCP Adapter, markeer die drie abilities als meta.mcp.public => true en koppel Claude Desktop of Cursor aan je lokale site. Kijk wat er gebeurt zodra een externe agent jouw schema's leest.

Heb je een derde weekend, schrijf dan de AI Client-integratie. Op dat punt weet je al waar je de kostenbeheersing moet plaatsen, waar je de permission-checks moet plaatsen, en waarom de AI Client het makkelijke deel is.

De plugins die de komende twee jaar van WordPress AI gaan winnen, zijn niet de plugins met de indrukwekkendste wp_ai_client_prompt()-demo. Het zijn de plugins met de schoonste abilities, de strengste permission-callbacks en de zorgvuldigst geplaatste MCP-exposure. Dat werk compoundt. De AI Client-demo niet.

Belangrijkste punten

• De Abilities API zit sinds WordPress 6.9 (november 2025) in de core. De MCP Adapter is een aparte plugin, nu v0.5.0, die bewust buiten core wordt gehouden. De AI Client is wat vandaag nieuw is in 7.0.
• Abilities + MCP maken WordPress aanroepbaar voor externe AI-agents. Die aanroepbare interface overleeft elke individuele provider. De AI Client is een dunne abstractie die grotendeels concurreert met een goede HTTP-library.
• Een echte ability heeft een namespaced ID, een input-schema, een permission_callback die de daadwerkelijke operatie bewaakt en meta.mcp.public => true als je wilt dat agents hem vinden.
• WordPress 7.0 levert geen kostenbeheersing. De wp_ai_client_prevent_prompt-filter is binair. Spendinglimieten bij de provider en een zelfgebouwd quotum per gebruiker zijn je enige reële vangnetten.
• API-keys in de Connectors API zijn onversleuteld in de database. Raad environment variables of PHP-constanten aan voor elke deployment die credentialbeveiliging serieus neemt.