MCP Adapter for WordPress: Abilities, Transports, and Access Control

MCP Adapter's Place in the WordPress Ability Model

MCP Adapter solves a connection problem rather than supplying a new catalog of AI actions. WordPress code defines capabilities through the Abilities API, while an MCP client speaks the Model Context Protocol. The adapter bridges those two layers so a client can discover eligible WordPress functions and invoke them through a standardized interface.

The intended users are developers building WordPress plugins, themes, or core integrations that should be available to AI agents. A plugin team might expose a narrowly defined operation through the Abilities API and let MCP Adapter handle its MCP representation. This is more specific than installing a general chatbot integration because the project does not decide what the agent is allowed to do. It transports and controls abilities that the surrounding WordPress code already defines.

The README identifies tools, resources, and prompts as MCP representations of WordPress abilities. It also states that the plugin supports HTTP and STDIO transports, multiple servers, custom transports, error handling, observability, and authentication or permission controls. Those details matter for architecture review because an AI integration is not only the callable action. It also includes discovery, transport exposure, failure reporting, and access policy.

This project is not a standalone agent, model client, or replacement for the Abilities API. Its value depends on WordPress code registering abilities that are suitable for remote invocation. If the intended feature exists only as an undocumented PHP function, MCP Adapter has no basis for exposing it.

From WordPress Ability Registration to MCP Invocation

The documented path has two explicit stages. First, a WordPress plugin, theme, or core component provides an ability to the Abilities API. Second, MCP Adapter converts eligible abilities into MCP entities and makes them reachable through a configured server and transport.

Exposure is opt-in. The README says WordPress abilities are private by default. A developer must set `meta.public` or `meta.mcp.public` to `true` before an ability should be exposed. This boundary is important because adding an ability to WordPress does not automatically authorize an external agent to discover or execute it.

The default server exposes three meta-tools named `mcp-adapter/discover-abilities`, `mcp-adapter/get-ability-info`, and `mcp-adapter/execute-ability`. Together, those names describe the client flow: discover available abilities, inspect one, and execute it. The documentation points to the default-server and Creating Abilities guides for the full opt-in model, but the README itself does not publish their request payloads or responses.

The architecture supports more than one MCP server. Each server can have its own transports, abilities, and handlers. That arrangement can separate integrations by purpose or client, although the README does not prescribe a particular partitioning scheme. Organizations should define server ownership and exposure rules rather than putting unrelated abilities into one broad default surface.

The adapter also defines extension interfaces, including `McpTransportInterface`, `McpErrorHandlerInterface`, and `McpObservabilityHandlerInterface`. Based on those names and the linked documentation, protocol integrations and operational behavior are replaceable. The README does not claim that every logging destination, protocol, or monitoring backend is built in.

HTTP, STDIO, and MCP Adapter Client Connections

MCP Adapter supports two documented transport styles. HTTP clients can address the REST route for the default server, while command-line clients can use WP-CLI over STDIO. The documented HTTP endpoint is `/wp-json/mcp/mcp-adapter-default-server`.

The CLI Usage Guide is identified as the source for Claude Desktop and other MCP client configurations, including direct STDIO and HTTP-via-proxy arrangements. However, the README excerpt does not include those configuration bodies, so this review does not invent a command, executable path, proxy setting, or client configuration file. A reader should obtain the exact client entry from that guide before configuring a desktop application.

Transport choice affects the operating boundary. STDIO is presented as a WP-CLI connection, which fits environments capable of launching a command-line process. HTTP fits clients that connect to a network-accessible WordPress endpoint. The project does not claim that either transport is safe by default. Its separate permissions documentation is the relevant control point because a reachable protocol endpoint and an authorized ability are different conditions.

For protocols other than HTTP and STDIO, the architecture exposes `McpTransportInterface`. The Custom Transports guide is the documented next reference. This creates an extension seam, but it also makes a custom transport a development task rather than a configuration switch. The README does not document whether a custom implementation is backward-compatible across all releases.

Installing MCP Adapter and Making a First Real Request

The README does not give a command-line installation procedure for end users. It directs readers to the WordPress plugin page at `https://wordpress.org/plugins/mcp-adapter/`, which is the documented place to obtain the plugin. Installation through WordPress administration is therefore the only end-user path that can be confirmed here; the excerpt provides no `wp plugin install` command that should be substituted.

For a first use, start with an ability that has already been registered through the WordPress Abilities API and deliberately make it public by setting either `meta.public` or `meta.mcp.public` to `true`. Then connect an MCP client using one of the documented methods. For HTTP, point that client at `/wp-json/mcp/mcp-adapter-default-server`. For STDIO, use the exact configuration from the CLI Usage Guide.

