Hook

By the end of this hour, you'll see a capability registered once in WordPress and called live by an AI.

Ask the room

Show of hands: who has wired an LLM to WordPress with custom REST glue?

Notes

Keep this short. Name yourself. Set the expectation that slides are visual anchors — you'll talk over them. Footer strip is intentional: Abilities shipped in 6.9, extended in 7.0, proposed expansion in 7.1.

Transition

Start with why LLMs feel brilliant and useless on a live site.

Talking points

LLMs hallucinate today's stock price; they can write a plan to update your site but can't click the button.

Misconception to kill

A bigger model doesn't fix this — it's an access problem, not an IQ problem.

Punchline

"Intelligence without access is a very expensive encyclopedia."

Transition

"So we bolt on integrations… and it gets ugly."

Talking points

Every model↔tool pair = bespoke connector. WordPress updates its API → rewrite in 3 places. Fragile glue code, permanent maintenance debt.

Transition

"What if each side implemented ONE standard and N×M collapsed to N+M?"

Talking points

USB-C didn't change what devices do — it standardized the connection.

Fact-check moment

MCP did NOT work with ChatGPT on day one; OpenAI joined 4 months later.

Ask

"How many cables did USB-C kill in your bag?"

Talking points

One client per server (1:1). The LLM never touches your DB — the server is the security boundary.

Misconception

"Everything is a tool" — resources are context to READ, tools are actions to DO, prompts are user-invoked slash-command templates.

Talking points

Two layers: data layer = JSON-RPC 2.0; transport = stdio (local) or Streamable HTTP (remote).

Debug tip

Most MCP bugs are protocolVersion mismatches — use npx @modelcontextprotocol/inspector to watch raw JSON-RPC.

Transition

"So what does this look like ON WordPress?"

Talking points

Endpoints /wp/v2/wpmcp (stdio proxy) and /wp/v2/wpmcp/streamable. Granular CRUD toggles in admin.

Real workflow it enabled

"Draft this year's sales report from my WooCommerce orders" — AI reads orders under WordPress permissions.

Arc

It proved the demand… and exposed the cracks.

Transition

"Here's where it hurt."

Talking points

Apideck production data: GitHub+Slack+Sentry ≈ 143k of 200k tokens burned on tool definitions before the user says a word. Clients are mitigating (Cursor caps at 40 tools; Anthropic's tool-search cuts ~85%).

WordPress-specific problem

No shared way for plugins to declare "here's what I can do." Everyone reinvented "get a post."

Transition

"The protocol wasn't the problem. WordPress was missing a layer BELOW the protocol."

Talking points

MCP answers "HOW does an AI talk to a system?" It never answers "WHAT can this WordPress site do?" That's the Abilities API.

Punchline

Register once → reachable from PHP, REST, JS, WP-CLI, and any MCP client. If MCP is ever replaced, you swap the adapter — your business logic survives.

Transition

"Let's meet the star of the talk."

Pause here

"Who thought this was a 7.0 feature? It's 6.9 — you may already have it in production."

Details

Registry = WP_Abilities_Registry singleton; each ability = WP_Ability; each belongs to one category.

Ask

How many are on 6.9+ already?

Critical

Never claim Abilities is "a 7.0 feature." 7.0 added the client-side JS API, Abilities Explorer, and WP AI Client.

Talking points

Name = namespace/ability-name. The description is NOT cosmetic — it's the AI's tool-selection signal; write it like docs.

Gotcha

The destructive annotation defaults to TRUE — set it explicitly.

Schema

Schema validation = JSON Schema Draft-4 subset.

#1 mistake in the wild

Registering on the wrong hook → _doing_it_wrong() + silent failure. Categories hook fires FIRST; hook name is wp_abilities_api_init (with the wp_ prefix — old blog posts got this wrong).

REST verb

Picked from annotations: readonly→GET, default→POST, destructive→DELETE.

Order

Input validation runs BEFORE the permission check.

Audit hooks

wp_before_execute_ability / wp_after_execute_ability.

Talking points

The adapter ships helper tools (discover-abilities, get-ability-info, execute-ability) so agents pull schemas on demand instead of ingesting everything — this is the direct answer to slide 8's tool bloat.

Extensibility

Custom servers via mcp_adapter_init + create_server().

Design intent

Protocol dies → swap adapter, keep abilities.

Rules

Never __return_true on destructive abilities.

Myths to correct

1. "Human-in-the-loop" is client-UI dependent — the protocol encourages approval prompts, doesn't enforce them.
2. "Keys stay local" is only true for local STDIO — remote HTTP puts the credential at the proxy.

Mindset

MCP clients act as logged-in WP users: treat them as attack surface.

7.1 proposal

core/read-settings / read-content / read-users behind a show_in_abilities flag — drew maintainer pushback; state it as "proposed, contested" not "shipping."

Advice to the room

Build on Abilities, not directly on any MCP plugin — that's the durable layer.

Demo cue

Keep this slide up the whole demo. Fallback: pre-recorded video if Wi-Fi dies.

Prep before the talk

Pre-generate the application password + client config.

Steps

1. Clean local WP 7.0 → activate site-stats-ability plugin
2. Discover: curl /wp-json/wp-abilities/v1/abilities
3. Run: GET …/site-stats/get-post-count/run
4. Claude Desktop → asks "how many pages?" → calls the ability
5. Edit the ability live → AI sees the new schema instantly

Close

Thank the audience. Open the floor for questions.