WordPress + MCP in Practice: From the Abilities Concept to a Working Integration

Home » Blog » WordPress + MCP in Practice: From the Abilities Concept to a Working Integration

In our previous article, we described how AI capabilities are moving deeper into the WordPress core – led by the Abilities API, which has been a core part of the system since WordPress 6.9. Abilities standardize how core, plugins, and themes describe their functionality to the outside world, complete with input/output schemas, permission checks, and callbacks.

What sounds convincing in theory only becomes useful once an AI application can actually call these abilities. That’s exactly what the Model Context Protocol (MCP) enables: an open protocol through which AI assistants such as Claude Desktop, Claude Code, Cursor, or VS Code communicate with external tools and data sources. This article shows how the connection between WordPress abilities and MCP clients is built in practice – as a direct follow-up to our Abilities API article.

WordPress + MCP in Practice: From the Abilities Concept to a Working Integration

Two Paths to the Same Goal

In practice, two different approaches have emerged for making WordPress addressable via MCP.

1. The official path: Automattic’s mcp-adapter

Automattic experimented early on with the original “WordPress MCP” plugin. That plugin is now considered deprecated – its successor is called mcp-adapter, designed as an “AI Building Block” for WordPress. It is now considered stable and is set to become the canonical plugin and Composer package for MCP integration in WordPress. Anyone developing their own plugins or themes and wanting to expose their capabilities via MCP should build directly on mcp-adapter rather than the old plugin.

The mcp-adapter acts as a translator: it takes the abilities registered internally through the Abilities API and makes them discoverable and callable for MCP clients – including the necessary metadata on inputs, outputs, and permissions.

2. The pragmatic path: a standalone MCP server

For agencies and developers who want to work quickly with existing WordPress installations without registering anything on the PHP side themselves, standalone Node.js-based MCP servers such as mcp-wp-abilities are available. These connect to any WordPress 6.9+ instance via the REST API and automatically discover all registered abilities at runtime, without a fixed tool list hard-coded anywhere. Any plugin that registers its own abilities automatically becomes available to the MCP client as a result.

This approach works particularly well when connecting multiple client sites without maintaining custom code on each one.

Practical Setup with a Standalone Server

As a concrete example, here’s how to set up a standalone MCP server against an existing WordPress installation.

Requirements

  • WordPress 6.9 or newer (the Abilities API must be active)
  • Node.js 18 or newer on the machine running the MCP server
  • A WordPress Application Password for authentication

An application password can be created under Users → Profile → Application Passwords in the WordPress admin. It should be issued separately per use case and rotated regularly.

Installation

bash

npm install -g mcp-wp-abilities

Configuration

The server requires three environment variables:

VariableDescription
WORDPRESS_URLThe URL of the WordPress site, e.g. https://client-site.com
WORDPRESS_USERNAMEThe WordPress username
WORDPRESS_APP_PASSWORDThe application password generated earlier

For Claude Desktop, the server is added to the configuration file (macOS path shown as an example):

json

{
  "mcpServers": {
    "wp-abilities": {
      "command": "npx",
      "args": ["-y", "mcp-wp-abilities"],
      "env": {
        "WORDPRESS_URL": "https://client-site.com",
        "WORDPRESS_USERNAME": "your-username",
        "WORDPRESS_APP_PASSWORD": "your-application-password"
      }
    }
  }
}

For Claude Code, the server can be registered via the CLI:

bash

claude mcp add wp-abilities \
  --env WORDPRESS_URL=https://client-site.com \
  --env WORDPRESS_USERNAME=your-username \
  --env WORDPRESS_APP_PASSWORD=your-application-password \
  -- npx -y mcp-wp-abilities

First Requests

After restarting the MCP client, the abilities registered on the WordPress site are available as tools. In practice, typical requests look like this:

  • “Show me all drafts from last week.”
  • “Create a blog post draft titled ‘Summer 2026 Updates.’”
  • “Which plugins are installed on this site?”

The client translates these natural-language requests into concrete tool calls, which the MCP server forwards to the WordPress REST API.

Registering Your Own Abilities

Anyone developing a plugin can register their own capabilities, which then automatically become visible through mcp-adapter or an abilities-discovery server. The principle can be seen in a WooCommerce demo plugin that registers a custom ability for querying store statistics. The rough process:

  1. An ability is registered under a unique namespace (e.g. my-plugin/customer-stats).
  2. Input and output schemas are defined as JSON Schema, so the AI knows which parameters are expected and what structure the response has.
  3. A permission check defines which user role is allowed to execute the ability.
  4. A callback contains the actual logic – typically a thin wrapper around functionality the plugin already has.

The big advantage: existing code barely needs to change. At its core, an ability is a standardized wrapper around functionality that already exists in the plugin.

Security Considerations

The convenience of controlling WordPress through natural language comes with responsibility:

  • Principle of least privilege: MCP calls run under the permissions of the WordPress user in use. For the connection, a restricted user should be used wherever possible instead of an administrator account.
  • Rotate application passwords: Application passwords should be renewed regularly and revoked immediately if compromise is suspected.
  • Enforce HTTPS: MCP connections to WordPress should run exclusively over encrypted connections.
  • JWT vs. application password: The official mcp-adapter path often relies on token-based JWT authentication with its own management interface, while standalone servers frequently use classic application passwords. For production environments with multiple users, the JWT variant is usually the lower-maintenance choice.
  • Audit logging: Especially for write operations (publishing posts, creating users), logging which request triggered which change is advisable.

Conclusion and Outlook

The combination of the Abilities API and MCP already makes WordPress addressable by AI assistants today – whether through the official mcp-adapter for custom plugin development or through standalone discovery servers for a quick start with existing installations. For sevmatic clients, this means recurring editorial or administrative tasks can already be experimentally turned into natural-language workflows today.

With the WP AI Client and the planned Workflows API announced for WordPress 7.0, this path is set to become even more convenient – more on that in one of our upcoming posts.


This article is part of our series on AI integrations in the WordPress ecosystem. You can find the previous post on the Abilities API [linked here].

Heinrich Franz