WordPress MCP Adapter: Install and Connect Agents

The WordPress MCP Adapter is the official plugin that lets an AI agent work with a WordPress site through MCP. It does not ship content tools of its own. It exposes the abilities that WordPress core and your plugins register and mark public, as MCP tools. It needs WordPress 6.9 or newer and is GPL-2.0-or-later. We checked it on 31 October 2026.

Quick facts

Where the old one went

Many guides still point at Automattic's wordpress-mcp plugin. That repository is archived on GitHub. Its own description says it will be deprecated as stable releases of mcp-adapter become available and tells you to use WordPress/mcp-adapter. Its last tagged release was v0.2.5 in July 2025, and GitHub shows no licence for it.

So the maintained option is the WordPress project's adapter. If you find a tutorial that installs the Automattic plugin, treat the steps as out of date and check them against the adapter's docs. The proxy package that the adapter's docs still use for desktop clients, @automattic/mcp-wordpress-remote, is published under Automattic's npm scope, so the Automattic name has not vanished from the setup.

How it works

The adapter sits on top of the Abilities API. An ability is one named action that WordPress core or a plugin registers, with an input schema, a callback and a permission check. The Abilities API is in core from WordPress 6.9, so it needs no separate plugin. The adapter then turns abilities into MCP tools, resources and prompts.

Three ideas matter for anyone installing it.

1. Abilities are private by default. An ability reaches MCP only when its author sets meta.public (or meta.mcp.public) to true. If no plugin on your site has done that, the agent sees an empty list. That is expected, not a fault.
2. The agent acts as a WordPress user. You connect with a username and an Application Password. Every action runs with that user's role. An Editor connection cannot do what an Editor cannot do.
3. The default server is small on purpose. It exposes three meta-tools that let the agent find, inspect and run abilities. The tools/list response stays at three entries however many abilities the site has, which saves context.

The default server also auto-discovers public abilities marked as resources or prompts and lists them alongside the three tools.

The three meta-tools

The docs note that abilities are registered with / in their names, such as mcp-adapter/discover-abilities, and that the adapter converts / to - for the MCP tool names the agent sees.

So a typical agent turn is: discover, read the schema, then execute. That is three steps where a custom server needs one.

Custom servers

A plugin or site can create its own server through the mcp_adapter_init hook and list the abilities to expose. Each listed ability becomes its own MCP tool with a full schema visible straight away.

You can turn the default server off with the mcp_adapter_create_default_server filter, and extend it with mcp_adapter_default_server_config. Both are in the docs.

Install it on the site

The docs give a WP-CLI route:

wp plugin install https://github.com/WordPress/mcp-adapter/releases/latest/download/mcp-adapter.zip --activate

You can also install it from the WordPress.org plugin directory, or download the zip from GitHub releases. The plugin directory lists it as requiring WordPress 6.9, PHP 7.4, and tested up to 7.1.4 as of our check.

Install it on a staging copy first. The adapter is below 1.0 and the repo carries migration guides between 0.x versions, so a change can need a code update.

Connect an agent

There are two ways in, and which one you pick depends on where the site runs.

Route one: HTTP

Every site gets the endpoint https://your-site.example/wp-json/mcp/mcp-adapter-default-server. Use the Site Address from Settings, General, so a site in a subfolder keeps its path. Clients connect with a WordPress username and an Application Password.

Make the password in wp-admin:

1. Go to Users, Profile, or edit the user the agent will use.
2. Scroll to Application Passwords.
3. Enter a name you will recognise, such as "Claude Code on laptop", and add it.
4. Copy the password. WordPress shows it once.

WordPress offers Application Passwords only over HTTPS, except on local development sites, per the site-owner guide.

Route two: STDIO with WP-CLI

For a local site, the agent can start WordPress itself:

wp --path=/path/to/site mcp-adapter serve --server=mcp-adapter-default-server --user=admin

--user sets the WordPress user for permission checks. Without it the server runs unauthenticated, with limited capabilities. This route is best for development, since it needs WP-CLI and file access to the site.

Install it in each agent

The adapter's docs show the STDIO entry and the Node proxy entry for Claude Desktop, Cursor, VS Code and Windsurf, and a direct HTTP route for Claude Code. The rest is our adaptation. For how each agent names fields, see MCP clients.

Claude Code

The site-owner guide describes Claude Code connecting over HTTP with a Basic auth header. Build the value from your username and Application Password:

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

Then add the server, our assembly of the documented pieces:

claude mcp add --transport http wordpress \
  https://your-site.example/wp-json/mcp/mcp-adapter-default-server \
  --header "Authorization: Basic <base64-value>"

For a local site over STDIO:

claude mcp add wordpress -- wp --path=/path/to/site mcp-adapter serve --server=mcp-adapter-default-server --user=admin

Codex

Our adaptation, in ~/.codex/config.toml, using the proxy:

[mcp_servers.wordpress]
command = "npx"
args = ["-y", "@automattic/mcp-wordpress-remote@latest"]

[mcp_servers.wordpress.env]
WP_API_URL = "https://your-site.example/wp-json/mcp/mcp-adapter-default-server"
WP_API_USERNAME = "your-username"
WP_API_PASSWORD = "xxxx xxxx xxxx xxxx xxxx xxxx"

Cursor

The docs' entry, in ~/.cursor/mcp.json:

{
  "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"
      }
    }
  }
}

Antigravity

Our adaptation. Put the same proxy entry in ~/.gemini/config/mcp_config.json under mcpServers. Antigravity's serverUrl field is for Streamable HTTP, so the direct route would need it to send a Basic auth header. Antigravity's docs say custom HTTP headers, such as Authorization, go in a headers object. We did not test it against this adapter. Gemini CLI is now for Code Assist enterprise customers only.

