👁 3 views
Today marks a shift in our WordPress MCP development philosophy. We’ve moved past the “make it work” phase into “make it work better.” Breaking things along the way? That’s just part of the process.
The Simple Version
Our MCP (Model Context Protocol) system lets AI assistants manage WordPress sites through natural conversation. Instead of clicking through admin panels, you just say “list plugins” or “create a post about X” and it happens. Today’s work focused on making these conversations more efficient—using fewer resources while being smarter about what the AI needs to know and when.
The Technical Deep Dive
Ability Loading: On-Demand vs. Upfront
Our system exposes 120+ WordPress abilities—everything from listing posts to managing ACF field groups. The naive approach would dump all ability schemas into the AI’s context window at conversation start. That’s expensive (tokens cost money) and noisy (the AI has to parse through irrelevant options).
Instead, we use a three-tier discovery pattern:
- discover-abilities — Returns a lightweight list of all available abilities (just names and descriptions)
- get-ability-info — Fetches the full schema for a specific ability only when needed
- execute-ability — Runs the ability with parameters
This lazy-loading approach means the AI only pulls detailed schemas for abilities it actually intends to use. For a simple “list plugins” request, we load one schema instead of 120+.
Resources: Context Without Conversation
MCP Resources provide static or semi-static information the AI might need—site configuration, available post types, registered taxonomies. Rather than making the AI ask “what post types exist?” at the start of every content-related task, resources can pre-populate this context.
The token savings compound. If an AI session involves 10 content operations, that’s 10 avoided round-trips for the same information.
Prompts: Teaching the AI Your Patterns
MCP Prompts are reusable instruction templates. Instead of explaining “when creating a blog post, always set category to ‘Development’ and add the ‘technical’ tag” every time, you define it once as a prompt. The AI can invoke that prompt by name, inheriting all the embedded instructions.
This isn’t just about saving tokens—it’s about consistency. The prompt becomes a contract for how certain operations should behave.
Today’s Setback: delete-plugin
Not everything worked. Our delete-plugin ability is returning generic errors regardless of input. Activate and deactivate work fine with identical parameter formats. The issue is isolated to the delete handler—likely something in how we’re calling WordPress’s delete_plugins() function or handling its response.
This is the nature of the “make it work better” phase. You optimize, you refactor, and sometimes you break things that were working. The fix will come. The architecture is sound.
What’s Next
We’re continuing to refine parameter naming conventions (moving toward intuitive names like “plugin” instead of “plugin_file”), improving error messages to surface actionable details, and building out the resource and prompt libraries. The goal: an AI that can manage WordPress as fluently as an experienced developer, but accessible to anyone who can describe what they want.
P.S. Case in point: while writing this very post, the first create-post attempt failed. The AI used title instead of post_title. A quick schema lookup via get-ability-info revealed the correct parameter name, and the second attempt worked.
This is exactly why we’re investing in resources and prompts. If a “create-blog-post” prompt had been defined with the correct parameter mappings, or if a resource had pre-loaded the post schema, that failed attempt wouldn’t have happened. The three-tier discovery pattern saved us—we didn’t have to guess or reload everything—but a well-designed prompt would have eliminated the error entirely. The tooling works; now we make it seamless.
