DJIA BuilderAI and MCP · 5 of 5

WordPress Abilities API (WordPress 6.9+)

On WordPress 6.9 and later DJIA Builder registers the same twelve operations as its MCP tools as WordPress abilities. The Abilities API, its REST routes, the WordPress MCP adapter and other plugins can then call them, with the same permission checks.

What this does

During WordPress's wp_abilities_api_categories_init and wp_abilities_api_init actions the plugin registers the category djia-builder ("DJIA Builder": "Read and change DJIA Builder pages, templates and components; publish with the right capability.") and one ability per operation, named djia-builder/…. Each ability carries its label, description, JSON input schema, an object as output schema and the annotations readonly, destructive and idempotent. All of them are marked show_in_rest and public for MCP (meta.mcp.public).

Executing an ability runs the same permission check and handler as the matching tool of the built-in MCP server, described in MCP tools, drafts and publishing permissions. Writes become draft revisions recorded with the client MCP. A failure comes back as a WP_Error with the HTTP status and, where useful, the index, path, conflicts or what the change needs.

Before you start

WordPress 6.9 or later, or the Abilities API plugin on an older version. Every call is guarded, so without the API nothing is registered and the built-in MCP server works as before.
Check the line WordPress Abilities API under Settings → API keys → MCP server: Registered ("The same tools are also available to the WordPress MCP adapter.") or Needs WordPress 6.9 ("The built-in server works without it.").
The caller signs in as a WordPress user with builder access; the permissions are that user's.

The registered abilities

Ability	Annotations	Permission
`djia-builder/get-design-context`	read-only	builder access
`djia-builder/get-selection`	read-only	builder access
`djia-builder/list-documents`	read-only	builder access; lists only documents the user may edit
`djia-builder/get-page`	read-only	builder access and edit_post on the document
`djia-builder/get-query-definition`	read-only	builder access and edit_post
`djia-builder/apply-change-set`	write	builder access and edit_post
`djia-builder/validate-and-preview`	read-only (dry run)	builder access and edit_post
`djia-builder/import-html`	write	builder access and edit_post
`djia-builder/create-page`	write	Full access and edit_pages
`djia-builder/update-seo`	write, idempotent	builder access and edit_post on the page
`djia-builder/publish-revision`	destructive	edit_post, publish_post, "Allow publishing over MCP" on; input `confirm: true`
`djia-builder/rollback-release`	destructive	publish_pages, "Allow publishing over MCP" on; input `confirm: true`

The inputs are the same as the MCP tools': for example document_id, base_revision and ops for apply-change-set. The input schema of each ability lists them.

How other tools call them

REST. WordPress lists and runs abilities through its own routes under /wp-json/wp-abilities/v1, signed in as a WordPress user, for example with an application password. The routes and their methods are WordPress's; DJIA Builder adds nothing to them.
The WordPress MCP adapter. It exposes abilities marked public for MCP and uses the same naming convention as the built-in server: djia-builder/get-page becomes the tool djia-builder-get-page.
Another plugin. Code running inside WordPress can execute an ability through the Abilities API functions. It runs as the current user, so in WP-CLI or a cron job set a user first; without one every DJIA Builder ability is refused.
Your own definitions. The filter djb_abilities receives the array of definitions; add your own or remove some. The built-in MCP server reads the same array.

Differences from the built-in MCP server

The abilities are registered whether the MCP server switch is on or off. Turning the switch off closes only /wp-json/djia-builder/v1/mcp.
The publish and rollback abilities are always registered. The built-in server hides them while publishing is off; through the Abilities API a call fails with djb_mcp_publish_disabled ("Publishing over MCP is turned off (DJIA Builder → Settings → API keys).") until you allow it.
The resources (selection, design context, documents) exist only on the built-in server.
The built-in server's Origin check and its no-store header belong to its endpoint; REST calls to the Abilities API follow WordPress's own handling.

Limits

The same limits as the MCP tools: at most 300 operations and 400 new elements per change set, confirmations for code and custom CSS, and confirm: true for publishing and rollback.
When another plugin has already registered an ability under one of these names, DJIA Builder skips it and keeps the other one.
Status of this integration: in testing, as listed on the integration status page.

If it doesn't work

The screen says Needs WordPress 6.9. Update WordPress, or install the Abilities API plugin on an older version.
"You do not have access to DJIA Builder." The calling user's role has No access under Settings → Builder access, or no user is signed in.
djb_mcp_publish_disabled. Switch on Allow publishing over MCP under Settings → API keys, if you want abilities to publish at all.
You want no external access at all. Keep the MCP server off and remove the abilities with a djb_abilities filter in a must-use plugin; that removes them from the built-in server too.

Last verified 2026-10-20 · tested with DJIA Builder 1.0.20.15
To confirm Verified against the plugin code; run the steps on a test site before launch