WordPress MCP Adapter: Setup, Limits, and When a Plugin Is Easier

Let’s jump right into it.

What the WordPress MCP Adapter is (and isn’t)

The adapter is infrastructure, not a feature product. It bridges WordPress’s Abilities API with the MCP specification: an ability is one registered action, such as getting site info or creating a draft post, and the adapter turns the public ones into MCP tools a client can call. The readme is blunt about scope: “MCP Adapter is the server and transport layer. It does not provide any AI features itself.”

The launch post announced the plugin’s WordPress.org listing: as a canonical plugin, “end-users and plugin developers can rely on MCP Adapter without worrying about multiple conflicting, outdated copies”. Automattic’s older WordPress MCP plugin is being deprecated: the project’s issue tracker says “Users are encouraged to migrate to mcp-adapter”.

The numbers: version 0.7.1, 50,000+ active installs, and a project that calls itself “still experimental”. Everything the AI can do comes from abilities that WordPress core or your plugins register and mark public, and each call runs as the WordPress user you connect with (an Application Password over HTTP, or the --user flag over STDIO) with that user’s permissions.

How to set up the MCP Adapter 🔧

The adapter’s own site-owner guide covers this path in detail; here is the short version. The claude mcp add command below is the guide’s own and was not run as written; the same Basic header over HTTP worked from a Claude Code MCP config file.

Install it

Go to Plugins > Add New, search for “MCP Adapter”, and install the card by WordPress.org. WP-CLI does the same job: wp plugin install mcp-adapter --activate.

Create an Application Password

HTTP clients authenticate as a WordPress user with an Application Password. Go to Users > Profile, scroll to Application Passwords, give it a name you will recognize (“Claude Code on my laptop”), click Add Application Password, and copy the value, because WordPress shows it only once.

One ground rule: live sites need HTTPS, because WordPress only offers Application Passwords on sites served over HTTPS, except on local development sites.

Connect your client

Three routes, depending on where the client runs.

HTTP clients that accept a custom header, such as Claude Code, skip the helper. The header is Authorization: Basic plus the base64 encoding of username:application-password:

printf 'your-username:xxxx xxxx xxxx xxxx xxxx xxxx' | base64 | tr -d '\n'

claude mcp add --transport http my-wordpress-site \
  https://example.com/wp-json/mcp/mcp-adapter-default-server \
  --header "Authorization: Basic PASTE_THE_BASE64_HERE"Code language: JavaScript (javascript)

Desktop apps that read a JSON config, such as Claude Desktop, Cursor, VS Code and Windsurf, go through @automattic/mcp-wordpress-remote, “a small helper that runs on your computer and passes the client’s requests to your site”. In Claude Desktop, open the config from Settings > Developer > Edit Config; in Cursor it is ~/.cursor/mcp.json. Add this entry, then save and restart the app. The helper needs Node.js installed:

{
  "mcpServers": {
    "my-wordpress-site": {
      "command": "npx",
      "args": ["-y", "@automattic/mcp-wordpress-remote@latest"],
      "env": {
        "WP_API_URL": "https://example.com/wp-json/mcp/mcp-adapter-default-server",
        "WP_API_USERNAME": "your-username",
        "WP_API_PASSWORD": "xxxx xxxx xxxx xxxx xxxx xxxx"
      }
    }
  }
}Code language: JSON / JSON with Comments (json)

A local site with WP-CLI skips passwords and serves the adapter over STDIO (if WP-CLI is new to you, install it first). Add this entry to the client’s JSON config, with your own installation path and username:

{
  "mcpServers": {
    "my-wordpress-site": {
      "command": "wp",
      "args": ["--path=/path/to/your/wordpress", "mcp-adapter", "serve", "--server=mcp-adapter-default-server", "--user=your-username"]
    }
  }
}Code language: JSON / JSON with Comments (json)

Test the connection

Start a new chat and ask: “List the WordPress abilities you can use on my site.” A list of abilities, or the message that the list is empty, means the connection works.

Keep the connection contained

