Skip to content
Writing
By MD Jehad H.··4 min read·Operator playbook

The abilities API lets AI run your WordPress

Drafted through my n8n + AI pipeline, edited by me.

WordPress 7.1 landed on August 19, timed to WordCamp US, and its biggest change is under the hood. The release expands an abilities API that lets AI agents run real tasks on your site: create a post, update stock, pull recent orders. For a small business, that means your website can take instructions from a tool, not only from a person clicking around the dashboard.

What the abilities API actually is

An ability is a registered function that WordPress describes in a typed, permission-gated, schema-validated way. Core ships several out of the box, including create_post, get_post, find_posts, and update_post. WooCommerce adds store actions like create_product, update_inventory, and get_orders. A companion piece called the MCP adapter exposes those abilities over the Model Context Protocol, so an AI client can discover them at runtime and call one with checked inputs.

The practical part is discovery. Instead of writing custom glue code for every action you want an agent to take, the agent asks your site what it can do, gets back a typed list, and calls the right ability. 7.1 hardened this with execution filters, custom validation, and a single public exposure flag that controls which abilities are visible to outside callers.

What this changes for a small business

  • Content updates by instruction. You tell an assistant to post the weekly update or fix a typo across three pages, and it calls the same abilities your editor uses.
  • Store operations without the admin screen. Inventory changes and order lookups become something an agent can do while you are on a job site.
  • Build once, use everywhere. The same registered ability answers your dashboard, the REST API, the block editor, and an AI client, so you are not maintaining four versions of one action.
  • You stay in control of scope. Every ability is permission-gated, so an agent only touches what the connected user is allowed to touch.

A flow showing an AI request moving through the MCP adapter to a WordPress ability and back to a saved draft.

  1. 01Trigger

    You ask an AI client

    post the weekly update

  2. 02Decision

    MCP adapter lists abilities

    create_post, find_posts, update_inventory

  3. 03Action

    Agent calls create_post

    schema-validated fields

  4. 04Action

    WordPress checks the capability

    permission-gated execution

  5. 05Record

    Saved as a draft

    logged for your review

One registered ability answers the dashboard, the REST API, and an AI client, so a single setup covers every caller.

What to set up before you turn it on

  1. 1

    Update on staging first

    Move to 7.1 on a copy of your site and confirm your theme, WooCommerce, and key plugins still behave. Do not update a live store blind.

  2. 2

    Decide which abilities are exposed

    Use the public exposure flag to show read abilities like find_posts and get_orders. Keep write actions off until you have watched the reads for a while.

  3. 3

    Gate permissions by role

    Agents act as a WordPress user. Create a dedicated account with least privilege and start it read-only, rather than pointing an agent at your admin login.

  4. 4

    Turn on an audit log

    Add a plugin that records every ability call, such as Agent Abilities for MCP, so you can see exactly what ran and roll back if needed.

Start read-only

The fastest way to a bad afternoon is handing an agent update_inventory and delete rights on day one. Expose read abilities first, watch the log for a week, then add write actions one at a time.

Do I need to be technical to use this?

Registering custom abilities is developer work. Using the core and WooCommerce abilities through an MCP client is mostly configuration: connect a client, pick a permission level, and choose what to expose.

Does this put my site on the public internet?

No. Abilities are only reachable by callers you authenticate and permit. The exposure flag and the capability check decide who can see an ability and who can run it.

If you run your business on WordPress and want a short list of which abilities to expose first and which to keep off, bring me your current setup and the handful of tasks you keep doing by hand. We can map them to abilities and a safe permission model, and leave the risky ones behind a human for now.

Building something this should run inside?

Book a systems call

Keep reading