WordPress MCP Adapter Explained: What It Is, What It Exposes, and Your Options

The WordPress MCP Adapter is a plugin that transforms your WordPress site into an MCP server. It enables an AI client to discover and utilize the capabilities registered on your site by both the WordPress core and various plugins. As outlined in the project’s README, it is referred to as “the official WordPress package for MCP integration”. Starting from version 0.7.0, released on 2nd October 2026, it can be installed directly from the WordPress.org plugin repository.

In practical terms, the Adapter comes equipped with its own AI functionalities and content tools. What it reveals to AI clients is anything marked public by the WordPress core, plugins, or custom site code, which may exceed your expectations. For instance, on a WordPress 7.1.2 site with a single fields plugin activated, the discovery tool highlighted 51 capabilities, including five that permanently delete items.

This guide elaborates on the current state of the Adapter, the fate of Automattic’s original project, the abilities exposed on a functioning site, who can connect, methods to restrict the display, and available options. If you are unfamiliar with MCP, please review this beginner’s guide to MCP in WordPress first, and then return here.

Understanding the WordPress MCP Adapter and Automattic’s WordPress MCP

MCP, or Model Context Protocol, is an open standard that allows AI applications to access external tools via a unified interface. The Adapter serves as WordPress’s server-side implementation, summarised in its directory FAQ as: “MCP Adapter operates as the server and transport layer. It does not provide any AI features itself.” You can find it published on WordPress.org as part of the AI Building Blocks for WordPress initiative.

The functionalities available stem from the Abilities API, which was integrated into WordPress core from version 6.9. An ability is defined as a named capability that specifies typed input and output, optionally includes a permission check, and contains the executable code. The core code registers several abilities, with additional ones from plugins, and the Adapter converts the public abilities into MCP tools, resources, and prompts.

So, is this the same as Automattic’s WordPress MCP? The GitHub repository for the earlier Automattic project is now archived, and its README clearly states: “This repository is deprecated and archived. It is no longer maintained and is not the recommended method for adding MCP support to WordPress.” The README highlights the MCP Adapter as “the canonical plugin and Composer package for MCP integration in WordPress” and directs readers to the WordPress.com MCP documentation for the latest setup guidance.

Installing the Adapter is straightforward: go to Plugins → Add New, search for “MCP Adapter,” install it, and activate. It requires WordPress version 6.9 or above and PHP version 7.4 or higher. Once activated, a new entry for the MCP Adapter will appear in the admin menu, and the MCP Adapter row in the Plugins screen will have a Settings link:

How the Adapter Functions Explained Simply

By default, all abilities on the Adapter’s server are private, meaning they remain unseen by MCP clients. An ability becomes accessible only when marked public, using either a general public flag or a specific MCP flag (the latter takes precedence if both are set). The directory FAQ summarises the principle in four words: “exposure is opt-in.”

In this context, the AI does not receive the abilities themselves but is granted access to three: mcp-adapter-discover-abilities lists what is public, mcp-adapter-get-ability-info retrieves detailed schema information for an ability, and mcp-adapter-execute-ability runs an ability. On the measured site, tools/list offered these three entries while 51 remained hidden. The AI can discover and inspect these abilities but will always see only three schemas regardless of how many abilities are actually available.

To illustrate the flow:

server flow: hidden unless public; public abilities are listed by discover; a permission check runs or denies them.” class=”wp-image-119403″/>

An important additional step involves permissions: before an exposed ability executes, the Adapter checks its permission callback against the WordPress user who is signed in. As stated in the FAQ, “permission checks always run against the current user before anything is executed.”

Capabilities Exposed on a Live WordPress 7.1.2 Site

On a WordPress 7.1.2 site running MCP Adapter version 0.7.0 and Secure Custom Fields version 6.9.5 (as of 5th October 2026), while signed in as an administrator over HTTP, the discovery tool highlighted 51 abilities: three from WordPress core, 48 from Secure Custom Fields, and none from other sources.

The core three abilities are core/get-site-info, core/get-user-info and core/get-environment-info, which WordPress marks as public in its code. Two of these require the manage_options capability, meaning they are accessible only by administrators on a standard site; core/get-user-info can be accessed by any signed-in user to view their profile.

The remaining 48 abilities are public because Secure Custom Fields designates them as such: its code tags the MCP public flag for the capabilities it registers. This set encompasses the plugin’s structures, including field groups, fields, post types, taxonomies, and options pages, allowing for operations ranging from listing and creating to importing, deleting, and restoring. Notably, five of them are permanent deletions; one self-describes as: “Permanently deletes an instance of SCF field group. This action cannot be undone.”

