What WordPress MCP Is and What Sits Underneath It
WordPress MCP means a WordPress site that speaks the Model Context Protocol, so an AI assistant such as Claude or ChatGPT can read and change the site through a defined list of tools instead of a copied and pasted screenshot. The part that decides whether that is a good idea is not the protocol, it is how the assistant signs in and what it is allowed to touch. This is for site owners and developers deciding how to connect an assistant to a live site.
MCP in a Few Lines
MCP is an open protocol with two sides. The server publishes a list of tools, each with a name, a description, and a typed input. The client, which is the assistant, reads the list and calls tools when a request needs one. Messages travel as JSON-RPC 2.0. Nothing about it is specific to WordPress, which is why a site needs an adapter in the middle before a general assistant can do anything useful with it.
The Abilities API Underneath
WordPress 6.9 added the Abilities API, described in the WordPress developer blog as a way to standardize how core and plugins expose what they can do. A plugin registers an ability with a unique name, typed input and output, a permission callback, and the code that runs. Core ships three to start with: core/get-site-info, core/get-user-info, and core/get-environment-info.
An ability is not an MCP tool by itself. It is a description of an action that anything, including an assistant, can discover. The step that makes it reachable from an assistant is a separate piece, and that is where the official adapter comes in.
What the Official Adapter Does
The WordPress MCP Adapter, introduced in a February 2026 developer post, turns registered abilities into MCP tools. Its default server exposes three of them: mcp-adapter-discover-abilities, mcp-adapter-get-ability-info, and mcp-adapter-execute-ability. An ability appears there only when it is flagged public for MCP. The post lists STDIO for local development through WP-CLI and HTTP for public sites, with application passwords, JWT tokens, or a custom OAuth implementation for authentication (checked October 2026).
Local Connections and Remote Ones
The two transports are different jobs. A local STDIO connection runs on a developer's own machine against a development copy of a site. The MCP specification itself says STDIO implementations should not follow its authorization flow and should take credentials from the environment. A remote connection to a live site is a different matter, because anyone who can reach the URL can try to use it, and that is when authentication stops being optional in practice.
The same specification calls authorization optional, which is accurate and worth reading twice. A server that skips it is conforming to the spec. Whether a server skips it is a choice its author made, not something the protocol enforces.
What an Agent Can Reach on a Plain Site
With a finished plugin rather than a library, core is covered without writing any PHP. The MCP Connector plugin describes its own tools as covering WordPress core: posts, pages, media, comments, users, taxonomies, menus, plugins, themes, and settings, which is most of what an editor does in wp-admin. Anything beyond core comes from Abilities that other plugins register.
That list is also the blast radius. An assistant that can edit settings and plugins can break a site as quickly as it can fix one, and the rest of this article is about narrowing that list before the first connection is made.
A Library or a Finished Plugin
The official adapter is a library. Someone writes and maintains PHP to register the abilities that matter before an assistant can do anything, which suits a development team building a custom integration. A finished plugin suits an owner who wants to install, pick what is allowed, and connect. The MCP Connector setup guide covers each screen for that second path. Neither is better in general. They answer different questions.
Connecting Without Handing Over the Keys
Connecting an assistant to a live site is the same decision as giving a contractor a login. The useful questions are how it signs in, what the login can do, and how you take it back.
Why Sign-In Is the Decision That Matters
For HTTP connections, the MCP specification builds authorization on OAuth 2.1. A protected server must publish OAuth 2.0 Protected Resource Metadata so the client can discover the authorization server, and clients must use PKCE to protect the authorization code. Tokens must be issued for the specific server, and a server must reject tokens meant for someone else. All of this is in the authorization section of the 2025-06-18 specification, which is the version checked here in October 2026.
In plain terms: the assistant sends you to a WordPress sign-in screen, you approve, and the assistant gets a token that expires. Compare that with a password pasted into a settings box, which never expires and works from anywhere.
Two details are worth checking in any server you try. The approval screen should name the app asking and the domain it came from, so you can tell a real request from a lookalike. And the token should be bound to your site, so one stolen from another service cannot be replayed against yours. The specification requires the second, and a good server makes the first visible.
Application Passwords and OAuth Compared
Application passwords arrived in WordPress 5.6. They are generated per user, can be revoked one at a time from the Edit User screen, and show when each was last used. They work through the REST API over HTTPS. That is a real improvement over sharing the account password, and for a script you wrote yourself it is a sensible choice.
The weakness is what the password represents. An application password carries the full abilities of the user it belongs to, with no consent screen and no expiry. OAuth adds the screen naming who is asking, tokens that expire, and a refresh step. The connector's own page makes a related point: a server that only accepts bearer tokens or Basic Auth may run in Claude Desktop and Cursor, while ChatGPT, which connects over OAuth, never gets past the first screen.
Scope the Connection with a Profile
The connector uses profiles. A content profile exposes posts and media and nothing else. An administrative profile exposes more, and you can define your own. A read-only profile is a reasonable first connection for anything new: the assistant can summarize, audit, and draft, and cannot publish.
Most people settle on a custom profile once they know which dozen tools they actually use. Start narrow and widen it when a task needs more, rather than starting wide and trimming after something goes wrong.
Turn Other Plugins' Abilities On One at a Time
Abilities registered by other plugins start switched off in every profile, Full Access included. You enable them profile by profile, and each is marked Write or Destructive when it can change things. This is the setting to take slowly. A plugin you installed for an unrelated reason may have registered an ability that deletes or overwrites records, and no one chose that when installing it.
Treat Page Content as Untrusted Input
An assistant reads the text it is shown. A comment on a post, a form submission, or the body of an imported page is text that a stranger wrote, and it will be read by the same assistant holding your tools. Instructions hidden in that text can be followed as if you had typed them.
Two habits limit the damage. Connect with a profile that cannot change anything while the assistant is reading untrusted content, and run first attempts at a bulk change on a staging copy, then read what changed before pushing it. The connector offers previewed and reversible edits for exactly this.
A First Connection, Step by Step
Do the first connection on a staging copy. Install the plugin there, create a profile that can read and cannot write, and connect one assistant. Ask for something harmless and checkable, such as a list of pages with no meta description or a summary of the last ten comments, and compare the answer with what wp-admin shows. If the two agree, you have confirmed the connection reaches the right site and sees what the profile allows.
Then widen it by one tool. Ask for a change to a single draft post, read the result, and only after that consider the live site. Before connecting to production, decide where you would end the connection if something looked wrong, and write that down next to the credentials. A login you do not know how to take back is a login you should not give out.
Keep a second profile for the work you do rarely. Switching to an administrative profile for an hour of plugin cleanup, then back, costs a minute and keeps the daily connection small.
Running MCP on Your Own Site
The MCP Connector is a free plugin that turns the site you already run into an MCP server. It runs on your server, the endpoint is on your own domain, and nothing about your site passes through us. For teams that connect many tools and many people, Managed MCP puts every connector behind one endpoint and sets access person by person and tool by tool, with credentials kept server side. If the site underneath needs looking after, managed WordPress hosting includes a staging copy, and WordPress maintenance covers updates and backups. The wider AI services page lists what else we run.