The first interaction should use `mcp-adapter/discover-abilities` rather than attempting execution immediately. Inspect the returned ability with `mcp-adapter/get-ability-info`, check its declared permissions and input expectations, and only then call `mcp-adapter/execute-ability`. The README does not provide concrete JSON arguments for these meta-tools, so it would be misleading to publish invented payloads as a working example.

Repository contributors have a separate Node-based toolchain. `package.json` requires Node `>=24.15.0` and npm `>=10.9.4`. The documented PHP test entry point runs the PHPUnit suite through the WordPress test environment:

npm run test:php

That command is relevant to plugin development and verification, not to installing the released plugin on a normal WordPress site. It delegates to `wp-env:test`, runs `cli`, and invokes `vendor/bin/phpunit -c phpunit.xml.dist` inside the plugin directory.

MCP Adapter's Permission and Failure Boundaries

The most consequential limitation is also its most useful design constraint: abilities remain private unless the owner opts into exposure. A developer who expects registration alone to make functionality available to an agent will find that it does not. The public metadata must be changed deliberately, and the resulting ability then passes through discovery and execution paths controlled by the adapter.

MCP Adapter documents two permission layers: per-server transport authentication and per-ability permission checks. Deployments should not treat either layer as optional merely because the default server has discovery tools. The repository description does not provide the exact callback signatures, failure responses, or authorization model for each ability, so those details cannot be inferred from the README.

Error handling is described as pluggable through `McpErrorHandlerInterface`, and observability through `McpObservabilityHandlerInterface`. This means transport and ability failures can be connected to project-specific logging or monitoring. It does not establish which operational events are recorded by default, how sensitive arguments are redacted, or whether errors contain WordPress internals. Those points require review of the Error Handling and Observability guides.

MCP Adapter is the wrong choice when WordPress functionality has not first been modeled as an ability, when an application needs one-off commands but not MCP discovery, or when the WordPress environment cannot expose either HTTP or STDIO safely. It is also unsuitable as a substitute for application-level authorization. A public ability may be discoverable while still requiring an appropriate permission check.

Comparing MCP Adapter with Direct MCP Server Code

A direct alternative is to implement an MCP server alongside a WordPress plugin without using MCP Adapter. In that approach, the plugin team maps its own operations to MCP tools, resources, or prompts and manages transport registration, discovery, execution, errors, and permissions in application code.

MCP Adapter takes a different route. It accepts WordPress's Abilities API as the source model and handles conversion to MCP forms. The documented multi-server model also allows separate transports, abilities, and handlers for each server. This reduces the amount of protocol plumbing a team needs to own when its functions already fit the Abilities API.

Direct server code remains appropriate when operations are not WordPress abilities, when MCP behavior must diverge substantially from the adapter model, or when an existing plugin already has a mature MCP layer. Choosing the adapter creates a dependency on its interfaces, opt-in metadata model, default meta-tools, and release compatibility. Its convenience is also its constraint: capabilities are expressed through the Abilities API rather than an unrelated bespoke schema.

The comparison does not establish a performance difference. Neither the README nor the package metadata reports benchmark results, so claims about lower latency, higher throughput, or reduced resource use would be unsupported.

MCP Adapter Release, Maintenance, and GPL Obligations

The repository is not archived. Its last push was on 2026-10-16. Recent release history includes v0.7.0 on 2026-10-02 and v0.6.1 on 2026-08-13. These dates show recent code and release activity, but they do not establish compatibility guarantees for every WordPress or client configuration.

Upgrade planning has a concrete basis because the repository provides migration guides for v0.7.0, v0.5.0, and v0.3.0. Sites or plugins that customized earlier server, transport, error, or observability behavior should consult the guide for the version they are crossing. The v0.7.0 guide is the most immediate reference for an upgrade from an earlier release, although the README does not list every breaking change.

The package is licensed under `GPL-2.0-or-later`. The `package.json` package build includes `LICENSE.md`, the plugin entry file, `includes`, `vendor`, and `composer.json` in its packaged files. Contributor tooling includes PHP linting, PHPStan, PHPUnit, formatting, and dependency-review workflows. That structure indicates a conventional WordPress plugin distribution with a PHP runtime component and a JavaScript-based development environment.

MCP and related names are identified by the README as trademarks of LF Projects, LLC and are used for informational purposes. That trademark statement is separate from the GPL software license. Teams should review the shipped `LICENSE.md` and `SECURITY.md` when modifying or redistributing the plugin.

Editorial conclusion

WordPress plugin, theme, and core teams should evaluate MCP Adapter when they already define abilities through the Abilities API and need a documented MCP boundary for several clients. Sites that expose actions without a clear permission model, or teams unable to operate WordPress and an MCP transport, should not adopt it yet. Verify first that every intended ability is explicitly public, its permissions fit the deployment, and the selected HTTP or STDIO connection works with the actual client.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. WordPress/mcp-adapter on GitHub