WordPress MCP Adapter Review (2026): Setup, Security, Verdict

The WordPress MCP Adapter is the official WordPress plugin that turns abilities registered through the Abilities API into Model Context Protocol tools, resources and prompts, so AI clients like Claude, Cursor and VS Code can call them. It lives in the WordPress/mcp-adapter repository, it is at version 0.6.1, and it requires WordPress 6.9 or newer. It is a well-engineered connector, not a full development workflow.

This WordPress MCP Adapter review is written against the code as it stands on 11 September 2026. It covers what actually ships today, how you install and expose abilities, the security default most people miss, where the adapter genuinely falls short, and when a hosted WordPress MCP server is the more practical option. If you only read one section, read the security default.

What Is the WordPress MCP Adapter?

The WordPress MCP Adapter is an official WordPress plugin that reads the abilities registered on a site and republishes them over the Model Context Protocol as tools, resources and prompts. An AI client connects to one endpoint, asks what the site can do, reads the schema for the action it wants, and calls it. InstaWP has covered the protocol itself at length, so if you need the concept first, read WordPress MCP and come back. This page is only about the adapter.

Two things get conflated constantly, so separate them before anything else. The Abilities API (introduced here) is the WordPress core registry, added in WordPress 6.9. It defines what a site can do, with typed inputs, typed outputs and a capability-based permission callback per ability. The MCP Adapter sits on top and is the translation layer. The Abilities API decides what exists. The adapter decides what an AI agent is allowed to see and call.

That split matters practically. If an ability is wrong, the adapter faithfully exposes something wrong. InstaWP has seen this pattern in support: teams debug the MCP connection for an hour when the actual fault is a permission callback that returns __return_true.

Where Is the WordPress MCP Adapter Repo, and Which One Is Official?

The official WordPress MCP Adapter lives at github.com/WordPress/mcp-adapter, published under the WordPress GitHub organisation as part of the AI Building Blocks for WordPress initiative. The Composer package is wordpress/mcp-adapter on Packagist. Those two names are the same project. If a search result sends you anywhere else, check it against the table below.

This confuses people because there were three repositories in play during 2025, and two of them are now archived.

That last row is the one that trips up older tutorials. Any guide telling you to install an abilities-api plugin alongside the adapter is out of date. On WordPress 6.9 and later, wp_register_ability() is already there. The archived Automattic/wordpress-mcp plugin, often written as the “WordPress MCP plugin”, was the earlier Automattic experiment and is not the same codebase.

What Version of the MCP Adapter Actually Ships Today?

The current release is v0.6.1, published on 13 August 2026. The project is still pre-1.0. That is not a warning against using it, but it does mean the public API can move between minor versions, and it already has: the repo ships migration guides for v0.3.0 and v0.5.0.

Two of those rows deserve a sentence each, because no other review states them.

The adapter is not in the WordPress.org plugin directory yet. Query the WordPress.org plugin API for the mcp-adapter slug and it returns “Plugin not found”, even though the bundled readme.txt tells you to search for “MCP Adapter” under Plugins, Add New. InstaWP checked this on 11 September 2026. The practical consequence is real: the documented Requires Plugins: mcp-adapter plugin-dependency header only works for plugins hosted on WordPress.org, so if you are building on top of the adapter you cannot rely on WordPress to load it for you. The installation guide says as much.

Adoption is already substantial. Packagist records 448,960 total installs of wordpress/mcp-adapter, 131,357 in the last month, with 887 stars on the package. For a pre-1.0 package that is a healthy signal, and it is a better adoption proxy than GitHub stars because it counts builds rather than bookmarks.

Release history, for anyone deciding whether to pin a version:

Is the MCP Adapter a Plugin or a Library?

Both, and the answer changes what you install. Searches for “WordPress MCP adapter plugin” and “MCP adapter plugin” usually mean the first option below, but plugin authors almost always want the second.

The bundling warning is worth taking seriously. Two plugins each shipping their own copy of the adapter is the classic WordPress conflict, and the adapter ships a Jetpack Autoloader rather than a plain vendor/autoload.php specifically to survive that. The right check inside your own plugin is for the class, not for an autoloader:

