WordPress MCP Adapter 0.7 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 and the WordPress.org plugin directory, it is at version 0.7.0 (2 October 2026), 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 based on the v0.7.0 source code. 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, like the one built into InstaWP’s managed WordPress hosting, 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. To see how it compares with the other MCP plugins, read the best WordPress MCP plugins, 21 tested on one live site.

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.7.0, published on 2 October 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, and v0.7.0 carries breaking changes of its own (covered below).

Two of those rows deserve a sentence each.

The adapter is now in the WordPress.org plugin directory. As late as 11 September 2026 the WordPress.org plugin API still returned “Plugin not found” for the mcp-adapter slug. By October it is listed under the WordPress.org author account at v0.7.0 with 40,000+ active installs. Three things change: you can install it from Plugins, Add New, updates arrive through the dashboard like any other plugin, and the Requires Plugins: mcp-adapter dependency header that plugin authors were told to use now resolves. The installation guide covers every route.

Adoption is already substantial. Packagist records 578,905 total installs of wordpress/mcp-adapter, 156,491 in the last month, with 887 stars on the package (6 October 2026). 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:

What changed in v0.7.0, and who it breaks

Version 0.7.0 is the first release since the adapter reached the plugin directory, and it is a protocol release. For most sites running the default server it changes nothing you will see. It matters if you wrote a custom transport or maintain an MCP client:

• Two schema revisions, exactly. The adapter serves MCP 2025-11-25 and 2026-07-28. Clients that ask for 2025-06-18 or 2024-11-05 are still answered, through the 2025-11-25 schema. A client that proposes 2025-03-26 gets 2025-11-25 offered back, because that revision requires JSON-RPC batches and the adapter rejects batches.
• No more silent repairs. Invalid protocol fields used to be dropped or fixed up quietly. They now return an error, so a sloppy client that “worked” on v0.6.1 can start failing.
• Custom transports must delegate to HttpRequestHandler or McpWireOrchestrator rather than handling the wire format themselves.
• New in 2026-07-28: a sessionless server/discover lifecycle, and direct callable tools can ask the client for elicitation input.

SSE streaming is still not implemented in v0.7.0. A GET on the HTTP endpoint still returns 405.

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 five routes. Since the adapter reached the plugin directory, the shortest is one WP-CLI line using the directory slug:

wp plugin install mcp-adapter --activate

The release-URL form the official docs lead with still works, and pulls the latest GitHub release instead:

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”.

In wp-admin, the simplest manual route is now Plugins, Add New, search for “MCP Adapter”, then Install Now and Activate. If you need a specific release, download the ZIP from the releases page and upload it instead:

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 only the three read-only abilities WordPress core registers: core/get-site-info, core/get-user-info and core/get-environment-info. That is what InstaWP engineering saw on a clean sandbox in October 2026. 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 an exception or returns a WP_Error, the adapter logs the failure and denies the request. It fails closed in both v0.6.1 and v0.7.0, so a broken callback locks people out rather than letting everyone in. The failure that does not get logged is a callback that wrongly returns true, so test it with a Subscriber account before you trust it.

If you would rather not write a callback at all, you can raise the default instead. The adapter passes its default capability through a filter, so one line makes the default server administrator-only:

add_filter( 'mcp_adapter_default_transport_permission_user_capability', function () {
    return 'manage_options';
} );

Despite what the code comments say (they still describe the default as is_user_logged_in()), the check in v0.7.0 is current_user_can( 'read' ). In practice the result is the same, which is the point of fixing it.

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.7.0 is the third release in eight weeks, and it breaks custom transports. Before that, v0.6.1 existed 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.

It only just reached the WordPress.org directory

Until October 2026 there was no directory listing, no one-click updates and no working dependency header. That is fixed. The new risk runs the other way: a pre-1.0 plugin with breaking changes in a minor release can now auto-update on every client site at once. Across a fleet, pin the version or turn off auto-updates for it until you have tested each release on staging.

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.

It also means the setup does not travel. STDIO needs WP-CLI on the same machine as each person’s AI client, HTTP needs an application password and session handling per client, and nothing copies an exposure list from staging to production for you.

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.

How Does the MCP Adapter Fit With Other WordPress MCP Plugins?

The adapter is the substrate a lot of the WordPress MCP ecosystem is built on, so it rarely runs alone. InstaWP engineering tested 21 WordPress MCP plugins on the same WordPress 7.1 test site in September and October 2026, and six of them build on the adapter rather than shipping their own server: Enable Abilities for MCP, Agent Abilities for MCP, AtlasMCP, Invizo MCP, The Plus Addons for Elementor and MCP Content Manager Lite.

That makes plugin conflicts the practical thing to check. On that test site, AtlasMCP and Agent Abilities for MCP each switched off the adapter’s default server for the whole site, and MCP Content Manager Lite, while active, refused Application Password logins on every /wp-json/mcp/ route, including the adapter’s. If your client connects but authentication suddenly fails, list the active MCP plugins before you debug the adapter. The full field is compared in best WordPress MCP servers.

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’s managed WordPress hosting, 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 get four token scopes (read, write, delete and admin) that follow the WordPress role, so a contributor’s agent is read only. Safe Mode blocks delete operations and gates the write side of the three tools that can run code or touch the database and files (execute_php, db_query and site_files), and those three ship switched off until an administrator turns them on. Out of the box the agent gets 43 typed tools, against the adapter’s three gateway tools and three read-only core abilities. 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 with breaking changes between minors, it now auto-updates like any directory plugin unless you pin it, 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 the read-capability default, and pin a version rather than letting a pre-1.0 plugin auto-update 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