WordPress MCP in 2026: The Adapter, the Abilities API and the Plan for WordPress 7.3

WordPress MCP lets AI agents such as Claude, Cursor or VS Code work with a WordPress site through the Model Context Protocol. On self-hosted sites it runs through the official MCP Adapter plugin, version 0.7.1, which exposes abilities registered with the Abilities API. On 28 October 2026 the Core AI team proposed bringing MCP into WordPress 7.3.

This is a fast-moving topic and most articles about it are already out of date. In October 2026 alone, the adapter landed in the WordPress.org plugin directory, received a security fix, and became the subject of a formal proposal to make MCP part of WordPress itself. This guide sets out what is actually in core, what is a plugin and what is still a plan, checked against the primary sources on 29 October 2026. It also includes our own count of the MCP plugins in the WordPress.org directory, a tested setup walkthrough and a security checklist. We will update this page when WordPress 7.2 ships, when the 7.3 plan is confirmed, or when the adapter reaches version 1.0.

What is WordPress MCP?

WordPress MCP is the use of the Model Context Protocol to let an AI agent, such as Claude, Cursor or VS Code's assistant, read and act on a WordPress site through a defined set of tools. MCP is an open standard for connecting AI clients to outside systems. Instead of each AI app building its own WordPress integration, the site publishes what it can do, and any MCP client can discover and call it.

On a self-hosted site, three pieces work together:

1. The Abilities API, in WordPress core since 6.9. A plugin registers an "ability": a named action such as "get post count" or "create a draft", with an input schema, an output schema and a permission check.
2. The MCP Adapter, an official plugin from the WordPress Core AI team. It turns public abilities into MCP tools and gives your site one address that AI clients connect to: /wp-json/mcp/mcp-adapter-default-server.
3. An MCP client on your side: Claude Desktop, Claude Code, Cursor, VS Code or another app that speaks MCP. It signs in as a WordPress user.

The plugin's own FAQ puts the division of labour plainly: "MCP Adapter is the server and transport layer. It does not provide any AI features itself. What it exposes comes from the WordPress Abilities API." That sentence answers most of the confusion in the search results for this topic. Installing the adapter does not add an AI to your site. It opens a controlled door, and what the agent can do through that door depends entirely on which abilities your plugins have made public, and on the role of the user the agent signs in as.

The search results for "wordpress mcp" mix three different things under one name: the official adapter, WordPress.com's hosted MCP server, and dozens of third-party plugins and services that call themselves a "WordPress MCP server". They are not the same, and the differences matter for security. This guide separates them.

What changed in October 2026, in date order

October 2026 moved WordPress MCP from an experiment for developers toward a planned part of WordPress itself. The adapter reached the official plugin directory on 2 October, received a security fix on 16 October, and on 28 October the Core AI team published a proposal to bring MCP, a set of core abilities and OAuth sign-in into WordPress 7.3. Here is the full sequence, with the source for each line.

Two of these lines deserve a second look.

The 0% benchmark. The AI team's summary for its 21 October meeting reports that "agents completed 0% of the benchmarked tasks using the MCP Adapter alone, primarily because the adapter does not currently bundle the abilities needed to perform common WordPress operations." Agents that used the REST API instead did better, though the summary notes "some approaches introduced security concerns". For a site owner, the plain reading is: connecting the adapter on its own gives an agent almost nothing to do. The useful work comes from abilities, which today arrive from plugins.

The 7.3 target is a proposal. The 28 October post, "WordPress for the Agentic Web" by Jason Adams, says the work is "targeting WordPress 7.3 while using the 7.2 release cycle to establish the necessary foundations", and also that "inclusion in core will depend on technical readiness, security, and the normal core review processes." The 21 October summary adds that "no release commitment was made." No release date for WordPress 7.3 has been published. We will update this page when the 7.3 plan is confirmed, when WordPress 7.2 ships, or when the MCP Adapter reaches version 1.0.

What is in core, what is a plugin, and what is still a plan

Today, only the Abilities API and the AI Client are part of WordPress core. The MCP Adapter is a separate plugin, it is labelled experimental, and MCP in core is a proposal for 7.3. Secondary sources disagree on this, so here is each piece checked against its primary source on 29 October 2026.

The team explained on 7 October why the adapter is not in core yet: "the MCP specification itself is still in flux, with a major breaking update having shipped less than three months ago." Core WordPress has a strong promise of backward compatibility and is updated automatically on millions of sites, so a fast-moving protocol is a poor fit. Shipping it as a canonical plugin lets it change quickly. The 21 October discussion kept several routes open for 7.3: bundling the plugin, enabling it through existing core screens, or merging specific parts into core.

