MCP plugins
How We Made Our MCP Plugin Ecosystem Easier to Use
A practical update on the Devenia MCP plugin ecosystem: clearer setup, current add-on information, and a safer path for controlled WordPress automation.
A useful plugin ecosystem still needs a clear starting point.
MCP makes WordPress automation more useful, but the ecosystem has grown large enough that new users need a simpler path into it.
One plugin is easy to explain. A core plugin, an adapter, add-ons, GitHub releases, WordPress pages, and setup steps in the right order can quickly feel like a puzzle. That is the friction we have been removing.
The onboarding question
- What should be installed first?
- Which add-ons are optional for this site?
- Which abilities can an assistant use safely and clearly?
What had to become easier to scan
The goal is simple: make it obvious what each piece does and how to expose useful WordPress abilities without creating a vague, uncontrolled admin surface.
Starting point
The core plugin page needs to explain the first useful path, not leave users piecing together setup order from scattered release notes.
Add-on roles
Each add-on should make its WordPress job clear so a site installs only the abilities that match its stack.
Controlled abilities
Every exposed operation should be named, inspectable, and tied to the right WordPress permission instead of being one broad admin doorway.
The problem was the path around the plugins
The plugins were doing useful work. The weak point was the route around them: setup order, current release information, and a clear explanation of what belongs in core versus an add-on.
Those are not small questions for someone trying MCP on a real WordPress site. If the setup path is unclear, the useful part starts too late.
Questions the ecosystem now has to answer quickly
- Which plugin should be installed first?
- Which add-ons are optional?
- Which page has the current release information?
- What does the core plugin handle, and what belongs in an add-on?
- How does a user see that the ecosystem is still maintained?
What changed
The cleanup was not cosmetic. It changes whether the project feels approachable or like a pile of powerful tools with no obvious entry point.
- Plugin pages: The Devenia plugin pages now explain the core plugin and add-ons as one consistent ecosystem.
- Current references: Stale counts, release references, and links were updated so older pages do not sound newer than the main plugin page.
- Core overview: The MCP Expose Abilities page was rebuilt in maintainable Gutenberg content.
- Install path: The setup path is clearer: Abilities API and adapter first, MCP Expose Abilities for core abilities, then only the add-ons the site needs.
- Add-on groups: Add-ons are easier to scan because they are grouped around the WordPress work they control.
A small install surface is easier to reason about and easier to keep safe.
The current shape of the stack
The wider maintained stack spans core WordPress abilities plus add-ons for builders, SEO, security, forms, ads, files, database work, and other operational surfaces.
Core and builder work
- Posts, pages, media, menus, users, comments, taxonomies, plugins, options, widgets, debug, and cache-adjacent operations.
- Gutenberg, GeneratePress, GenerateBlocks, Elementor, templates, patterns, and layout data.
- Install the core first, then add builder abilities only when the site uses that builder.
Operational add-ons
- Rank Math, Wordfence, Cloudflare, Cache Enabler, Broken Link Checker, Brevo, WPML, Toolset, Formidable, and Advanced Ads.
- Filesystem, database, plugin checks, and workspace email workflows where those operations are actually needed.
- Focused add-ons keep the assistant’s surface easier to inspect and reason about.
A better first path
If you are trying the ecosystem now, keep the first setup narrow and inspectable.
- Install Abilities API.
- Install the adapter used by your MCP client.
- Install MCP Expose Abilities for WordPress-native core abilities.
- Add only the specific ability plugins that match the site stack.
- Start with harmless read operations before letting an assistant make changes.
- Use the current MCP Expose Abilities page as the overview.
That gives the assistant useful WordPress access without making the setup harder than the work it is supposed to save.
Frequently asked questions
Why split MCP abilities into add-on plugins?
Add-ons let each site expose a focused set of abilities instead of treating every WordPress operation as one all-or-nothing surface.
Does every site need every MCP ability plugin?
No. A GeneratePress site does not need Elementor abilities, and a site without Brevo does not need Brevo abilities. Install only what matches the site.
What is the safest way to start testing WordPress MCP abilities?
Start with the core overview, install only the needed plugins, and test harmless read operations before allowing an assistant to make changes.
Powerful tools become useful when people know where to start.
Good automation starts with trust: what the assistant can do, why that ability exists, and whether the right WordPress permission still applies.
- Start with the current core overview.
- Add only the abilities that match the site.
- Keep every exposed operation named and inspectable.
- Tighten onboarding and release information as the ecosystem grows.
Which WordPress operation would you want exposed first, and which should stay out of reach?