The Abilities API is WordPress-specific. The Model Context Protocol is not, it’s an open standard that Claude, Cursor, ChatGPT, and other AI clients already understand. This lesson covers MCP on its own terms, so when the MCP Adapter maps your abilities onto it in Course 2, none of the vocabulary is new.
The previous lesson, understanding abilities. No new tools to install for this one, it’s conceptual.
Step 1: The three primitives
MCP defines exactly three kinds of things a server can offer a client:
| Primitive | What it’s for |
|---|---|
| Tools | Functions the AI model can call to take an action or fetch computed data. This is what a WordPress ability becomes. |
| Resources | Context or data meant to be read, by the user or the model, rather than executed. |
| Prompts | Reusable, templated messages or workflows a user can trigger. |
Most of what you build in this track will be tools, an ability with an
execute_callback maps naturally onto an MCP tool. Resources and prompts exist in the
spec and the MCP Adapter can expose them, but they’re a smaller part of typical
WordPress use cases.
Step 2: Tool annotations, hints, not guarantees
Every MCP tool can carry annotations describing its behavior:
The MCP specification is explicit that these are hints for the client’s UI and
decision-making, not a security boundary. A client is not required to block a
destructive action just because destructiveHint is missing. Your
permission_callback in WordPress is still the actual enforcement point, annotations
only affect how a client presents or confirms the action.
Step 3: How WordPress abilities map onto MCP
This is the piece the MCP Adapter (Course 2) handles for you automatically, but knowing the mapping now makes that code much less mysterious later:
| Ability field | Becomes |
|---|---|
label | Tool title |
description | Tool description |
input_schema / output_schema | Tool input/output JSON Schema |
meta.annotations.readonly | readOnlyHint |
meta.annotations.destructive | destructiveHint |
meta.annotations.idempotent | idempotentHint |
Step 4: Transports and the connection lifecycle
MCP defines two transports: stdio (the server runs as a local process, communicating over standard input/output, this is how WP-CLI-based serving works) and Streamable HTTP (the server exposes an HTTP endpoint, this is how a remote AI client like Claude Desktop’s connectors typically reach a website).
Every MCP session, regardless of transport, follows the same lifecycle: the client
sends an initialize request declaring its capabilities and protocol version, the
server responds with its own capabilities, the client confirms with a
notifications/initialized message, and only then does normal operation, listing and
calling tools, begin.
Test it: read a real tool listing
If you have any existing MCP server available (even a non-WordPress example), most MCP client apps have a way to inspect the raw tool list they’ve discovered, in Claude Desktop this is usually visible from the connector’s settings screen. Open it and find one tool’s annotations, you should now be able to read exactly what each one is telling the client, without needing documentation open.
This lesson is intentionally read-only, you’re not running an MCP server yet. Course 2 has you build one and inspect its actual tool listing from a client.
Recap
MCP defines three primitives, tools, resources, and prompts, with tools being the one
WordPress abilities map onto most directly. Annotations are hints for client behavior,
not a substitute for your permission_callback. Two transports, stdio and Streamable
HTTP, and every session starts with the same initialize/initialized handshake regardless
of which one you use.
Resources & further reading
- Model Context Protocol specification, modelcontextprotocol.io
- MCP tools specification, modelcontextprotocol.io
- MCP transports specification, modelcontextprotocol.io