How many WordPress plugins now support MCP? Our count

We found 196 plugins in the WordPress.org directory that mention MCP in their name, short description, tags or slug, and 158 of them (81%) were added in 2026. The median plugin in that group has 20 active installs. A small number of large, established plugins account for most of the reach.

What the count shows

The largest plugins that now mention MCP in their listing are Elementor (10,000,000+ active installs), Jetpack (3,000,000+, whose listing name now includes "AI Agents" and "MCP"), and Premium Addons for Elementor (600,000+). Among plugins built for MCP from the start, the largest are WPVibe (90,000+, added 20 April 2026), the official AI plugin (60,000+), the official MCP Adapter (50,000+ within four weeks of its 2 October listing) and Easy MCP AI (30,000+, added 25 March 2026). A separate search for the Abilities API found 33 plugins that name it, 26 of them added in 2026, with a median of 40 installs.

The month-by-month chart tells the real story: about one new MCP plugin a week in early 2026, rising to roughly one a day by July. The rise from May onward coincides with the release of WordPress 7.0 on 20 May, though a count like this cannot prove cause. It is also a warning. Most of these plugins are new, small and written by authors with no track record yet, and each one asks for some of the most sensitive access a site can give.

How we counted

• Date: 29 October 2026, using the public WordPress.org plugin API (query_plugins, every results page, 250 per page).
• Filtering: the directory search matches full text, so many of its 754 results only mention MCP deep in a readme. We kept a plugin only if "MCP" or "Model Context Protocol" appears as a word in its name, short description, tags or slug.
• Limits: active installs are rounded buckets (for example "10,000+"), so the median is a bucket value, not an exact count. "Added" is the listing approval date, so an older plugin that added MCP this year counts as "before 2025". Premium plugins sold outside WordPress.org, and MCP servers that run on your computer instead of the site, are not included. A mention of MCP does not prove a plugin implements it well, or at all.
• Reproduce it: request https://api.wordpress.org/plugins/info/1.2/?action=query_plugins&request[search]=mcp&request[per_page]=250 and page through the results.

Three ways to connect an AI agent to WordPress

Which route you use depends on where your site is hosted and who wrote the server code. The table compares the three, using only what each provider says on its own pages.

Two details are easy to miss. First, WordPress.com's position changed during the year. Its October 2025 launch post said access was read-only and limited to paid plans. Its developer documentation, updated 22 October 2026, now says it "works on every WordPress.com site, free or paid", and lets you choose between "Full access", which "turns on every Read and Write tool", and "Read only". Second, the adapter's site-owner guide states that the web versions of Claude and ChatGPT "cannot connect to MCP Adapter on their own today", because they sign in through OAuth and WordPress has no OAuth server. Use a desktop client, or a plugin that adds OAuth.

Some third-party options are serious products. The MainWP MCP server, for example, runs on your computer and talks to a MainWP dashboard that manages many sites; its README says deleting a site, plugin or theme "shows you a preview first and runs only after you say yes", and it offers a safe mode that blocks those operations. Read any third-party server's permission model with the same care before you connect it to a live site.

How to set up the MCP Adapter on a self-hosted site

Setup takes about ten minutes: install the plugin, create an Application Password for a limited user, add the site to your AI client, and test with one prompt. These steps follow the adapter's own site-owner guide. Do this on a staging copy first. If you do not have one, our guide to creating a WordPress staging site explains how.

Before you start

• WordPress 6.9 or newer. The current release is 7.1.4, a security release from 28 October 2026, so update first.
• HTTPS on the site. WordPress only offers Application Passwords over HTTPS, except on local development sites.
• Node.js on your computer for most desktop clients, because the connection runs through a small helper started with npx.

Step 1: Install and activate the plugin

In wp-admin, go to Plugins, Add New, and search for "MCP Adapter" by WordPress.org. Or use WP-CLI:

wp core version            # needs 6.9 or newer
wp plugin install mcp-adapter --activate
wp plugin list --name=mcp-adapter --fields=name,status,version

Install it from WordPress.org rather than from the GitHub source code. The guide notes that a source checkout is missing files it needs, and 0.7.0 deprecated bundling the adapter inside other plugins as a library.

Step 2: Create a dedicated user and an Application Password

1. Create a new user for the agent with the lowest role that can do the job, for example Editor rather than Administrator. The guide's advice is that a separate user "keeps its actions easy to tell apart and easy to switch off."
2. Edit that user, scroll to Application Passwords, name it after the device ("Claude on office laptop"), and click Add New Application Password.
3. Copy the password. WordPress shows it once.

With WP-CLI, the same thing looks like this:

