WordPress MCP
We Built a WordPress Plugin That Lets AI Edit Your Site (And It’s Open Source)
MCP Expose Abilities lets AI assistants call approved WordPress operations through named abilities, so site owners can expose useful actions without opening a vague admin doorway.
AI is more useful when it can perform approved WordPress actions, not just suggest them.
We built a Devenia WordPress plugin layer that exposes concrete WordPress operations as named abilities an AI assistant can call through the MCP/Abilities stack.
The point is not to give an assistant a vague admin doorway. The point is to expose specific operations, keep permissions visible, and let a site decide which abilities are safe and useful.
The setup question
- Which WordPress operations should the assistant be allowed to use?
- Which public dependencies provide the MCP/Abilities connection?
- Which Devenia ability plugins match this site?
The stack has three different jobs
A safer setup is easier to reason about when the protocol layer, the WordPress ability framework, and the Devenia ability plugin are kept distinct.
Abilities framework
The WordPress Abilities API provides the framework for registering site actions as explicit abilities.
MCP connection
The MCP adapter layer lets compatible AI tools talk to those registered abilities. It is part of the surrounding setup, not a Devenia-owned add-on.
Devenia abilities
The Devenia plugin and add-ons define the WordPress operations we want to expose: content, media, menus, builders, SEO, security, and other focused surfaces.
Useful automation still needs boundaries
Letting an assistant change a WordPress site is powerful. That makes authentication, permission checks, and narrow ability selection more important, not less.
The goal is controlled execution: named operations, visible permissions, and a site owner who can decide what belongs in the assistant surface.
What should stay explicit
- Which user account authenticates the assistant.
- Which WordPress capability each ability requires.
- Which plugin or add-on provides the operation.
- Which operations are read-only and which can change the site.
- Which abilities should not be installed on this site at all.
What this makes possible
The useful part is removing the gap between a good AI suggestion and the WordPress work needed to apply it.
- Content work: Create, inspect, update, and patch posts or pages through named operations instead of copy-pasting by hand.
- Media and metadata: Inspect media, update alt text, and keep image metadata tied to the actual WordPress library.
- Builder-aware work: Use focused add-ons for Elementor, GeneratePress, GenerateBlocks, and other site-specific surfaces when the site actually uses them.
- Permission checks: Every useful write operation still needs the right WordPress permission instead of bypassing the admin model.
- Focused add-ons: A site should install only the ability plugins that match its stack, not every possible operation.
Good AI operations are specific enough to inspect and narrow enough to trust.
Why this matters in real maintenance work
Small WordPress fixes often take longer than the judgment behind them. The assistant can help when the safe operation is clear and repeatable.
High-friction manual work
- Opening many posts to apply the same small content or link correction.
- Moving between admin screens just to inspect current state.
- Repeating a safe metadata or media update across similar pages.
Better assistant work
- Ask for the exact inspected state before changing anything.
- Use a named ability with a clear permission boundary.
- Verify the result through WordPress and the public page when the change is visible.
A safer first path
Start with the smallest useful surface, then add abilities only when the site has a real job for them.
- Install the required public Abilities API and MCP connection layer.
- Install the Devenia core ability plugin for WordPress-native operations.
- Add only the Devenia add-ons that match the site’s builders, SEO tools, forms, security, or workflow.
- Test read operations before allowing writes.
- Review every write-capable ability as part of the site’s operational surface.
- Use the current Devenia plugin page and GitHub release as the active reference.
The right setup should make useful work faster without making authority harder to understand.
Frequently asked questions
Is MCP Adapter a Devenia plugin?
No. Treat the adapter as part of the public MCP/WordPress connection layer. The Devenia plugin layer provides specific WordPress abilities and add-ons.
Should every site install every ability add-on?
No. Install only the abilities that match the site’s actual stack and operational needs.
What is the safest way to start?
Start with read operations, verify that permissions behave as expected, and only then allow write operations that the site genuinely needs.
The useful future is not AI advice. It is controlled AI action.
WordPress work becomes faster when the assistant can inspect, apply, and verify specific operations inside clear boundaries.
- Keep dependency roles clear.
- Expose only the abilities the site needs.
- Start with low-risk reads.
- Verify visible writes on the actual page.
Which WordPress operation would you expose first, and which would you keep out of reach?