WordPress AI workflows with the Abilities API

#What Is the WordPress Abilities API?

#The Problem with Current Approaches

The WordPress REST API is powerful but resource-centric. It exposes endpoints like /wp/v2/posts and /wc/v3/products - CRUD operations on data objects. An AI agent can use these endpoints, but it needs to be pre-programmed to know what each endpoint does, what parameters it accepts, and how to chain multiple calls together to accomplish a goal.

WPGraphQL improves on this by allowing flexible queries, but it shares the same fundamental limitation: it describes data, not capabilities.

Consider this scenario: you want an AI agent to “write a blog post about spring gardening, optimize it for SEO, add a featured image, and schedule it for next Tuesday.” With the REST API, the agent needs to:

1. Know the /wp/v2/posts endpoint and its parameters
2. Know that SEO data lives in a meta field controlled by Yoast or RankMath
3. Know how to upload media via /wp/v2/media
4. Know the date format for scheduling
5. Chain these calls in the correct order

With the Abilities API, a plugin can register narrow operations such as content/create-draft or media/attach-image. An authenticated integration may list abilities exposed through REST, inspect their schemas and call the appropriate /run endpoint. Workflow planning and dependency handling remain the caller’s responsibility unless the plugin provides one higher-level operation.

#Architecture overview

The API has four parts. A category groups related operations. An ability carries a unique namespace/ability-name, a label, a description, schemas and callbacks. The registry lets WordPress code discover abilities. REST exposure is an optional transport for authenticated external systems.

Registration happens on dedicated hooks. Categories use wp_abilities_api_categories_init, while abilities use wp_abilities_api_init. The public functions are wp_register_ability_category() and wp_register_ability(). This timing matters: registering on a generic plugin-load hook can run before the registries are ready.

The official handbook documents the server-side API for WordPress 6.9 and newer. WordPress 7.0 adds client-side packages that can load server abilities into JavaScript in the admin. That addition does not replace the PHP registry or its permission model.

#REST discovery and execution

REST exposure is disabled by default. A plugin opts in per ability with meta.show_in_rest. Once enabled, authenticated clients can list abilities under /wp-json/wp-abilities/v1/abilities, retrieve one by namespace and name, and call its /run endpoint. The method depends on the ability annotations and behaviour.

WordPress REST authentication still applies. Same-origin code can use cookie authentication. The official REST documentation recommends Application Passwords for external access and also allows custom authentication plugins. Listing an ability does not grant permission to execute it; WordPress evaluates that ability’s permission_callback for the current user.

The distinction is useful in practice. A plugin may register an internal ability for use by other PHP code while leaving show_in_rest false. Another read-only ability may be exposed to a service account with limited WordPress capabilities. A destructive operation should have a narrower permission callback and additional application controls.

#Connecting an AI or MCP layer

The Abilities API provides structured descriptions and JSON schemas. Those fields can help an integration translate a WordPress ability into the tool format expected by an agent. Translation is still integration work.

WordPress core does not automatically expose an MCP endpoint or provider-specific plugin manifest. A bridge must authenticate to WordPress, select allowed abilities, translate schemas, enforce its own limits and map errors back to the client. It should expose fewer operations than the WordPress user can perform, not every discovered ability.

For example, a support assistant may receive a read-only product lookup and a draft-ticket operation. Refunds, user deletion and settings changes stay outside the bridge. This separation is easier to review than giving one general-purpose agent an administrator account.

#What WordPress 7.1 changes

WordPress 7.1 is scheduled for 19 August 2026 and touches this API in three places: exposure, discovery and the filters around it.

#A unified public flag

Exposure has so far been declared per channel, and show_in_rest was the only channel that mattered in practice. WordPress 7.1 adds a single key at meta['public']. The developer note describes it as follows: “The flag provides a single, high-level way to indicate that an ability is intended to be available to external clients such as the REST API.”

It replaces nothing. Channel-specific flags stay supported and win wherever both are set, which core resolves in one line, $show_in_rest = $meta['show_in_rest'] ?? $meta['public'] ?? false;. So an ability with show_in_rest set to false and public set to true stays out of REST. Registration with the new key:

wp_register_ability(
    'my-plugin/export-users',
    array(
        'label'               => __( 'Export users', 'my-plugin' ),
        'description'         => __( 'Exports user data as CSV.', 'my-plugin' ),
        'category'            => 'data-export',
        'execute_callback'    => 'my_plugin_export_users',
        'permission_callback' => function (): bool {
            return current_user_can( 'export' );
        },
        'meta'                => array(
            'public' => true,
        ),
    )
);