Before an AI client touches a real site, a few rules keep the connection contained. Connect the AI as a dedicated WordPress user with the lowest role that can do the job, create one Application Password per client so revoking one does not touch the others, and try new abilities on a staging copy first: the guide’s own warning is “Abilities change your live site the same way an action in wp-admin does.” Treat the content the AI reads as untrusted input, too: OWASP’s LLM01 entry covers indirect prompt injection, instructions smuggled in through external content such as websites or files, and a comment or imported post can carry them.

What your AI can do right after connecting 🔍

Here is what Claude Code saw on WordPress 7.1.3 with MCP Adapter 0.7.1 and no other active plugins, signed in as an administrator through an Application Password in a Basic header and limited to MCP tools.

tools/list returns exactly three tools: mcp-adapter-discover-abilities, mcp-adapter-get-ability-info and mcp-adapter-execute-ability. Asked the guide’s test prompt, the agent called discover once and found exactly three abilities: core/get-site-info, core/get-user-info and core/get-environment-info. Its reply summed them up as “All three only read information, and none of them can change anything on your site.”

Why three, and why read-only? A source check of WordPress 6.9, 7.0, 7.0.7, 7.1 and 7.1.3 shows the change: core registers the same three abilities in each of them, but only the 7.1 releases mark them public, and all three are annotated readonly and non-destructive. On 7.1 a fresh adapter install has something to show; on 6.9 and 7.0 the list starts empty until a plugin or a filter opts abilities in (verified in core source, not on a live 6.9 or 7.0 site).

So what happens with a real content task? The next prompt:

Find my draft post about holiday gift boxes and add a two-sentence intro that mentions our 12 oz, 2 lb and 5 lb bag sizes. Keep it as a draft.

The agent called discover, ran core/get-site-info, and stopped, because no ability on the site can list or edit posts. Its reply: “I couldn’t make this change. The WordPress connection I have only offers three read-only tools: site info, user info and environment info.” The draft was untouched afterwards: same content, same modified time, still zero revisions.

Writes come from plugins that register public abilities. WooCommerce is one example: it registers product and order abilities that AI clients can discover and run through the adapter, currently in developer preview.

Limits you’ll hit ⚠️

• claude.ai and ChatGPT on the web cannot connect on the default path. Both default to an OAuth sign-in when you add a connector, and the adapter has no OAuth server, so, in the guide’s words, “these apps cannot connect to MCP Adapter on their own today”. Pointing a claude.ai custom connector at the adapter over HTTPS ended with the toast “Couldn’t register with Adapter test’s sign-in service. You can try again, or add an OAuth Client ID in the connector settings.” and a site log with 404s on the three OAuth discovery paths and the registration fallback. One nuance: Claude documents request-header authentication, which can carry a Basic credential, as “in beta and available to a limited set of organizations”; on an individual account the dialog showed a Request headers section, but whether a Basic header gets past the adapter is untested.
• Core’s abilities are read-only. As one contributor’s tracking issue puts it, “Core’s abilities are read-only, so pages, posts, photos and settings are out of reach.” That issue, #394, and its successor, #402, propose fixes (a REST bridge now, core CRUD abilities later); #394 is one contributor’s proposal, and #402 tracks “the experimental core abilities agreed in #core-ai”, so neither has shipped yet.
• There’s no wp-admin screen. The adapter “adds no AI features and no new screens in wp-admin”, and the issue asking for a site-owner path concedes there is “no admin UI on purpose”. Apart from the Application Passwords list under Users > Profile, which shows each credential and when it was last used, the adapter adds no screen of its own showing which abilities are exposed or what the AI changed.
• It is experimental. The launch post says so: “still experimental” with a stable 1.0 as the goal, and the 0.7.0 upgrade notice lists “Breaking changes for extensions”. The 0.7.0 breaks target extension code (custom transports, validator classes), and 0.6.0 raised the requirement to WordPress 6.9 and changed which abilities the default server exposes. The connection setup hasn’t moved: the endpoint and Application Password setup in the February developer post still match the 0.7.1 guide. Read the changelog before updating a production site.
• Bundled copies linger. Some plugins shipped their own bundled copy of the adapter; 0.7.0 deprecated bundling it as a library, and 0.7.1 registers the canonical plugin’s autoloader first so version selection can happen. The WooCommerce developer docs say WooCommerce does not bundle the MCP adapter, but WooCommerce 11.2.1 still ships an older copy in its vendor folder; in one probe with both present, the standalone 0.7.1 classes loaded and no conflict appeared.