It is crucial to note that none of the 51 abilities pertain to reading or editing posts, pages, media, or comments. The Adapter effectively acts as a gateway; it’s the responsibility of WordPress core and its plugins to determine what lies beyond it.

Who Can Use It: Credentials, Roles, and an Editor’s Perspective

Without appropriate credentials, access is denied: attempting to call the endpoint without authentication results in a 401 error with the message “Sorry, you are not allowed to do that.” With credentials, the default HTTP transport requires only a signed-in user possessing the read capability, though this requirement can be modified through a filter.

When signed in as an Editor (using that user’s specific application password on 5th October 2026), the discovery tool provided the same 51 abilities visible to the administrator. By implementing the filter mentioned in the subsequent section and making one small custom ability public, the discovery then revealed 19 read-only entries, and each of these 19 were called as that Editor. Of these, only two could run: the Editor’s profile via core/get-user-info and the previously mentioned custom ability. The remaining 17 returned “Permission denied,” including the core site-info and environment-info abilities as well as all Secure Custom Fields listing, retrieval, and export options.

Connecting via Two Methods: HTTP and WP-CLI

Connections can be made over HTTP to the server located at /wp-json/mcp/mcp-adapter-default-server. Clients authenticate as WordPress users, typically using an application password, which can be created under Users → Profile → Application Passwords. By default, WordPress offers application passwords only on HTTPS sites and in local environments; they cannot be employed for traditional logins and can be revoked from the same menu. An example form from the measured site:

For clients relying on STDIO to connect remotely, the @automattic/mcp-wordpress-remote proxy can be utilised. This proxy operates on your machine, converting STDIO traffic from the client into HTTP requests validated using the same application passwords. Pre-configured setups for Claude Desktop, Cursor, Claude Code, and VS Code can be found on the WordPress developer blog’s tutorial; this covers client configurations, although it does not detail installation steps.

On a local installation, or any server where WP-CLI is available, the same server can communicate via STDIO, incorporating HTTP and application password components:

wp mcp-adapter serve --user=admin --server=mcp-adapter-default-server

The AI then operates as the specified user referenced by --user, with exactly that user’s capabilities. In a scripted session directed to that server on the measured site (5th October 2026), tools/list returned the same three tools and successfully executed one ability.

How to Limit Exposure

Two minor adjustments facilitate most of this task.

The first lever is the account. The security recommendations in the developer blog advise setting up a dedicated user with restricted capabilities for MCP access, and ensuring that read-only abilities are used for HTTP endpoints exposed on the internet. The Editor account mentioned earlier could only execute 2 out of the 19 read-only abilities it referenced.

The second lever is a filter that prevents exposure of unwanted abilities. The Adapter’s documentation outlines this mechanism: an explicit meta.mcp.public set to false effectively opts an otherwise public ability out from MCP. On the measured site, this essential plugin concealed all Secure Custom Fields abilities that are not read-only:

/**
 * Plugin Name: Limit MCP Abilities
 * Description: Keeps Secure Custom Fields’ read-only abilities available to MCP clients but hides those that write or delete.
 */
add_filter( 'wp_register_ability_args', function ( $args, $ability_name ) {
    if ( 0 === strpos( $ability_name, 'scf/' ) && empty( $args['meta']['annotations']['readonly'] ) ) {
        $args['meta']['mcp']['public'] = false;
    }
    return $args;
}, 10, 2 );

Save this as wp-content/mu-plugins/limit-mcp-abilities.php, ensuring the file begins with an opening line.

Comparing observations as of 5th October 2026: when the site had its single small custom ability also public, the discovery returned 52 abilities; with the filter applied, the count dropped to 19 (3 core abilities, 15 read-only abilities from Secure Custom Fields plus that custom ability), with no deletion abilities present. A direct attempt to access a deletion capability yielded Ability "scf/delete-field-group" is not exposed via MCP (mcp.public!=true).

Does this trimmed list remain effective with a real AI? On 5th October 2026, Claude Code version 2.1.289, connected over HTTP using an administrator’s application password and accessed solely through MCP tools, was queried: “Which abilities can you access on this WordPress site, and is any of them able to change or delete something? Please do not make any changes.” The response initiated with:

“I found 19 abilities on this site, and none can perform write or delete operations. Every one merely lists, retrieves, or exports information. I exclusively utilized the discovery and info tools, without executing any ability.”