add_action( 'plugins_loaded', function () {
    if ( ! class_exists( 'WP\\MCP\\Core\\McpAdapter' ) ) {
        add_action( 'admin_notices', function () {
            echo '<div class="notice notice-error"><p>MCP Adapter must be active.</p></div>';
        } );
        return;
    }

    // Safe to register servers and abilities from here.
} );

There is also a WP_MCP_VERSION constant if you need to gate on a minimum adapter version.

How Do You Install the WordPress MCP Adapter?

There are four routes. The fastest is one WP-CLI line, and it is the one the official docs lead with:

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

If you prefer Composer, because you deploy the whole site as a Composer project:

composer require wordpress/mcp-adapter

For a throwaway local environment, wp-env takes the same release URL in the plugins array of .wp-env.json. And if you only want to look at it, the repo ships a WordPress Playground blueprint, so you can run the adapter in a browser tab without installing anything at all. That is the cheapest way to answer “is this worth my afternoon”.

The manual route, which is what most people do the first time, is downloading the ZIP from the releases page and uploading it.

Take the mcp-adapter.zip release asset. Do not clone the repository and upload that, for the reason in the next paragraph.

In WP Admin, go to Plugins, then Add New, then Upload Plugin, and choose the ZIP.

Activate it once the upload finishes.

It then appears in your plugin list like any other plugin.

Activation registers a default MCP server at /wp-json/mcp/mcp-adapter-default-server and exposes three core adapter abilities:

• mcp-adapter/discover-abilities
• mcp-adapter/get-ability-info
• mcp-adapter/execute-ability

Those three are meta-tools, not your site’s functionality. The design is deliberate and it is the cleverest thing in the adapter: no matter how many abilities a site registers, an AI client’s tools/list response stays at three tool schemas. The agent discovers, inspects, then executes. On a site with sixty abilities that is the difference between a usable context window and a wasted one.

One naming detail that costs people time. The abilities are registered with slashes (mcp-adapter/discover-abilities) but MCP tool names cannot contain a slash, so McpNameSanitizer converts them to hyphens. The tool your client actually calls is mcp-adapter-discover-abilities. If you are debugging a “tool not found” error, that is usually why.

How Do You Expose an Ability to MCP?

This is where a fresh install stops being interesting. Abilities are private by default, so an MCP client connects successfully, lists three meta-tools, calls discover, and finds nothing. That is not a bug. You have to opt each ability in.

meta.mcp.public = true

meta.mcp.public = true

In a real ability registration, that flag sits in the meta array:

wp_register_ability( 'my-plugin/summarise-post', array(
    'label'               => __( 'Summarise a post', 'my-plugin' ),
    'description'         => __( 'Returns a short summary of a published post.', 'my-plugin' ),
    'input_schema'        => array(
        'type'       => 'object',
        'properties' => array(
            'post_id' => array( 'type' => 'integer' ),
        ),
        'required'   => array( 'post_id' ),
    ),
    'execute_callback'    => 'my_plugin_summarise_post',
    'permission_callback' => function () {
        return current_user_can( 'edit_posts' );
    },
    'meta'                => array(
        'mcp' => array(
            'public' => true,
        ),
    ),
) );

Three details the creating-abilities guide spells out and most tutorials skip. meta.public works as a broader alias for meta.mcp.public. An explicit meta.mcp.public = false opts an otherwise public ability back out of MCP specifically, which is the escape hatch when an ability should be public to other consumers but not to agents. And for abilities registered by core or by a plugin you do not control, you hook the wp_register_ability_args filter rather than editing anything.

Once you get past a handful of abilities you have a choice between two server shapes, and the adapter supports running both at once.

Two filters are worth knowing before you go custom. mcp_adapter_create_default_server set to __return_false removes the default server and its three meta-tools entirely. mcp_adapter_default_server_config lets you keep the default server but rename it, swap the error handler, or append one of your own tools alongside the meta-tools. Reaching for the second is usually better than disabling and rebuilding.

How Do You Connect an MCP Client to the Adapter?

The adapter ships two transports, and the choice is really a choice about where your WordPress install lives. People searching for a “WordPress MCP connector” are usually looking for this section.

STDIO transport, for local sites