Read public as a declaration of intent, not as new machinery. It says an ability is meant to be reachable by external clients such as REST consumers, MCP adapters or AI agents. It does not mean core provides those adapters: 7.1 still ships no MCP server, no agent-specific OAuth scopes, no rate limits, no audit trail and no approval queue. Everything in the security section below remains project work.

#Filtering discovery with wp_get_abilities()

Before 7.1, a caller that needed a subset had to fetch every registered ability and sift the array by hand with array_filter(). wp_get_abilities() now accepts an optional $args array with category, namespace, meta, item_include_callback and result_callback. The note is explicit about how they combine: “Conditions are combined using AND logic. An ability must satisfy every supplied argument to be included.”

Two new filters, wp_get_abilities_item_include and wp_get_abilities_result, adjust the same query, and rest_abilities_collection_params extends the REST collection argument schema. None of this touches authorisation: narrowing a list decides what discovery returns, not who may run anything, and permission_callback still runs at execution time.

#Practical Use Cases

#Content Creation Workflows

The most immediate use case is intelligent content creation. Instead of an AI generating raw text that a human pastes into WordPress, the AI agent handles the entire workflow:

User: "Create a comprehensive guide about organic pest control for our gardening blog"

AI Agent Workflow:
1. invoke: research_topics → finds trending subtopics and competitor gaps
2. invoke: generate_content → creates 3000-word article with headings, images references
3. invoke: optimize_seo → adds meta description, focus keyword, internal links
4. invoke: generate_featured_image → creates AI-generated hero image
5. invoke: create_draft → saves as draft with all metadata
6. invoke: notify_editor → sends review notification to editorial team

Each ability is provided by a different plugin - the SEO ability by RankMath, the image generation by an AI media plugin, the notification by a workflow plugin. The AI agent orchestrates them through the unified Abilities API.

#WooCommerce Store Management

For e-commerce sites, AI agents can manage entire store operations:

• Inventory management: monitor stock levels, generate reorder suggestions, update quantities
• Pricing optimization: analyze competitor prices, suggest adjustments, apply bulk changes
• Product descriptions: generate and update descriptions based on product attributes and SEO goals
• Customer service: process refunds, update order status, generate shipping labels
• Sales analysis: generate reports, identify trends, suggest promotions

A store owner could say “Review products that haven’t sold in 90 days and suggest whether to discount, bundle, or discontinue them” - and the AI agent would use WooCommerce abilities to fetch sales data, analyze it, and present actionable recommendations.

#SEO Automation

SEO tasks that previously required manual work or separate tools become abilities that AI agents compose:

• analyze_page_seo - returns SEO score, missing meta tags, keyword density
• suggest_internal_links - finds related content for cross-linking
• check_broken_links - scans for 404s and suggests replacements
• generate_schema_markup - creates JSON-LD structured data
• optimize_images - compresses and adds alt text to images
• audit_content_freshness - flags outdated content for review

An AI agent can run a complete SEO audit by invoking these abilities in sequence, then generate a prioritized action plan or even execute the fixes directly.

#Implementing custom abilities in a plugin

#Basic ability registration

An ability needs a unique name, category, human-readable metadata, schemas, an execution callback and a permission callback. Register the category first.

add_action( 'wp_abilities_api_categories_init', function () {
    wp_register_ability_category(
        'site-information',
        array(
            'label'       => __( 'Site information', 'wppoland' ),
            'description' => __( 'Read-only information about this site.', 'wppoland' ),
        )
    );
} );

add_action( 'wp_abilities_api_init', function () {
    wp_register_ability(
        'wppoland/get-site-title',
        array(
            'label'               => __( 'Get site title', 'wppoland' ),
            'description'         => __( 'Returns the current WordPress site title.', 'wppoland' ),
            'category'            => 'site-information',
            'output_schema'       => array(
                'type'        => 'string',
                'description' => 'The site title.',
            ),
            'execute_callback'    => function () {
                return get_bloginfo( 'name' );
            },
            'permission_callback' => function () {
                return current_user_can( 'read' );
            },
            'meta'                => array(
                'show_in_rest' => true,
                'annotations'  => array(
                    'readonly' => true,
                ),
            ),
        )
    );
} );

This example exposes a small read-only operation. Production code should use a capability that matches the data returned, provide translatable labels and descriptions, and test both authorised and unauthorised users. If no external client needs it, omit show_in_rest and call the ability internally through wp_get_ability().

#Composition belongs to the caller

Core provides registration, discovery, validation and execution. It does not create a workflow planner from a custom depends_on field. If several operations must run in a fixed order, implement one server-side ability that owns the transaction or let a reviewed orchestration layer call separate abilities.

The server-side option is safer for coupled changes. A single callback can validate the complete input, stop on the first error and return one structured result. Client-side composition is useful for independent read operations, but the caller must handle partial failure and retries.