It identified the Secure Custom Fields entries as providing “a list, get and export capability for each” post type, taxonomy, UI options page, field group, and field, noting that some responses could contain sensitive details, such as the administrator’s email address. Take heed of its assessment, which may include caveats: it examined the metadata of only a selected number of abilities, relied on the “names and descriptions” for others, and mentioned that two of the Secure Custom Fields schemas were “too lengthy for me to process in this session.” It also indicated that the “readonly” and “destructive” labels are determined by the plugins themselves, as the filter above trusts the readonly designation.

Anything within the AI’s reach can influence its operation: comments, form entries, and imported materials can all hide instructions. Prompt injection is listed as entry LLM01 in OWASP’s Top 10 for LLM applications, including indirect instances that may appear within external content such as websites or files. Maintaining a read-only list while employing a low-privilege MCP user adheres to OWASP’s own least-privilege recommendations for your site.

PRO TIP: A plugin update can introduce public abilities without notification, just like how Secure Custom Fields operates. After updates, re-run discovery, and remember that the filter above only applies to the plugins it specifies.

Significant Limitations

• It is pre-1.0 software. The 0.7.0 release notes outline potential breaking changes, particularly for any extensions to the Adapter, and specify that this release deprecates its bundling as a Composer library: “Instead, install the plugin.” It adds compatibility for MCP as of 28th July 2026, supporting clients requesting version 18th June 2025.
• There are no personal screens. Public abilities and filtering confirmations exist solely within the code; HTTP credentials are handled in the Application Passwords section of WordPress. If you have PHP in your toolkit, the next area will be beneficial.
• Ability schemas can be extensive. The four ability-info text results from Secure Custom Fields measured on 5th October 2026 ranged from 85,467 to 122,584 characters each, while the core site-info ability returned just 1,651 characters. Detailed plugins may impose additional demands on the AI, reinforcing the benefit of a concise public list.

Available Options for Pre-made Tools

The Adapter serves as a fundamental building block: if your aim is to have an AI assist in managing your site, an additional component is required. Here are three options.

1. Build on the Adapter. Register your own abilities (suitable for developers) or install plugins that register their abilities, ensuring to maintain the public list as narrow as shown above. This is ideal when you want a tailor-made toolset.

2. Use the integrated MCP server from WordPress.com. WordPress.com features an integrated MCP server on all paid plans (free sites access it for the first 30 days post-creation), and self-hosted sites linked via Jetpack using a Jetpack AI or Jetpack Complete plan also use the same server. Authentication is conducted through OAuth 2.1 via the browser, thus eliminating the need to manage application passwords. This is most suitable if your sites are already hosted on or connected with WordPress.com.

3. Install a plugin that provides its own tools and interfaces. Easy MCP AI is one option: available for free , it offers over 280 tools covering content, media, WooCommerce, SEO fields, and analytics, supporting connections via OAuth 2.1 or API tokens, with per-ability controls under Easy MCP AI → Tools → Abilities (starting from version 2.0.1 on WordPress 6.9+). It includes an audit log that tracks every MCP tool invocation. Easy MCP AI is developed by Themeisle, the creators of this blog. This is optimal if you prefer graphical interfaces over coding.

For more options, server-plugins/">the ThemeIsle roundup of WordPress MCP server plugins reviews available choices, while a detailed installation guide for a plugin can be found through this guide on connecting AI assistants to WordPress.

Closing Thoughts

• The WordPress MCP Adapter is the officially sanctioned method from WordPress.org for exposing a site’s capabilities as MCP tools; Automattic's previous project is archived and redirects to it.
• The exposed capabilities comprise whatever is marked public by core and plugins: on the measured site, there are 51 abilities, including five that result in permanent deletion, with none associated with posts.
• Before an ability is executed, its own permission check determines accessibility: an Editor received “Permission Denied” on 17 out of 19 read-only abilities.
• With one small custom ability also publicly accessible, a single filter reduced the visible list from 52 to 19 read-only abilities, with Claude Code reporting that none could perform changes or deletions; a low-role user thus constrains execution.

To get started, install the plugin, use the discovery tool to review what is public on your site, and then determine how limited you wish the listing to be. Have you connected an AI client to your WordPress site yet, and what method did you pursue? Share your experiences in the comments section below!

FREE GUIDE

4 Essential Steps to Speed Up Your WordPress Website

Follow the simple instructions in our 4-part mini series and reduce your loading times by 50-80%.