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

When I released WordPress MCP v1.0.0, the goal was intentionally narrow: give ChatGPT and other MCP clients a controlled way to work with WordPress without handing the model unrestricted administrator credentials.

v1.0.0 shipped with 14 WordPress-specific MCP tools. That was enough for content workflows: discover sites, search and read posts, create and update content, moderate comments, inspect taxonomies, and work with media.

WordPress MCP v1.3.0 is a much larger step. The current production MCP runtime used by JOOservices exposes 58 tools.

Important: for this article I am treating the running v1.3.0 MCP server as the source of truth for the current tool surface. README and changelog information is useful for release history, but if documentation and the deployed MCP differ, the runtime wins.

Repository: github.com/jooservices/wordpress-mcp
v1.3.0 branch: release/1.3.0

From 14 Tools to 58

The easiest way to understand v1.3.0 is not as “more post CRUD”. The project has moved from a content connector toward a broader WordPress operations interface for AI agents.

The 58 runtime tools currently break down into these groups:

Total: 58 tools.

Complete Content Workflow, Including Featured Images

One of the practical gaps in v1.0.0 was that an agent could upload media but could not complete the full publishing workflow by assigning a featured image.

v1.3.0 adds featured_media support to content create/update operations and expands the media lifecycle:

wordpress_list_media
wordpress_get_media
wordpress_upload_media
wordpress_update_media
wordpress_delete_media

An AI publishing workflow can now be:

write article
    ↓
select or generate image
    ↓
upload image
    ↓
set title / alt text / caption
    ↓
assign featured image
    ↓
publish

This matters more than it sounds. A tool is most useful when it represents a complete workflow instead of leaving the last manual step to wp-admin.

Plugin Management

v1.3.0 can inspect and manage installed plugins:

wordpress_list_plugins
wordpress_install_plugin
wordpress_activate_plugin
wordpress_deactivate_plugin
wordpress_update_plugin
wordpress_delete_plugin

The important design point is not only that these actions exist. They are protected by separate scopes and high-impact operations require explicit confirmation.

A content-writing connection does not need permission to delete plugins. An administration connection may need it. Those should not be the same connection.

Theme and User Management

The same principle now applies to themes and users. The MCP can list, install, activate, update and delete themes, and it can list, create, update and delete WordPress users when the connection has the required scopes and WordPress capabilities.

This makes v1.3.0 useful for maintenance and administrative workflows, not only editorial work.

SEO Is Now a First-Class Tool Group

The runtime exposes:

wordpress_seo_audit
wordpress_get_seo_metadata
wordpress_update_seo_metadata
wordpress_seo_fix

The normalized interface covers SEO title, meta description, canonical URL, Open Graph fields and noindex status, while the audit can also flag issues such as missing metadata, heading problems, missing image alt text and potentially broken internal links.

The long-term value here is the abstraction. An MCP client should ideally ask to “update SEO metadata”, while the WordPress integration handles the details of Yoast, Rank Math or another supported SEO provider.

There is one rule I consider non-negotiable: the public HTML is the final truth. If an SEO adapter reports that metadata was saved but WordPress does not render it, that is an integration bug, not a successful SEO update.

Redirects, 404 Monitoring and Recovery

v1.3.0 adds redirect and 404 tooling:

wordpress_list_redirects
wordpress_get_404_log
wordpress_upsert_redirect
wordpress_delete_redirect

That enables a useful agent workflow:

inspect recurring 404s
    ↓
find the intended destination
    ↓
suggest a redirect
    ↓
human approval
    ↓
create 301 redirect

Content recovery is also stronger because revisions can be listed and restored:

wordpress_list_revisions
wordpress_restore_revision

For AI-controlled writes, authentication is only half of safety. The other half is being able to see what changed and recover when an authorized change was still the wrong change.

Site Health, Core Updates and Maintenance

The MCP can now inspect WordPress health and update state, toggle maintenance mode, and install an offered WordPress core update when explicitly authorized.

wordpress_get_site_health
wordpress_get_update_status
wordpress_set_maintenance_mode
wordpress_update_core

This is where the project starts to feel less like “ChatGPT can write WordPress posts” and more like a real operations layer.

Observability

v1.3.0 also exposes MCP request statistics and request logs. These report operational information such as request count, success/error state, latency, action and resource type. They intentionally do not turn WordPress into a store for prompts or model conversations.

That gives administrators enough information to answer questions such as:

• Which MCP actions are being used?
• How many requests are failing?
• Which resource types are involved?
• Is latency increasing?