WordPress MCP Server: What Is Maintained, What Is Archived

A WordPress MCP server does not, by itself, give an AI assistant access to anything. It is a translation layer: it takes capabilities that WordPress has already registered and republishes them in a format an AI client understands. That distinction is the single most useful thing to understand before you install one, and it is the thing almost every list of “best WordPress MCP servers” leaves out.

This page is a comparison of the options that exist, what state each one is in, and where each one is genuinely weak. Every figure carries the date it was captured, following the standard we hold every page to. WPNeon does not operate a test rig and has not benchmarked these packages; what follows is built from repositories, changelogs, the WordPress.org plugin directory, Make WordPress posts and vendor documentation, plus a short section of operational notes drawn from this site’s own MCP connection, which is labelled as such.

What a WordPress MCP server actually is

The Model Context Protocol is a specification for how an AI application discovers and calls tools on an external system. An MCP client — Claude Desktop, Claude Code, Cursor, ChatGPT or something you built — speaks the protocol and knows nothing about WordPress. An MCP server sits on the other side and answers two questions: what can I do here, and please do this one thing.

A WordPress MCP server is the implementation of that server half. There are three architectural approaches in the wild, and they behave very differently:

• In-WordPress, ability-backed. A PHP package runs inside your install, reads the abilities registry, and publishes each public ability as an MCP tool. This is what WordPress/mcp-adapter does.
• In-WordPress, self-defined tools. A plugin ships its own hand-written tool list and its own endpoints, independent of any core registry. This is what Automattic’s wordpress-mcp did before it was archived.
• External proxy over REST. A Node process runs on your machine or a server, authenticates to the WordPress REST API with an application password, and presents REST operations as MCP tools. This is what InstaWP’s mcp-wp does.

The first approach is the direction the WordPress project has committed to. The developer blog post introducing the adapter, published 4 February 2026 and written by Jonathan Bossenger, describes the adapter-and-bridge pattern as the intended long-term approach precisely because it survives the protocol changing underneath it.

The layer most round-ups skip: the Abilities API

The Abilities API landed in WordPress 6.9. According to the Make WordPress Core announcement of 10 November 2025, it ships three things: a PHP API for registering and executing abilities, optional REST endpoints under the wp-abilities/v1 namespace, and hooks for integrating with the registry.

An ability is a named unit of functionality with declared inputs, declared outputs, an execution callback and — the part that matters here — a permission_callback. When you register one with wp_register_ability(), you are describing both what it does and who is allowed to do it.

The MCP adapter then exposes abilities that are marked public as MCP tools, resources and prompts. It adds no capabilities of its own. If nothing in your install registers an ability, an AI client connected through the adapter can see nothing and do nothing, however the transport is configured. This is why “install an MCP server and your AI can manage your site” is a misleading description of how the official path works.

WordPress has continued down this road since. A client-side Abilities API was announced for WordPress 7.0 in a Make WordPress Core post dated 24 March 2026, extending the same registry into the editor.

WordPress MCP server options compared

All figures below were captured on 28 August 2026 from the sources named in each row.

Read the official adapter repository
View the plugin directory listing

Where each option loses

A comparison in which nothing has a downside is not a comparison. Here is where each of these falls down.

WordPress/mcp-adapter is a developer package, not a product. It is installed with Composer, it has no settings screen, and it does nothing at all until something in your install registers abilities and marks them public. Its version number is still below 1.0, and its own repository carries migration guides for v0.3.0 and v0.5.0, which is a polite way of saying the interface has broken twice. If you want to plug something in and have an assistant start editing posts, this is not that.

Automattic/wordpress-mcp loses on the only axis that matters for software with write access to a production site: nobody is maintaining it. The repository is archived and read-only. There will be no security patches. It is still installable, still works, and is still the first recommendation in several widely linked round-ups — one of the most visible of which was published on 15 January 2026, four days before the archive, and has not been revised since. That is not a criticism of the people who wrote those pages; it is what happens when a category moves faster than a publishing schedule.

Enable Abilities for MCP loses on trust surface. It is a third-party plugin sitting between your site and the core adapter, and it embeds its own OAuth 2.1 authorisation server so that claude.ai can connect without local setup. That is genuinely convenient, and it is also an authorisation server you are now running. Its install base was listed at 2,000+ on 28 August 2026, which is small for a component holding the keys to write operations. Nothing here suggests it is badly built — the listing describes per-ability toggles, capability checks and an execution log, all of which are the right features — but 2,000 installs is not the same kind of scrutiny that a plugin like the ones covered in our roundup of WordPress security plugins has received.

InstaWP/mcp-wp loses on auditability. As of this capture it has published no tagged releases on GitHub, which means there is no version to pin in a deployment and no changelog to read before updating. Running outside WordPress, its only gate is whatever the application password’s user can do through the REST API, so scoping is coarse: you control it by creating a limited user, not by choosing individual abilities. Its SQL query tool needs you to add a custom REST endpoint, and is restricted to read-only single statements.

WP Engine Smart Search AI MCP loses on scope and portability. It is read-only by design — it retrieves approved published content for an AI client to answer questions with, and cannot create, edit or delete anything. It is also tied to WP Engine’s Smart Search AI or Managed Vector Database products, so it is not an option if your site lives elsewhere. The product page lists no price for the underlying subscription; the MCP layer itself is described as no extra charge for existing customers. If you are weighing that against other managed platforms, our comparison of Kinsta and WP Engine and the wider guide to WordPress hosting cover the rest of what those plans include.

What running a WordPress MCP server on a live site is actually like

The notes in this section come from WPNeon’s own editorial workflow, which is connected to this WordPress install over MCP. They are operational observations, not benchmarks, and they are the kind of thing that only shows up once an agent is doing real work rather than a demonstration.