OpenCode

Our adaptation, in opencode.json:

{
  "mcp": {
    "wordpress": {
      "type": "local",
      "command": ["npx", "-y", "@automattic/mcp-wordpress-remote@latest"],
      "environment": {
        "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"
      }
    }
  }
}

OpenCode also supports a remote type with a URL and headers, which fits the direct HTTP route.

Making abilities available

The adapter does nothing useful until something registers an ability. There are two cases.

A plugin you use already registers abilities. Check its docs for a public flag. Some plugins register abilities and leave them private, and the adapter only shows abilities marked public. We did not survey which plugins do so by default.

You write your own. A short example from the adapter's quick start registers a read-only "get site info" ability:

add_action( 'wp_abilities_api_init', function () {
    wp_register_ability( 'my-plugin/get-site-info', [
        'label'        => 'Get Site Information',
        'description'  => 'Retrieves basic information about the site',
        'category'     => 'site',
        'input_schema' => [ 'type' => 'object', 'properties' => [] ],
        'execute_callback'    => fn( $input ) => [
            'site_name' => get_bloginfo( 'name' ),
            'site_url'  => get_site_url(),
        ],
        'permission_callback' => fn() => current_user_can( 'read' ),
    ] );
} );

Then set meta.public to true to expose it. Keep the permission_callback honest. It is the line that decides who can run the ability.

Test the connection

Ask the agent to list what the site exposes. If it says there are no abilities, no plugin has marked any public yet. To test over STDIO without an agent:

echo '{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}' \
  | wp mcp-adapter serve --user=admin --server=mcp-adapter-default-server

wp mcp-adapter list shows the servers on the site and how many tools, resources and prompts each has. The --protocol option counts components under one MCP revision, either 2025-11-25 or 2026-07-28.

Security notes

A WordPress site holds content, users and sometimes customer data, so this deserves care.

1. Use a dedicated user. Create a user for the agent, with the lowest role that does the work. An Editor is safer than an Administrator, and the user is easy to disable.
2. Use an Application Password you can revoke. Never the login password. Revoke it from the user profile when you stop.
3. Never run STDIO with an admin user you did not mean to grant. --user=admin gives the agent administrator rights for that session.
4. Expose few abilities. Abilities are private by default. Mark public only what you want an agent to reach.
5. Check each ability's permission callback. The adapter checks permissions per ability, and your own abilities should check a capability, not just login.
6. Transport permissions are configurable. By default a server requires a logged-in user. You can set a callback per server, such as admin-only. If a callback throws an error, the docs say it falls back to the logged-in check.
7. Treat content as untrusted. An agent that reads comments or post bodies is reading text anyone may have written. Do not give such an agent write access beyond what it needs.
8. HTTPS only. Basic auth over plain HTTP exposes the password.
9. Staging first. Run destructive abilities against a copy.

Limits and known issues

• Pre-1.0. The version is 0.7.1 and migration guides exist for three earlier steps. Pin a version in production.
• Empty on a fresh install. Without public abilities the agent has nothing to call.
• Requires WordPress 6.9. Older sites lack the Abilities API in core, and the plugin's WordPress.org page says the standalone Abilities API plugin is no longer a supported installation path.
• Proxy for most desktop clients. The docs route desktop clients through a Node proxy, so Node must be installed.
• Three-step calls. The default server's discover, inspect, execute pattern adds turns compared with a custom server.
• Open issues. The repo showed 62 open issues on 31 October 2026. We did not read them, so search the tracker for auth, sessions and multisite before you rely on those.

Alternatives

WP-CLI, run by a shell tool in your agent, also covers many site tasks, with the risks of shell access.

The MCP servers hub lists more.

Which agents it suits

• Claude Code and OpenCode can use the direct HTTP route.
• Codex, Cursor and Antigravity can use the Node proxy entry.
• Developers working on a local site can use the WP-CLI STDIO route, with no password at all.
• Plugin authors gain most, since registering abilities makes their plugin reachable from every MCP client.

Our take

We did not install the adapter for this page. This comes from the repo, the docs in it and the WordPress.org listing.

The design is careful. Private-by-default abilities, per-ability permission callbacks and a connection that acts as a normal WordPress user are the right defaults for a system that runs on live sites. The small three-tool default server is also a sound choice for context size.

The catch is the early state. At 0.7.1 it will change, and it is only as useful as the abilities your plugins register. Expect to spend time on which abilities exist before the agent can do anything.

Use it on staging first, connect as a low-role user and keep the exposed list short. If you only need to read a site, a fetch tool does that with no setup on the WordPress side.

A short setup checklist

1. Back up the site and work on a staging copy.
2. Confirm WordPress 6.9 or newer.
3. Install and activate the adapter.
4. Create a dedicated user with a low role.
5. Create an Application Password for it.
6. Add the server to your agent and ask it to list abilities.
7. Register or enable only the abilities you want public.
8. Revoke the password when you finish.

Related pages

• Claude Code, for the claude mcp add lines above
• Cursor, which the adapter docs list
• Windsurf, also listed in the adapter docs
• All add-ons, the full directory

Frequently asked questions

What is the WordPress MCP Adapter?

The official plugin that exposes WordPress abilities as MCP tools, resources and prompts over HTTP or WP-CLI STDIO.

What happened to Automattic/wordpress-mcp?

It is archived, and its description points to WordPress/mcp-adapter.

Can an agent edit my posts with it?

Only through public abilities, and only within the connected user's permissions.

What does it need?

WordPress 6.9 or newer and PHP 7.4 or newer. Application Passwords need HTTPS except locally.

Is it safe to connect to a live site?

Use a dedicated low-role user, a revocable password and a short list of public abilities, and try it on staging first.