AI plugin 1.5.0 adds MCP Access and WebMCP experiments
The official AI plugin's new MCP Access experiment installs and activates the MCP Adapter plugin from WordPress.org and adds a Tools → MCP Access screen to choose which abilities agents can use. A WebMCP experiment lets an agent browser edit in the block editor through document.modelContext. It also adds Mistral and Vercel AI Gateway as featured connectors (wpai_featured_connectors filter) and ai/v1 REST routes to list and run abilities.
To give agents MCP access on a site, enable MCP Access in the AI plugin instead of bundling the adapter yourself.
AI plugin 1.5.0 breaking changes to core abilities
The AI plugin removes the core/read-settings, core/read-users and core/read-content aliases, reshapes inputs to where / fields / pagination, and core/settings-get now uses REST names (title, not blogname).
Update any agent prompt or code that calls the old core/read-* abilities or the old input shape.
MCP stays a plugin in 7.2; MCP in core proposed for 7.3
The 7.2 roadmap requires AI features to prove adoption in the AI plugin first, so MCP, WebMCP, embeddings and streaming are developed there with no 7.2 guarantee. 7.2 does add three read-only core abilities (core/content-query, core/users-query, core/settings-get). The AI team aims to propose MCP for core in 7.3, merged or bundled.
Don't assume core includes an MCP server before 7.3: use the MCP Adapter plugin (or the AI plugin's MCP Access).
wp_get_abilities() now filters by category, namespace and meta
wp_get_abilities( $args ) accepts category, namespace, meta (strict, nested), item_include_callback and result_callback, combined with AND logic. New filters wp_get_abilities_item_include and wp_get_abilities_result apply site-wide. The REST list endpoint filters by category, namespace and meta (see rest_abilities_collection_params).
Use wp_get_abilities( array( 'namespace' => 'my-plugin' ) ) instead of filtering the full registry by hand; filtering is not authorization.
Abilities can set meta.public => true to signal they are meant for external clients (REST, MCP, agents). REST exposure resolves as show_in_rest ?? public ?? false, so a channel-specific flag still wins. Exposure is not authorization: permission_callback still applies.
Use 'meta' => array( 'public' => true ) instead of setting show_in_rest and MCP flags separately.
New filters wp_ability_validate_input and wp_ability_validate_output supplement JSON Schema validation, and the wp_ability_invoked action fires on every call. REST-style validate_callback/sanitize_callback schema keywords are not run by abilities. REST GET/DELETE run input is now coerced to schema types.
Put custom ability validation in wp_ability_validate_input, not in schema callbacks, and expect typed values in callbacks on 7.1+.
wp_prepare_json_schema_for_client() for MCP and AI tool schemas
New wp_prepare_json_schema_for_client( $schema, $profile = 'draft-04' ) converts WordPress-style schemas to portable Draft 4 (moves property-level required into a required array, strips server-only keywords). Core applies it automatically to ability schemas in REST and AI Client function declarations.
Call it on a copy of your schema when exposing it in a custom REST endpoint, JS config, MCP tool or AI function declaration.
WP_Ability::execute() now runs wp_pre_execute_ability (short-circuit), wp_ability_normalize_input, wp_ability_permission_result and wp_ability_execute_result, around the existing wp_before_execute_ability and wp_after_execute_ability actions.
Use wp_pre_execute_ability for caching, rate limiting or maintenance mode, and wp_ability_permission_result for extra authorization.
WordPress 7.0 ships a provider-agnostic AI Client. wp_ai_client_prompt( 'text' ) returns a WP_AI_Client_Prompt_Builder with methods like using_system_instruction(), using_temperature(), using_model_preference(), as_json_response( $schema ), then generate_text(), generate_image() or generate_text_result(). Failures return WP_Error. Core bundles no providers: official Anthropic, Google and OpenAI provider plugins add them.
Check is_supported_for_text_generation() before showing AI UI, and handle WP_Error; never assume a provider is configured.
Migrating from php-ai-client and wp-ai-client packages
On 7.0+, core loads wordpress/php-ai-client, so loading it again via Composer causes duplicate class conflicts. AI_Client::prompt() is replaced by wp_ai_client_prompt(). The wp_ai_client_prevent_prompt filter can block prompts. The client-side JS prompt API is not in core and needs an admin-level capability.
Require WP 7.0 and drop the Composer dependency, or only load your Composer autoloader when wp_get_wp_version() is below 7.0.
7.0 adds a JavaScript Abilities API in two script modules: @wordpress/abilities (store, registerAbility, registerAbilityCategory, getAbilities, executeAbility) and @wordpress/core-abilities, which loads server abilities from /wp-abilities/v1/.
Call wp_enqueue_script_module( '@wordpress/core-abilities' ) and import from @wordpress/abilities dynamically.
Connectors API and the Settings → Connectors screen
7.0 adds a registry for external service connections, starting with AI providers (Anthropic, Google and OpenAI are featured connectors; the providers themselves are separate plugins). Query it with wp_is_connector_registered(), wp_get_connector() and wp_get_connectors(), and modify it on wp_connectors_init. API keys come from an env var, then a PHP constant (e.g. ANTHROPIC_API_KEY), then the database (stored unencrypted, masked in UI).
Don't build your own AI key settings page: AI provider plugins registered with the AI Client get a connector automatically.
Since 6.9, register abilities with wp_register_ability( 'namespace/name', $args ) on the wp_abilities_api_init action (with label, description, category, input_schema, output_schema, execute_callback, permission_callback). Categories must be registered first with wp_register_ability_category() on wp_abilities_api_categories_init. Run one with wp_get_ability( $name )->execute( $input ).
Register abilities only inside wp_abilities_api_init (elsewhere it fails with _doing_it_wrong()). REST (/wp-json/wp-abilities/v1/) only lists abilities with meta.show_in_rest => true (on 7.1+, meta.public also works).
