WordPress MCP and the Abilities API Explained

Last updated: October 8, 2026 · Skill level: intermediate developer.

The WordPress Abilities API describes what a site can do; the WordPress MCP Adapter makes selected abilities usable by AI clients. An ability is a named PHP operation with documented inputs, outputs and a permission check. MCP is the transport-facing layer that lets an agent discover and call those operations as tools or read them as resources.

This separation matters. MCP does not automatically expose the whole database or turn a language model into an administrator. A WordPress plugin registers each allowed operation, WordPress authenticates the request, and the ability’s permission callback decides whether the current user may execute it.

WordPress MCP and the Abilities API at a glance

Layer	Job	Typical example
WordPress function or service	Performs the actual site work	Read site health or update a draft
Ability	Names, documents, validates and authorizes that work	`acme/get-site-health`
Abilities REST API	Exposes opted-in abilities over authenticated HTTP	`/wp-json/wp-abilities/v1`
MCP Adapter	Maps abilities to MCP tools or resources	An AI client discovers a callable tool
AI client	Chooses a tool, supplies arguments and uses the result	Create a draft after the user asks

What is the WordPress Abilities API?

The Abilities API arrived in WordPress 6.9 as a standard registry for discrete units of functionality. Each ability uses a namespace and name such as my-plugin/get-report. It includes a human-readable label and description, a category, JSON Schema for inputs and outputs, an execution callback and a permission callback.

Before this API, plugins could expose REST routes, WP-CLI commands, AJAX handlers or custom hooks independently. Those approaches remain useful, but an outside system had no single way to ask, “What can this site do?” The registry provides that discovery layer and a common contract that WordPress, plugins, automation systems and AI agents can understand.

Discoverability: software can list registered abilities instead of relying on undocumented routes.
Validation: JSON Schema rejects missing or malformed arguments before business logic runs.
Permissions: each operation checks the authenticated user’s authority.
Interoperability: unrelated plugins can inspect and compose documented functionality.
Documentation: labels, descriptions and schemas travel with the operation.

What is the WordPress MCP Adapter?

The official MCP Adapter is a bridge between registered WordPress abilities and the Model Context Protocol. The adapter converts suitable abilities into MCP primitives. Executable operations usually become tools. Read-only context can be represented as resources, while reusable workflow instructions may be exposed as prompts when an implementation supports them.

The adapter’s default server includes a layered discovery workflow: discover abilities, inspect an ability’s full schema, then execute it. That pattern lets a client keep its initial tool list small while still reaching a larger WordPress capability catalog.

How a request travels from an AI client to WordPress

A user asks an AI client to perform a WordPress task.
The client connects to an authenticated WordPress MCP endpoint.
The client discovers an appropriate tool and reads its schema.
It sends structured arguments that match the input schema.
WordPress authenticates the request and runs the ability’s permission callback.
The ability validates input, executes its callback and validates the returned output.
The client receives structured data and reports the result to the user.

Authentication answers who is calling. Authorization answers whether that caller may run this specific ability. Input validation answers whether the supplied data has the expected shape. All three controls are required; none should be delegated to the model.

A minimal ability example

A plugin registers abilities on wp_abilities_api_init. The following shape illustrates a read-only operation; production code should use translatable labels and return stable, documented data.

wp_register_ability( 'wppres/get-site-summary', [ 'label' => 'Get site summary', 'description' => 'Returns public site details.', 'category' => 'site-information', 'output_schema' => [ 'type' => 'object' ], 'execute_callback' => 'wppres_get_site_summary', 'permission_callback' => function () { return current_user_can( 'manage_options' ); }, 'meta' => [ 'show_in_rest' => true ] ] );

The official REST documentation states that abilities are hidden from REST by default. Setting show_in_rest to true is an explicit exposure decision. External access still requires an authenticated WordPress user, and the permission callback still applies.

What MCP does not mean

It does not give a model unrestricted database access unless a developer deliberately writes such a tool.
It does not bypass WordPress roles, capabilities or the ability permission callback.
It does not make generated content accurate, accessible or safe without review.
It does not require every ability to be destructive; read-only tools are a sensible starting point.
It does not replace backups, staging, logs or release approval.