# a dedicated, limited user for the agent
wp user create ai-agent ai-agent@example.com --role=editor

# an application password for one client on one device
wp user application-password create ai-agent "Claude on office laptop" --porcelain

# later: see when each password was last used, and revoke one
wp user application-password list ai-agent --fields=uuid,name,last_used
wp user application-password delete ai-agent <uuid>

Step 3: Add the site to your AI client

For Claude Desktop (Settings, Developer, Edit Config), Cursor (~/.cursor/mcp.json) and similar apps, add this entry with your own values:

{
  "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": "ai-agent",
        "WP_API_PASSWORD": "xxxx xxxx xxxx xxxx xxxx xxxx"
      }
    }
  }
}

VS Code uses the same entry inside a servers object in .vscode/mcp.json instead of mcpServers. Restart the app after saving, because most clients only read this file at startup.

Clients that accept a URL and a header, such as Claude Code, can skip the helper:

# build the header value: username:application-password, base64, one line
printf 'ai-agent: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"

For a site on your own computer with WP-CLI, the client can start the adapter directly over STDIO, with no password:

{
  "mcpServers": {
    "local-wordpress": {
      "command": "wp",
      "args": [
        "--path=/path/to/wordpress",
        "mcp-adapter",
        "serve",
        "--server=mcp-adapter-default-server",
        "--user=ai-agent"
      ]
    }
  }
}

Step 4: Test the connection

Ask the assistant: "List the WordPress abilities you can use on my site." Either a list or an empty list means the connection works. An empty list is normal on a fresh site; the next section fixes it.

If it fails

The 401 problem is common on Apache hosts where the .htaccess file was replaced. The same header handling affects other REST API tools, which our WordPress REST API guide covers in more depth.

Give the agent something to do: register an ability

An agent can only call abilities that a plugin registers and marks public, so the real work of WordPress MCP is writing good abilities. This is where the 0% benchmark comes from, and where a developer adds value. Below is a minimal, read-only ability in a small plugin. It follows the signature in the WordPress 6.9 developer note: register a category on wp_abilities_api_categories_init, register the ability on wp_abilities_api_init, and give it schemas, an execute callback and a permission callback.

<?php
/**
 * Plugin Name: Example Read-Only Abilities
 * Description: Exposes one read-only ability to MCP clients.
 * Requires at least: 6.9
 */

add_action( 'wp_abilities_api_categories_init', function () {
	wp_register_ability_category(
		'example-reporting',
		array(
			'label'       => __( 'Reporting', 'example' ),
			'description' => __( 'Read-only reports about site content.', 'example' ),
		)
	);
} );

add_action( 'wp_abilities_api_init', function () {
	wp_register_ability(
		'example/count-published',
		array(
			'label'               => __( 'Count published content', 'example' ),
			'description'         => __( 'Returns how many items of a post type are published.', 'example' ),
			'category'            => 'example-reporting',
			'input_schema'        => array(
				'type'        => 'string',
				'description' => __( 'Post type to count, for example post or page.', 'example' ),
				'default'     => 'post',
			),
			'output_schema'       => array(
				'type'        => 'integer',
				'description' => __( 'Number of published items.', 'example' ),
			),
			'execute_callback'    => function ( $input ) {
				$type = post_type_exists( $input ?? 'post' ) ? ( $input ?? 'post' ) : 'post';
				return (int) wp_count_posts( $type )->publish;
			},
			'permission_callback' => function () {
				return current_user_can( 'edit_posts' );
			},
			'meta'                => array(
				'mcp'         => array( 'public' => true ),
				'annotations' => array(
					'readonly'    => true,
					'destructive' => false,
					'idempotent'  => true,
				),
			),
		)
	);
} );

What each part does:

• permission_callback runs before anything executes. Here the user must be able to edit_posts. Never use __return_true on anything that changes data; the developer blog warns against exactly that.
• meta.mcp.public exposes the ability to MCP only. Since adapter 0.6.0, setting the broader meta.public to true exposes it to MCP as well, unless meta.mcp.public is set to false. The adapter's docs note that core starts applying meta.public to the REST API in WordPress 7.1.
• annotations tell the client the tool is read-only and not destructive. The adapter converts readonly to MCP's readOnlyHint. Clients use these hints when deciding whether to ask you before running a tool. They are hints, not enforcement; the permission callback is the enforcement.

Check that it registered, then ask your assistant to "count my published pages":

wp mcp-adapter list
wp eval 'var_dump( wp_has_ability( "example/count-published" ) );'