STDIO runs the MCP server as a WP-CLI subprocess on your own machine. There is no network surface at all, which makes it the right default for plugin development. The adapter adds two commands:

# Serve the default MCP server as a specific WordPress user
wp mcp-adapter serve --server=mcp-adapter-default-server --user=admin

# List every MCP server registered on the site
wp mcp-adapter list --format=json

The --user flag is not optional in practice. Without it the process runs unauthenticated with very limited capabilities, which shows up as an empty tool list rather than an error. Most MCP clients can launch a subprocess directly, so the client config points at the wp binary:

{
  "mcpServers": {
    "wordpress": {
      "command": "wp",
      "args": [
        "--path=/path/to/your/wordpress/site",
        "mcp-adapter",
        "serve",
        "--server=mcp-adapter-default-server",
        "--user=admin"
      ]
    }
  }
}

The limitation is structural rather than technical. STDIO assumes the person using the AI client also owns the machine WordPress runs on. That is fine for one developer on one laptop and awkward the moment a second person, a remote staging site or a CI job needs the same access.

HTTP transport, and its session handshake

HTTP exposes the server at /wp-json/mcp/mcp-adapter-default-server, authenticated with WordPress application passwords over Basic auth, or with your own OAuth layer. Custom servers follow the pattern /wp-json/{namespace}/mcp. HTTPS is required, which is not a suggestion when you are sending an application password on every call.

Here is the part that generates most of the “it connected but nothing works” reports. The HTTP transport implements the MCP session protocol, so every request after initialize must carry an Mcp-Session-Id header returned by that first call. Omit it and you get JSON-RPC error -32600, “Missing Mcp-Session-Id header”.

# 1. Initialize, and read Mcp-Session-Id out of the response headers
curl -s -D - -X POST "https://example.com/wp-json/mcp/mcp-adapter-default-server" \
  --user "username:application_password" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"my-client","version":"1.0.0"}}}'

# 2. Every later request carries the header
curl -s -X POST "https://example.com/wp-json/mcp/mcp-adapter-default-server" \
  --user "username:application_password" \
  -H "Content-Type: application/json" \
  -H "Mcp-Session-Id: <session-id-from-step-1>" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}'

# 3. Clean up when you are done
curl -s -X DELETE "https://example.com/wp-json/mcp/mcp-adapter-default-server" \
  --user "username:application_password" \
  -H "Mcp-Session-Id: <session-id-from-step-1>"

Three consequences worth writing down. Sessions expire after 24 hours of inactivity by default, adjustable with the mcp_adapter_session_inactivity_timeout filter, and an expired session returns “Invalid or expired session” rather than a 401, so it reads like an auth failure when it is not. Server-sent events are not implemented yet: a GET to the endpoint returns 405 Method Not Allowed, so any client that insists on SSE streaming will not connect. And STDIO does not use HTTP sessions at all, so if you see session errors on a WP-CLI setup you are on the wrong transport.

A fourth, duller cause of 404s: the REST API has to work and permalinks must not be set to Plain. wp option get permalink_structure answers that in one line, and the troubleshooting guide lists the rest.

How Secure Is the WordPress MCP Adapter?

The exposure model is correct by design and the default permission is weaker than most people assume. Both of those are true at the same time, and the second one is what InstaWP would flag in a client audit.

The good part first. Nothing is reachable until you mark it public, so the attack surface starts at zero and only grows on purpose. Abilities carry their own permission_callback, which runs on every call, so an agent is bounded by WordPress capabilities rather than by prompt instructions. That is a far better posture than a plugin that exposes the whole REST API behind one token.

The fix is a few lines. A transport permission callback can return a boolean, or a WP_Error if you want the client to see why it was refused:

function (): WP_Error|bool {
    if ( ! is_user_logged_in() ) {
        return new WP_Error( 'not_logged_in', 'Please log in', array( 'status' => 401 ) );
    }

    if ( ! current_user_can( 'manage_options' ) ) {
        return new WP_Error( 'insufficient_permissions', 'Admin access required', array( 'status' => 403 ) );
    }

    return true;
}

One behaviour to know about: if your callback throws, the adapter logs the failure and falls back to is_user_logged_in(). It fails to a lower bar rather than closed. Test the callback rather than assuming it runs.