#Add operational controls explicitly

Do not rely on undocumented middleware hooks. Put domain validation in the execution callback or a service called by it. Apply rate limiting at the gateway, reverse proxy or application layer, and record only the audit fields the project is allowed to retain.

#Security considerations for external access

#Authentication and authorisation

The Abilities REST endpoints use WordPress REST authentication. Cookie authentication is available for same-origin requests, Application Passwords are documented for external access, and projects may add a custom authentication plugin.

Authentication answers who the caller is. The ability’s permission_callback answers whether that WordPress user may execute this operation. Keep both checks. A shared administrator credential defeats the purpose of a narrow ability contract.

REST visibility is another boundary. Registered abilities remain internal unless show_in_rest is true. Review that flag during code review and expose only operations required by the integration.

#Approval for risky changes

WordPress core does not provide a generic approval queue for abilities. Build one in the domain application if a refund, deletion or settings change needs human confirmation. A common pattern is to let the ability create a pending request and require an authorised user to approve it through a separate admin action.

Keep approval and execution separate. The approval record should identify the proposed change, the reviewer, the expiry time and the exact input digest. Reusing approval for modified input creates a gap that the workflow was meant to close.

#Audit trail

The API does not create a complete audit trail automatically. Decide what must be recorded for operations exposed to external systems:

• authenticated WordPress user or service account,
• ability name and request correlation ID,
• result category and duration,
• approval reference for sensitive changes,
• timestamp and relevant application version.

Avoid logging secrets, complete prompts or unnecessary personal data. Retention and access to logs need an owner, not just a database table.

#Input Sanitization

The Abilities API validates inputs against the declared JSON Schema before execution. Schema validation checks shape; it does not make a string safe for every destination. Apply WordPress sanitisation and escaping for the actual context, and use prepared database queries where required.

#Comparison with existing approaches

#REST API vs. Abilities API

#WPGraphQL vs. Abilities API

WPGraphQL excels at flexible data querying - letting clients ask for exactly the data they need in a single request. The Abilities API is not a replacement. Rather, abilities can use GraphQL internally for data fetching while exposing a higher-level interface for AI agents.

Think of it this way: GraphQL answers “what data do you have?” while the Abilities API answers “what can you do?”

#When to Use What

• REST API: Server-to-server integrations, mobile apps, traditional frontend consumption
• WPGraphQL: Complex data fetching, headless frontends, Jamstack architectures
• Abilities API: AI agent integration, automated workflows, capability discovery

#The Future of AI-Driven WordPress Workflows

#Multi-Agent Orchestration

As AI systems mature, we will see multiple specialized agents collaborating on WordPress tasks. A content agent handles writing, an SEO agent handles optimization, a design agent handles layout and images, and a QA agent handles review and testing. The Abilities API provides the shared infrastructure these agents use to coordinate.

#Marketplace Implications

The WordPress plugin ecosystem will evolve to include ability bundles - plugins that primarily exist to expose abilities for AI agents. Imagine a plugin that adds zero UI but registers 50 SEO abilities that AI agents can use. The value shifts from human-facing interfaces to machine-facing capabilities.

#WordPress as an AI Backend

With the Abilities API, WordPress becomes more than a content management system. It becomes an AI-orchestratable backend that can power intelligent applications. A WordPress multisite with WooCommerce, LMS, membership, and event plugins becomes a comprehensive business platform that AI agents can manage end-to-end.

#Integration with external AI services

The Abilities API does not include a generic invoke_external_ability() function. A plugin may call an external service with the WordPress HTTP API and wrap that operation in its own ability, but the plugin remains responsible for credentials, timeouts, retries, cost controls and response validation.

Keep the external call behind a narrow domain operation. An ability named media/create-approved-variant is easier to review than a generic prompt relay that accepts arbitrary instructions and writes the result directly into post metadata.

#Getting started

For WordPress 6.9 or newer:

1. Choose one operation. Start with a small read-only ability.
2. Register its category. Use wp_abilities_api_categories_init.
3. Register the ability. Use wp_register_ability() on wp_abilities_api_init.
4. Define schemas. Describe inputs and outputs with JSON Schema.
5. Check permissions. Test authorised and unauthorised WordPress users.
6. Keep REST private by default. Enable show_in_rest only for a real external consumer.
7. Add missing controls. Rate limits, audit records and approvals belong to the project architecture.

The practical benefit is a consistent contract between WordPress components and external automation. It is useful even without an AI agent: plugins can discover named operations, inspect schemas and call them through the same registry.

For implementation help, send the WordPress version, plugin list, intended operation, caller identity and required data access through the contact page.

Verified against the official WordPress Abilities API handbook and the WordPress 7.0 and 7.1 developer notes on 9 August 2026.