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 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
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
Current references
Core overview
Install path
Add-on groups
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.
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.
1
2
3
4
Which WordPress operation would you want exposed first, and which should stay out of reach?