Extending the adapter as a developer 🛠️

If you write plugins, this is where the adapter gets interesting. Register an ability with wp_register_ability(), mark it public with meta.public (or meta.mcp.public for MCP-only exposure), and the default server’s discover tool picks it up; the developer handbook covers the registration API. The February post’s wp_register_ability_args snippet for core abilities predates WordPress 7.1, which now marks its own three abilities public.

For bigger integrations, hook mcp_adapter_init and register a custom server with its own tools, resources and prompts. And if your plugin needs the adapter, declare it with Requires Plugins: mcp-adapter in the plugin header instead of bundling a copy.

Troubleshooting the adapter

The short version of the guide’s troubleshooting section:

When a plugin is easier than the adapter 🔌

The adapter’s own guide names the exit ramp: “Use a desktop client, or a plugin that adds an OAuth sign-in to your site.”

The tested plugin example is Easy MCP AI, a free plugin that runs its own MCP server on your site (it does not use the adapter) and signs clients in over OAuth 2.1 or API keys. Easy MCP AI is built by Themeisle, the team behind WPShout. Easy MCP AI’s documented clients include Claude (web, desktop and Claude Code), ChatGPT, Cursor, GitHub Copilot in VS Code and OpenAI Codex CLI. Its 280+ built-in tools work from WordPress 6.0, and the wp.org listing shows 30,000+ active installs.

The same owner request then went to a site with the same four posts and Easy MCP AI in place of the adapter. That site also ran WooCommerce, with the shop pages WooCommerce creates, and had About and Contact pages the adapter site lacked, so read this as a comparison of outcomes, not a controlled benchmark.

On the Easy MCP AI site, authenticated with a Full access API key bound to an administrator (an API key, not the OAuth flow), the agent found the draft, inserted the intro at the top, and re-read the post to confirm. Its reply opened with “I added the intro to your draft” and confirmed the post “is still a draft”. The draft gained one revision and kept its status, and its unscheduled post date moved to the day of the edit, which the agent pointed out itself. The agent also flagged a content problem the prompt itself had created: “The 5 lb size isn’t in any of the boxes.”

Every one of those calls left a row in the plugin’s Audit log, which records every MCP tool call while the log is on (and it is on by default):

Side by side:

The plugin route has its own costs. Easy MCP AI’s surface is much larger: 280+ tools, and its general REST tools can call the REST API routes of WordPress and your other plugins as the connected user, with each route’s own permission check deciding, so bind the connection to a user whose role fits the job. The API-key form starts on Full access with a 30-day expiry, so pick Read-only for read-only jobs, and turn on Ask before destructive actions if you want Easy MCP AI to pause its own delete, uninstall and other destructive tools for your approval, keeping in mind that Always ask for wins over Never ask for, a site’s approval filter has the last word over both lists, and API keys marked Unattended never pause. OAuth sign-in needs HTTPS on live sites. And run one MCP plugin per site: Easy MCP AI does not need the adapter active, and its conflict check flags a running copy.

👉 Easy MCP AI is free on WordPress.org: install it from the plugin directory.

Bottom line 💬

If you are a developer building AI features into plugins, the MCP Adapter is the right foundation: canonical, small, and deliberately unopinionated about what gets exposed. If you are a site owner who wants claude.ai or ChatGPT connected to a live site, or draft edits that none of your installed plugins offers as an ability, a plugin with an OAuth sign-in and built-in tools is the route that fits (adding a custom MCP server in ChatGPT depends on your plan and workspace settings), and the adapter can wait until your plugins grow abilities. Whichever route you pick, start with a low-role WordPress user and the narrowest credential that does the job.

Have you connected an AI client to your WordPress site yet? What did you ask it to do first?