Security checklist for a WordPress MCP server

Create a dedicated WordPress user with the smallest role and capabilities the workflow needs.
Use HTTPS and an authentication method supported by WordPress; application passwords are designed for external API access.
Expose only narrowly scoped abilities with explicit input and output schemas.
Mark read-only, destructive and idempotent behavior accurately in ability metadata.
Reject arbitrary PHP, SQL, filesystem paths and unrestricted URLs unless the use case truly requires them and additional controls exist.
Log the user, ability name, timestamp, arguments after secret redaction, result and error state.
Require a draft or approval step before public publishing, deletion, deployment or account changes.
Rotate credentials and revoke the integration when it is no longer used.

How developers should design good abilities

Prefer a small business action over a general-purpose escape hatch. shop/create-refund-request can validate an order, amount and reason; system/run-any-php cannot be safely reasoned about. Keep inputs compact, make names unambiguous and return identifiers that another ability can use.

Idempotency deserves special attention. A read operation can be repeated safely. A draft update can often accept a stable post ID. A payment or email operation may create duplicate effects when a client retries after a timeout. Design a request key or a “check then act” workflow for those operations.

Where WordPress MCP is useful today

Workflow	Useful ability boundary	Human control
Editorial	Create or update a draft from an approved brief	Editor reviews and publishes
Site operations	Read versions, health checks and failed jobs	Administrator decides remediation
Commerce support	Look up an order with a supplied identifier	Support agent approves any change
Agency reporting	Collect plugin, content and performance summaries	Account owner checks client-facing report
Development	Inspect configuration or run a bounded staging task	Developer reviews logs and code diff

WPPRES already covers the broader operational pattern in How WordPress Agencies Use AI. The key is to give an agent documented context and limited tools, then keep a person responsible for publication and production changes.

A safer first WordPress MCP workflow

Start with a read-only diagnostic instead of content publishing. Register abilities that return the WordPress version, PHP version, active theme, selected plugin versions and Site Health status. Give the connected user only the capability required to read those fields. The client can summarize the result, but a person chooses whether to update software.

Next, add one reversible write such as creating a draft with a required title and content schema. Return the new post ID, status and edit URL. Test invalid input, insufficient permissions, retry behavior and audit logging. Only after that workflow is dependable should a team consider scheduling, publishing or operational changes.

Version and dependency planning

The Abilities API is a Core API from WordPress 6.9 onward, while the MCP Adapter is distributed separately. A plugin that bundles shared AI building-block packages should follow the official dependency guidance so two plugins do not load incompatible copies. Declare the minimum WordPress and PHP versions, test activation with another adapter-dependent plugin and fail with an administrator notice instead of a fatal error.

How to evaluate an MCP plugin or service

Can you list every ability it exposes and see the full schemas?
Does each destructive ability have an understandable permission check?
Can you restrict the connected user and revoke its application password?
Are credentials passed as environment variables or a secure secret store?
Does it produce an audit trail without storing passwords or tokens?
Can content stop at draft status?
Does the vendor explain data retention, subprocesses and model-provider transfer?
Can you test the same workflow on staging before production?

Frequently asked questions

Is the Abilities API the same as MCP?

No. The Abilities API is the WordPress registry and execution contract. MCP is a protocol used by external clients. The MCP Adapter connects the two.

Which WordPress version includes the Abilities API?

The official developer documentation says the Abilities API was added in WordPress 6.9. Plugins supporting older versions should check that the relevant classes and functions exist before registering abilities.

Can an MCP client publish posts automatically?

Only if the server exposes an ability that can publish and the authenticated user passes its permission check. A safer editorial design creates drafts and reserves publishing for an explicit approval step.

Are WordPress application passwords the same as the normal login password?

No. An application password is a separate revocable credential for API authentication. Give it a descriptive name, transmit it only over HTTPS and revoke it when the integration ends.

Sources and further reading

Primary references: the official Abilities API handbook, Abilities REST endpoints, WordPress MCP Adapter introduction and the @wordpress/abilities package reference. For release context, see what changed in WordPress 7.0.