Post and page write paths are not interchangeable. The tool that updates a post rejects a page ID outright. If your abilities or tools are named generically, an agent will pick the wrong one and get an error that reads like a permissions problem when it is a post-type problem.

Search-and-replace operations match raw HTML, not what you see in the editor. Passing an entity-escaped string returns zero replacements and no error. Silent no-ops are worse than failures, because an agent treats them as success and moves on.

Custom post types that are not registered with show_in_rest are invisible. On this site an entire portfolio post type — including a page carrying roughly 117 referring domains — simply does not exist as far as the REST API is concerned, and therefore does not exist to any MCP client built on it. Nothing warns you. The content is live, and the tooling reports nothing.

Some plugin values are computed in the browser and cannot be read or written over REST. Rank Math’s SEO score is the example we hit: an automated run can set every input the analyser evaluates — focus keyword, SEO title, meta description — and still cannot read the resulting number, because it is calculated client-side in the editor. A human opening the post and pressing Update once populates it. If you are configuring that plugin, our Rank Math Pro review and the Rank Math and Yoast comparison cover the settings themselves.

Bulk writes hit rate limits. Roughly fifty consecutive write operations is where this install starts refusing them. Any agent doing a site-wide pass needs to expect that and pause rather than retry into a wall.

None of these are faults in MCP. They are the ordinary seams of WordPress becoming visible when something automated walks across them at speed.

Security: the permission callback is the whole game

The developer blog post introducing the adapter is explicit that the adapter treats an MCP client as a logged-in user, and recommends that production deployments use a dedicated account with limited capabilities rather than an administrator. That advice is doing more work than it looks like it is.

Every access decision resolves to two things: which user the credential maps to, and what the permission_callback on each ability checks. The transport, the token format and the plugin’s settings screen are all upstream of that; none of them can grant something the callback refuses, and none of them will save you if the callback is permissive and the account is an administrator.

Practical consequences, in order of how often they bite:

• Create a dedicated user. An application password on your own administrator account is the fastest way to set this up and the worst way to run it. Give the MCP account the narrowest role that does the job, the way you would for any other automated integration.
• Expect an agent to try everything it can see. A tool that is exposed will eventually be called. “It probably won’t use that” is not an access control.
• Have a restore path before you grant write access. This is ordinary hygiene, and it is covered in our guide to WordPress backup plugins. An agent that deletes the wrong thing is not different in kind from a bad update; it is just faster.
• Log what was called. An execution log is the difference between “something changed” and “this tool changed it at this time as this user”.
• Watch your login surface. Adding an OAuth server or long-lived tokens changes the shape of what an attacker can aim at; if you are already hardening that area, the options in our custom login plugin roundup and dashboard plugin guide are the neighbouring controls.

How to choose

The decision is mostly determined by what you are actually trying to do.

If you are building. Use WordPress/mcp-adapter and register your own abilities. You get exact control over what exists, each one carries its own permission check, and you are on the path the WordPress project is committing to rather than a fork of it. Read the developer blog introduction first; it is short and it is the canonical description.

If you want to connect an assistant to a site you already run. The plugin route via Enable Abilities for MCP is the shortest path, on the understanding that you are adding a third-party component with an OAuth server in it. Turn on only the abilities you need. Do not start from “enable everything and see what happens”.

If you only need an AI client to read your content. A read-only hosted server such as WP Engine’s removes the entire write-access question, which is a real advantage rather than a limitation, if reading is all you need.

If you inherited a setup running Automattic’s plugin. It still works. Plan the move anyway, because archived software with write access to a production database is a maintenance liability regardless of whether it currently functions.

One thing worth saying plainly: this category is roughly a year old and moving quickly. The official package has published breaking changes twice, the previous official plugin was retired inside seven months, and the core API underneath all of it gained a client-side counterpart in WordPress 7.0. Anything you read about it — including this page — should be read with its capture date attached. The dates above are 28 August 2026, and this page will be re-verified rather than left to drift. If you are auditing your stack more broadly, our overviews of WordPress SEO plugins and free SEO tools follow the same convention.

Frequently asked questions

Is there an official WordPress MCP server?

Yes. The official package is WordPress/mcp-adapter, maintained under the WordPress organisation and licensed GPL-2.0-or-later. It bridges the Abilities API to the Model Context Protocol. Automattic’s earlier wordpress-mcp plugin, which many articles still call the official server, was archived read-only on 19 January 2026.

Do I need WordPress 6.9 to use one?

For the official adapter, yes. It requires WordPress 6.9 or later because it depends on the Abilities API that shipped in that release, and PHP 7.4 or 8.x. External proxy servers that talk to the REST API from outside WordPress do not have that requirement, but they also cannot use ability-level permissions.

Can an AI agent delete my content through MCP?

Only if an ability exposing deletion exists, is marked public, and its permission callback passes for the user your credential maps to. The adapter treats an MCP client as a logged-in user, so an administrator application password gives an agent administrator reach. Use a dedicated limited-capability account instead.

What is the difference between the Abilities API and MCP?

The Abilities API is a WordPress core registry describing what your site can do, with inputs, outputs and permission callbacks. MCP is a protocol AI clients speak. The adapter translates between them. The registry is the security boundary; the protocol is only the transport format used to reach it.

Does a WordPress MCP server slow down my site?

An in-WordPress adapter only executes when an MCP client calls it, so there is no front-end cost to ordinary visitors. Bulk agent activity is a different matter: it is authenticated traffic that bypasses page caching, and on this install roughly fifty consecutive write operations is where rate limiting begins.

Is any of this monetised or sponsored?

No. Nothing in this comparison is an affiliate placement, and none of the projects named here were contacted before publication. WPNeon does not run a test rig, so nothing above is presented as a benchmark or as firsthand performance measurement.