WordPress MCP v1.3.0: From 14 to 58 Tools — What Changed and How It Compares

How v1.3.0 Differs from the Official WordPress MCP Adapter

The most important comparison is with the official WordPress MCP Adapter.

The official adapter is built around the WordPress Abilities API. Its job is to map registered WordPress abilities into MCP tools, resources and prompts while preserving WordPress permission callbacks and capability checks.

Conceptually:

WordPress Ability
      ↓
MCP Adapter
      ↓
MCP Tool / Resource / Prompt
      ↓
AI Client

That is a strong architecture for the WordPress ecosystem because plugin developers can register abilities and have a standardized MCP layer expose them.

JOOservices WordPress MCP solves a different, more opinionated problem.

It ships a curated remote management surface with concrete tools such as:

wordpress_update_plugin
wordpress_upload_media
wordpress_seo_audit
wordpress_get_404_log
wordpress_restore_revision
wordpress_get_site_health

The architecture separates the WordPress plugin from the MCP server:

ChatGPT / MCP client
        ↓
independent MCP server
        ↓
scoped HTTPS API
        ↓
WordPress plugin
        ↓
WordPress Core

This makes one MCP server capable of connecting to multiple independent WordPress sites while keeping per-site connection scopes on the WordPress side.

Official Adapter vs JOOservices WordPress MCP

These approaches are not mutually exclusive. The official Adapter is infrastructure for an abilities-driven WordPress ecosystem; JOOservices WordPress MCP is deliberately opinionated about the WordPress workflows it exposes.

What About the Older Automattic WordPress MCP Project?

The older Automattic/wordpress-mcp repository has been archived and its own documentation directs users toward WordPress/mcp-adapter as the canonical path going forward.

That distinction is worth making because “WordPress MCP” can refer to several unrelated projects. When comparing implementations today, the official reference should be the WordPress MCP Adapter rather than the archived Automattic plugin.

Other WordPress MCP Approaches

The ecosystem is already diverse, and raw tool count is not a useful measure by itself.

IATO MCP

IATO MCP runs the MCP endpoint directly from a self-hosted WordPress installation and focuses heavily on SEO workflows and Elementor. Its current documentation describes native WordPress tools, SEO adapters, Elementor editing, OAuth and reversible writes through change receipts and rollback.

The interesting idea here is rollback. An agent can be authorized and still make a bad decision. Reversible writes are a different safety layer from authentication.

WSP WordPress MCP

WSP WordPress MCP uses WordPress abilities and exposes core WordPress, Yoast SEO, Elementor and WooCommerce functionality. It is a good example of a feature-oriented plugin that can expose specialized abilities only when the corresponding WordPress plugin is active.

Large Tool-Surface Servers

Other projects intentionally expose much larger surfaces. For example, wp-mcp-server currently advertises more than 190 tools covering Gutenberg, Elementor, WooCommerce, ACF, accessibility, forms, multilingual content, SEO and administration.

That can be powerful, but my goal with JOOservices WordPress MCP is not to win a tool-count competition.

The next tool should exist because it completes a real workflow and can be permissioned safely — not because a larger number looks better in a README.

Why Not Just Give an Agent the WordPress REST API?

WordPress already has a REST API, but a raw REST endpoint and an MCP tool communicate different levels of intent.

Compare:

POST /wp-json/...

with:

wordpress_update_plugin

An MCP tool tells the model what operation exists, which arguments are required, which values are valid, and what result shape to expect.

JOOservices adds another control layer:

MCP tool
    ↓
connection scope
    ↓
WordPress capability
    ↓
input validation
    ↓
explicit confirmation when required
    ↓
WordPress operation

For agentic systems, that extra semantic and authorization layer is the point.

Scopes Matter More as the Tool Surface Grows

Going from 14 tools to 58 increases capability, but it also increases risk if every connection receives every permission.

A writing connection might only need:

site.read
posts.read
posts.create
posts.update
media.read
media.upload
media.update

It does not need:

plugins.delete
users.delete
themes.activate
core.update

The safest permission remains the permission an agent never receives.

Authorization and Confirmation Are Different

Another design decision that became more important after v1.0.0 is separating authorization from confirmation.

A connection may be authorized to update a plugin. That does not mean a model-generated tool call should silently update production the instant it appears.

High-impact operations can therefore require both:

Does this connection have the required scope?

            AND

Did the user explicitly approve this operation?

This applies to operations such as plugin installation/deletion, theme changes, user administration, publishing, core updates, permanent deletion and site-wide robots.txt changes.

Upgrading from v1.0.0 to v1.3.0

If you are still on v1.0.0, this should be treated as a substantial capability upgrade rather than a small patch.

1. Upgrade the WordPress plugin and MCP server from the matching v1.3.0 release source. Do not mix an old server with a newer plugin and assume the schemas match.
2. Review every connection scope. New administrative capabilities should not become implicitly available to an old writing connection.
3. Re-run MCP tool discovery. Verify the tool list exposed by the actual running server.
4. Test write operations on a non-critical post first. Include featured media and media metadata.
5. Verify SEO changes in public HTML. Do not rely only on an internal “saved” response.
6. Check plugin/theme/user permissions separately.
7. Verify revision recovery, redirects and confirmation flows.
8. Review MCP request logs after the upgrade.

On the current JOOservices deployment, the WordPress plugin reports version 1.3.0 and the connected runtime exposes 58 MCP tools. That runtime verification is the baseline I use when documenting the release.

Final Thoughts

v1.0.0 proved that ChatGPT could work with WordPress through a scoped MCP integration.

v1.3.0 expands that idea into a broader operations layer:

Content
Media + Featured Images
SEO
Plugins
Themes
Users
Redirects + 404s
Revisions
Navigation
robots.txt
Site Health
Core Updates
Maintenance
Observability

The project is more powerful now, but the direction is still the same: give AI agents useful WordPress workflows without treating the AI as an unrestricted administrator.

GitHub: https://github.com/jooservices/wordpress-mcp