A good first set of abilities for a business site is read-only: draft counts, broken-link reports, plugin update status, recent form entries without personal data. Add write abilities one at a time, each with its own narrow permission check, after the read-only ones have run cleanly for a while. If you want this built for your own plugins or workflows, our guide to building a custom WordPress plugin covers the plugin side.

Is WordPress MCP safe?

It is as safe as the user account and the abilities you expose: the agent acts with that user's role, so a narrow role and read-only abilities keep the risk small, while an Administrator account with broad write tools makes the agent as dangerous as any admin login. Three facts from the primary sources frame this:

• The adapter's guide says "every action runs with that user's role and permissions." Permission checks run per ability and, separately, per server; by default a server requires a logged-in user (is_user_logged_in()).
• Exposure is opt-in. Abilities are private unless a plugin marks them public. But any plugin you install can mark its own abilities public, so the plugin list is now part of your agent's reach.
• The adapter itself needed a security fix. Version 0.7.1 and the 0.6.2 backport, both published 16 October 2026, cap stored session data at 4 KiB after a researcher found oversized data could cause "repeated database failures and excessive logging". Keep it updated like any other plugin.

A security checklist before you connect a live site

1. Use a dedicated user for each agent, never your own admin account.
2. Give it the lowest role that works. Editor or a custom role, not Administrator, unless you have a specific reason.
3. One Application Password per client and device, so you can revoke one without breaking the others. Users, Profile shows when each was last used.
4. Never paste the password into a chat. The proposal of 28 October itself says users should not be pasting Application Passwords "in plaintext to their agent". Put it in the client's config file.
5. Start read-only. The developer blog recommends read-only abilities "for public MCP endpoints" and suggests beginning with "a few non-destructive, read-only abilities".
6. Audit which plugins register public abilities. Run wp mcp-adapter list and ask the agent to list its abilities after every plugin install.
7. Log what the agent does. The adapter supports custom error and observability handlers; at minimum, keep the server access log and an activity log plugin.
8. Test on staging, back up live. The guide is blunt: "Abilities change your live site the same way an action in wp-admin does." Our WordPress security guide covers backups, roles and logging in more detail.
9. Treat third-party MCP plugins like any plugin with admin reach: check the author, install count, update history and support threads before installing.

The risk to watch is not a rogue AI. It is the familiar one: a powerful credential stored on a laptop, or a poorly written plugin that exposes more than it should. The 28 October core release, 7.1.4, lists more than ten security fixes, including a weakness in the upgrade process that can lead to remote code execution. That is a reminder that the base site has to be current before you add a new way into it.

How MCP relates to the WordPress 7.0 AI Client

MCP and the AI Client point in opposite directions: MCP lets an outside agent work on your site, while the AI Client lets your site call an AI model. Both use the Abilities API, which is why they are often mixed up.

The AI Client's entry point is wp_ai_client_prompt(), which returns a WP_AI_Client_Prompt_Builder. Site owners choose providers in Settings, Connectors, which ships with Anthropic, Google and OpenAI as presets. A plugin call looks like this, from the core dev note:

$text = wp_ai_client_prompt( 'Summarize the benefits of caching in WordPress.' )
	->using_temperature( 0.7 )
	->generate_text();

if ( is_wp_error( $text ) ) {
	return; // no provider configured, or the request failed
}

Nothing calls a model until an administrator adds a provider key and a plugin uses the client. A fresh WordPress 7.0 site does not send content anywhere by itself.

What this news does not mean

What to do now, by role

Most business sites need to do nothing yet beyond keeping WordPress current; the people who should act now are those already connecting agents and those who build plugins.

Site owners

• Update to WordPress 7.1.4 now, and plan the 7.2 update after 8 December using our WordPress 7.2 release guide.
• If anyone on your team has connected an AI tool to the site, find out which plugin, which user and which password it uses. Revoke what you cannot account for.
• If you want to try it, do it on staging, with a dedicated Editor-level user and read-only abilities.

Agencies and site managers

• Add "MCP plugins and Application Passwords" to your monthly maintenance checks: what is installed, which users hold passwords, when each was last used.
• Update the MCP Adapter to 0.7.1 on any site running it, and any plugin bundling an older 0.6.x copy to 0.6.2 or later.
• Watch the 7.2 release candidates (RC1 is scheduled for 17 November) for changes to abilities you rely on.

Plugin developers

• Register your plugin's key actions as abilities with tight permission callbacks and honest annotations. The benchmark finding means sites with good abilities will be the ones agents can use.
• Depend on the canonical adapter with a Requires Plugins: mcp-adapter header instead of bundling it, as the plugin page now recommends.
• Read the 0.7.0 migration guide if you built a custom transport or used the removed validator classes.