Build a Conversational WordPress Admin Assistant With MCP

A single ability, “create a draft post,” is a tool. A handful of related abilities, combined with a clear sense of what the assistant is for and how it should behave, is something a site owner would actually want to use every day. This lesson is about that jump: going from individual tool calls to a coherent assistant persona someone can hold a real conversation with.

What you'll learn in this lesson

Why "an assistant" is a set of abilities plus a role

There's no separate assistant object in MCP, the persona lives in how you describe and group tools.

Picking a coherent ability set

Grouping abilities around one admin job instead of exposing everything at once.

Writing descriptions that shape behavior

How ability descriptions steer which tool the model reaches for for a given request.

Giving the client a system prompt to match

Where persona and boundaries actually live, on the client side, not the server.

Testing a multi-turn conversation

Confirming the assistant handles a realistic back-and-forth, not just one isolated command.

Prerequisites

A working connection to your MCP server from one of the previous three lessons (Claude Desktop or Cursor are the more reliable choices given Lesson 3’s findings), and at least two or three registered abilities from Course 2 covering related admin tasks, for example listing posts, creating a draft, and updating post status.

Step 1: pick one admin job, not “everything”

The biggest mistake at this stage is registering every ability you can think of and hoping a good system prompt sorts it out. Instead, pick one real job a site owner does repeatedly and build the assistant around exactly that. A content triage assistant, for instance, needs abilities to list recent drafts, read a single post’s content, and update its status, nothing about users, plugins, or settings belongs in that same conversation.

Scoping a first assistant

Name the job in one sentence

"Helps me manage the draft queue" is specific enough to scope abilities against, "helps with WordPress" is not.

List the abilities that job actually needs

Usually three to six, covering read and a narrow set of writes.

Everything else on your site stays invisible to this connection, exactly as covered in Course 1.

Confirm the permission_callback matches the job

An assistant scoped to draft triage shouldn't be running under a user who can also manage plugins.

Step 2: descriptions are the only steering wheel you have

The model picks a tool based on its label and description, nothing else, this was covered in Course 1’s lesson on the discovery lifecycle. For a coherent assistant, write descriptions as if they’re instructions to a new hire, not internal documentation.

// File: inc/abilities/content-triage.php
wp_register_ability( 'my-plugin/list-recent-drafts', array(
    'label'       => 'List recent draft posts',
    'description' => 'Returns the 10 most recently modified draft posts, with title, '
        . 'author, and last-modified date. Use this when the user asks what\'s '
        . 'waiting for review, what needs to be published, or wants an overview '
        . 'of the draft queue. Does not return published or trashed posts.',
    'input_schema'  => array( 'type' => 'object', 'properties' => new stdClass() ),
    'output_schema' => array(
        'type'  => 'array',
        'items' => array(
            'type'       => 'object',
            'properties' => array(
                'id'       => array( 'type' => 'integer' ),
                'title'    => array( 'type' => 'string' ),
                'author'   => array( 'type' => 'string' ),
                'modified' => array( 'type' => 'string' ),
            ),
        ),
    ),
    'execute_callback'   => 'my_plugin_list_recent_drafts',
    'permission_callback' => 'my_plugin_can_edit_posts',
    'meta' => array( 'mcp' => array( 'public' => true ) ),
) );

Notice the description does two jobs at once: it says what the tool returns, and it says when to use it versus not use it (“Does not return published or trashed posts”). That second half is what stops the model from calling this tool for the wrong request.

Step 3: shape the persona on the client side

MCP itself has no concept of “assistant persona,” that lives entirely in the client, usually as a system prompt or custom instructions you set once. This is where you turn a pile of tools into something that feels like a single coherent helper.

// Context: Claude Desktop project instructions, or a Cursor custom mode prompt
You are a WordPress content triage assistant for [site name]. You help review and
manage the draft post queue using the tools available on the connected WordPress
MCP server. When asked about "the queue" or "what needs review," use the recent
drafts tool. Always confirm a post's title back to the user before changing its
status. If a request falls outside draft/post management, say so plainly instead
of guessing at an unrelated tool.

That last sentence matters more than it looks: without it, a model faced with an ambiguous request sometimes reaches for the nearest tool that seems even loosely related. Telling it explicitly to decline out-of-scope requests keeps the assistant predictable.

Step 4: test a real multi-turn conversation

A single command proves a tool call works. A short conversation proves you’ve built an assistant.

You: "What's in the draft queue right now?"
Assistant: [lists 4 drafts with titles and authors]
You: "Open the one about the summer sale."
Assistant: [reads that post's content back to you]
You: "That looks ready, mark it as pending review."
Assistant: [confirms the title, then updates its status]

Signs the assistant is working, not just the tools

It resolves "the one about the summer sale" correctly

Meaning it connects your earlier list output to a specific post ID without you repeating it.

It stays inside the job you scoped it for

Asking it to change a user's role should get a decline, not an attempt.

It confirms before changing state

Even without an explicit confirmation-gate ability, a well-instructed client should recap before acting, Lesson 6 makes this a server-side guarantee instead of a client habit.

Treating a broad ability set as more helpful

It’s tempting to register ten abilities so the assistant can do “anything.” In practice, this makes tool selection worse: the model has more similar-looking options to choose between, and descriptions blur together. A tightly scoped set of abilities around one real job produces a more reliable assistant than a broad one.

Recap

A conversational WordPress assistant isn’t a special MCP feature, it’s a small, coherent set of abilities scoped to one real admin job, described precisely enough that a model reaches for the right one, paired with client-side instructions that define its persona and its boundaries. Test it with a multi-turn conversation, not a single command, since that’s what reveals whether it actually behaves like an assistant.

Resources & further reading

Abilities API reference, developer.wordpress.org
MCP Adapter repository, GitHub
Model Context Protocol specification, modelcontextprotocol.io