The practical checklist InstaWP would apply before pointing an agent at a production site:

• Create a dedicated WordPress user for MCP access with the narrowest role that works, and generate the application password against that user, not your own admin account.
• Never use __return_true as a permission_callback on an ability that writes, deletes or changes settings.
• Prefer read-only abilities on anything reachable over HTTP. Keep write abilities on STDIO or behind an admin-only custom server.
• Set a transport permission callback explicitly, even when the answer is “logged in is fine”. Writing it down is what stops the default drifting past you.
• Enforce HTTPS. Application passwords travel as Basic auth, which is base64, not encryption.
• Swap in an observability handler via McpObservabilityHandlerInterface and actually read the log. An agent calling something unexpected is only visible if you are recording calls.
• Rotate the application password when someone leaves the project. There is no per-client revocation, so the password is the whole key.

Security issues in the adapter itself go through the WordPress HackerOne programme, which is the same disclosure route as core. That is a point in its favour over a random MCP plugin.

WordPress 7 and MCP: What Actually Changed

Plenty of 2025 coverage promised that the Abilities API would “land in WordPress 7.0“. That is not what happened, and the correction matters because it changes your minimum version.

The Abilities API shipped in WordPress 6.9, not 7.0. The abilities-api repository has since been archived because there is nothing left to ship separately. By September 2026 the current WordPress branch is 7.1, with 7.0.4 still being served for auto-updates, and the MCP Adapter plugin header declares “Tested up to: 7.1”.

So the practical answer on WordPress 7 MCP support is that you do not need WordPress 7 at all. You need 6.9. If you are on WordPress 7.0 or 7.1 you are comfortably inside the tested range, and if you are below 6.9 the upgrade is the prerequisite, not the adapter.

The forward-looking claim that does hold up is the architectural one. Because abilities are registered in core, every plugin and theme that registers one becomes callable by an AI agent without bundling an SDK, and the adapter is the bridge that stays stable while the MCP specification itself moves. The WordPress developer blog describes that adapter-and-bridge shape as the deliberate long-term approach, which is the honest reason to build against it rather than against a vendor plugin.

Where the WordPress MCP Adapter Falls Short

None of these are reasons to avoid the adapter. They are the things you should know before you plan a quarter around it.

It is still pre-1.0, and it has broken a release

v0.6.1 exists because v0.6.0 shipped a broken production ZIP. The release build carried a Jetpack Autoloader class map listing test-only global classes, including WP_CLI and WP_CLI_Command, mapped to files under tests/phpunit/ that the ZIP excludes. Any plugin calling class_exists( 'WP_CLI' ) on a normal web request could trigger an uncaught fatal error. The v0.6.1 release notes say so plainly, and installs built from source or required through Composer were unaffected.

InstaWP reads that two ways. The disclosure was fast, specific and honest, which is a good sign about the maintainers. It is also a fair warning that a pre-1.0 release ZIP is not the thing to auto-update on twelve client sites at once.

No SSE streaming yet

A GET on the HTTP endpoint returns 405 Method Not Allowed because server-sent events are not implemented. Clients that require SSE rather than plain request and response will not connect over HTTP today.

Not in the WordPress.org directory

It is not installable from the Plugins, Add New search, there is no one-click update path, and the documented Requires Plugins: mcp-adapter dependency header does not resolve. For a single site that is a minor annoyance. Across a fleet it means you own the update mechanism.

Exposure configuration becomes real work at scale

The default-deny model is correct and it is also a per-site decision multiplied by every site you run. You decide which abilities are public, keep that parity between staging and production by hand, and separate read-only audits from anything that writes. On one local install this is ten minutes. Across thirty client sites it is configuration drift waiting to happen, and drift in an exposure list is not the kind you notice until an agent does something surprising.

Also, it comes with certain limitations:

• Not suitable for distributed teams
• Requires local CLI alignment
• Harder to replicate across remote staging
• No built in environment scaling

It does not manage environments, which is the gap that matters

The adapter is excellent as a command layer. It is genuinely good at environment audits, compatibility checks, structured diagnostics, controlled admin operations and plugin-specific reporting, because abilities are typed and permission-gated so tool calls behave deterministically instead of being improvised from a prompt.

