From CRUD to Complete: How We Let an AI Agent Control WordPress

Four Operations, Then a Question

We started with four operations: create a blog post, read a blog post, update a blog post, delete a blog post. Standard CRUD that we'd built into Writer's AI agent to let it manage WordPress content through the Model Context Protocol. It worked. Users could ask the agent to draft posts, schedule them, update old ones. Clean, contained, useful.

Then someone on the team asked: what if we kept going?

The Stack

WordPress 6.9 shipped with the Abilities API—a formal way to register custom operations that external clients can discover and execute. We wrote an MCP adapter and packaged it as a must-use plugin. The adapter registers each WordPress operation as an MCP tool that the agent can call directly.

What Happened Next

We started with pages. Same pattern as posts: create, read, update, delete. Pages have different hierarchies and templates, but the underlying mechanics were familiar. The agent picked it up immediately. Users started asking it to build entire page structures—about pages, contact forms, service listings—and it would scaffold them out in minutes.

Then we added theme control. This was trickier. WordPress themes expose hundreds of options through the Customizer API—colors, fonts, layouts, custom CSS. We didn't want to build 200 individual operations, so we wrote a generic theme mutation operation that takes a JSON object and merges it with the current theme mod. The agent could now adjust typography, switch color schemes, modify spacing variables. One user asked it to "make the site feel more corporate," and it darkened the palette, increased font weights, and tightened line heights. We hadn't programmed that heuristic. It just inferred it from the request.

Media import came next. We built an operation to pull images from URLs—Unsplash, Pexels, whatever—and add them to the library. The agent started using images contextually. Ask it to write a post about remote work, and it would pull a relevant header image, import it, attach it as the featured image, all without prompting.

Global styles nearly broke everything. WordPress stores design tokens as JSON in the database—color palettes, font families, spacing scales. We wrote an operation to let the agent read and write the global styles object. First test: "lighten the color palette." The agent did, but when we opened the block editor, the color picker was corrupted. Every swatch showed the same gray. Took us an hour to find the bug: our PHP array merge was recursively flattening nested arrays, turning the color palette structure into a mess. The block editor expected a specific nested format, and our merge destroyed it. We switched to a proper JSON merge and rebuilt the operation.

Then came template editing. WordPress block themes store templates as HTML with block markup—headers, footers, single post layouts, archive pages. We exposed read/write operations for every template file. The agent could now redesign the entire template hierarchy. User asks: "make the blog archive more visual." The agent rewrites the archive template to use a three-column grid with larger featured images, adjusts the post meta display, tightens the excerpt length. It does this by reading the current template, parsing the block markup, injecting new block directives, and writing it back. No GUI, no drag-and-drop builder. Just structured HTML operations.

The Unexpected Part

We built 55 operations covering nearly every corner of the WordPress admin surface. What surprised us wasn't that the agent could call these operations—that was the whole point. What surprised us was how it chained them together into multi-step workflows without us teaching it how. Ask it to "launch a new blog section about case studies," and it creates a category, builds a custom archive template, writes three seed posts, imports featured images for each, adjusts the site navigation to include the new section, and updates the homepage to highlight the latest case study. That's seven operations across four different subsystems, sequenced correctly, with no explicit workflow definition. The protocol gives it building blocks. The reasoning model figures out the assembly.

We're still running with it. Users are building entire sites from a single conversation. No dashboard logins, no clicking through admin panels. Just: "build a portfolio site for a photographer with these galleries," and the agent scaffolds the structure, imports the images, designs the layouts, and ships it. The WordPress Abilities API made this possible. MCP made it composable. The agent made it real.