What it does not do, by design:

• Environment creation
• Cloning for bug reproduction
• Resetting to known good state
• Multi version compatibility matrices
• Snapshot based experimentation

That is not a criticism of the project. It was built to solve the protocol problem and it solves it. But if an agent is going to write to a WordPress site, someone has to answer “what happens when it gets it wrong”, and the adapter does not answer that question. Safe iteration needs spin up, test, snapshot, reset, repeat. The adapter gives you the test step.

Hosts are shipping it, mostly read-only

Worth knowing where the wider market is. Pressable shipped a WordPress MCP Adapter integration as a developer preview on 18 February 2026, toggled from MyPressable under Tools, WordPress MCP. Their own changelog states “the current version is limited to read-only interactions and does not support active site management or file modification”. So the managed-host route to the official adapter exists, and as of that release it reads but does not write.

When a Hosted WordPress MCP Server Is a Better Fit

The WordPress MCP adapter is a protocol layer you add to an existing WordPress install. A hosted built-in WordPress MCP server is part of the platform, so the setup work the adapter leaves to you is already done.

On InstaWP that is a single toggle per site, which installs the plugin, generates a scoped token and hands back a connection URL with the token embedded. No JSON configuration, no application password to create, no proxy.

The security model is different in shape rather than in strictness. Instead of writing a transport permission callback, you pick token scopes, and the tools that can run arbitrary code sit behind a separate Safe Mode switch that is off until an administrator turns it on. Revocation is turning the toggle off, which kills the connection URL without visiting each client. The WordPress MCP page has the full scope list.

The more important difference for agencies is not the toggle. It is what sits underneath it. AI agents make mistakes, and the question that decides whether you can let one near a client site is how cheaply you can undo one. WordPress staging sites that spin up in seconds, snapshots taken before an agent runs, and cloning that reproduces a client-specific bug without touching the original are the parts the adapter deliberately leaves out.

Watch it in action.

Neither model makes the other wrong. If you are writing a plugin and you want AI clients to discover and execute your plugin’s abilities, the official adapter is the correct thing to build against, and it is what other people will expect you to have used.

If you are running MCP across many sites and you want the environment lifecycle rather than the protocol exercise, a hosted server gets you there sooner. Several teams run both: the adapter in plugin development, a hosted server for client work. InstaWP has compared the realistic options side by side in best WordPress MCP servers if you are still choosing.

MCP Adapter vs a Hosted WordPress MCP Server

If your answer is “I want to expose my own plugin’s functionality to AI agents”, the adapter wins that row outright and nothing hosted replaces it. If your answer is “I want AI to safely operate sites I already run”, the environment row is the one that decides it.

Verdict: Should You Use the WordPress MCP Adapter?

Yes, if you are a plugin developer. The WordPress MCP Adapter is the official, correctly-designed way to make your plugin callable by AI agents, it is backed by the WordPress AI Team, security reports go through the WordPress HackerOne programme, and the discover-inspect-execute model is genuinely better engineering than dumping fifty tool schemas into a context window. Build against it.

With caveats, if you run client sites. It is pre-1.0, it is not in the plugin directory so you own updates, exposure configuration multiplies per site, and the default transport permission is any logged-in user. None of that is disqualifying. All of it is work you should cost before you promise an agentic workflow to a client.

The one-line summary has not changed since the first version of this review, only the evidence behind it has got sharper: the adapter makes WordPress AI-capable, and something else has to make it AI-operational.

Conclusion

The WordPress MCP Adapter is the right protocol layer and the Abilities API underneath it is now core infrastructure, so this is not a bet on a trend. Start with STDIO locally, keep your permission_callback disciplined, set a transport permission callback explicitly rather than inheriting is_user_logged_in(), and pin a version rather than auto-updating a pre-1.0 release ZIP across a fleet.

What the adapter will not give you is the environment lifecycle that makes AI automation safe to repeat: instant staging, a snapshot before the agent runs, and a reset path when something unexpected happens. That has to come from somewhere, and deciding where is the actual architectural choice, not which MCP server you install.

Pricing for production sites is on the InstaWP pricing page, and the agency-side workflow is covered in WordPress MCP for agencies.

Frequently Asked Questions