WordPress MCP servers: what they actually let an agent do
You’re pointing Claude, Cursor, or ChatGPT at your own WordPress site for the first time. Somewhere in the setup you’re asked for a credential, and the only one WordPress hands you by default is an Application Password. Tied to an Administrator account, that’s the same kind of credential that can install plugins, delete users, and edit every post on the site. You’re about to give an AI agent the same reach you have. Before you paste that credential in, the thing to establish is what, specifically, stands between “the agent can search my content” and “the agent can do anything I can do.”
That boundary is exactly what a WordPress MCP server is supposed to draw. Whether it does, and where, is different for every implementation currently in circulation.
A WordPress MCP server turns registered abilities into agent tools
The Model Context Protocol (MCP) is a standard for how an AI agent discovers and calls tools. In WordPress’s case, those tools read or write posts, users, settings, and plugin data. WordPress core’s answer to “which tools” is the Abilities API, a registry where a plugin or theme declares a discrete, named capability (“create a draft post,” “list published products”) rather than exposing the whole REST API surface at once. An MCP server sits on top of that registry and translates it into the format an agent’s client understands.
The part that determines whether this is safe is what happens between “the agent asks to do something” and “WordPress lets it.” Two designs are in circulation right now:
- Capability inheritance – the agent authenticates as a specific WordPress user, and every call is checked against that user’s role and capabilities, the same permission system that already governs what an Editor versus a Contributor can do in wp-admin. An agent connected as an Editor can’t touch plugins or site settings, because the underlying WordPress user can’t either.
- Opt-in ability exposure – abilities are private by default and have to be explicitly marked available to MCP, so even a capability the connected user technically has stays out of the agent’s reach unless someone turned it on for that purpose.
The strongest implementations combine both: an agent is scoped by the WordPress user it’s connected as, and by which abilities have been explicitly exposed for agent use at all.
The three implementations differ most in what they expose by default
WordPress/mcp-adapter is WordPress core’s official MCP implementation and the repository to build on. It converts registered Abilities into MCP tools automatically, ships a default server with meta-tools for discovering and executing abilities dynamically, and treats abilities as private unless a developer explicitly marks them public for MCP. Permission checks run per-ability against WordPress’s existing capability system. It supports HTTP transport (/wp-json/mcp/...) and STDIO via WP-CLI.
Agent Abilities for MCP, available on WordPress.com and WordPress.org, is the most permission-explicit option so far: 153 abilities across WordPress core (83 abilities: posts, pages, taxonomies, media, users, templates) and integrations including WooCommerce, Advanced Custom Fields, and SEO plugins like Rank Math, Yoast, and All in One SEO (70 abilities). Every ability ships disabled; a site owner turns individual ones on. The agent authenticates as a bound WordPress user rather than an admin-equivalent credential, every call is capability-checked again at execution time (not just at connection time), and the plugin logs activity including denied attempts, without storing the free-text content of what was sent.
WP Engine’s MCP Server belongs in a different category from the two above. Marketed as Smart Search AI MCP, it connects an agent to a managed vector database of a site’s published, approved content for retrieval, for answering questions and surfacing current copy, and doesn’t expose write, edit, or administrative tools at all. If your mental model of “WordPress MCP server” is “an agent that can act on my site,” WP Engine’s product is a read-only search layer instead, a safer default for a specific job and not a substitute for a scoped write-access tool if that’s what you need.
Scoping the abilities does nothing about the credential’s lifetime
You can scope every ability an agent can call and still be left with a credential that never expires. Scoped abilities solve what an agent can call, not how long a credential granting that access stays valid, or what happens to it when the task is done. An Application Password issued to an MCP connection doesn’t expire by default and isn’t revoked automatically when the chat session ends; it sits in the Application Passwords section of the user’s profile until someone remembers to delete it, exactly like every other Application Password on the site.
That gap is the one that put Rank Math’s plugin in the news: an Application Password created automatically, scoped to the connecting account’s full Administrator role, with no expiry and no way to turn it off, so their support AI agent could act on the site. The credential itself worked exactly as Application Passwords are built to work. What failed was the assumption that a feature built for scripts would behave responsibly when handed to an agent with no consent screen and no clock running.
A community write-up on WordPress MCP security states the underlying rule: an MCP connection built on an Application Password carries the same blast radius as that password. Its recommendation is a scoped, single-purpose password per MCP connection, revoked when not in use. That is the right instinct, and it has to be applied by hand, one credential at a time, on every site where you’ve connected an agent.
Before you connect an agent, check four things
Whichever server you’re evaluating, these four questions decide how much of your site you are handing over:
- What WordPress user is the agent authenticating as? If the answer is “an Administrator,” every downstream permission check is checking against full access. The scoping only works if the connecting account itself is limited to what the agent needs.
- Is the credential a standing Application Password, or does it expire? An Application Password has no expiry of its own and stays valid until somebody deletes it from the user’s profile. A server that issues a short-lived token for the connection instead puts a ceiling on how long the access lasts.
- Are abilities opt-in, or is everything exposed by default? WordPress core’s MCP Adapter treats abilities as private unless explicitly marked public, a design worth favoring over a server that exposes its full tool set as soon as it’s active.
- Is there a log of what the agent called, including denied attempts? A server that only logs successful actions can’t tell you when an agent tried something it shouldn’t have and was stopped, which is exactly the signal you’d want if a connection is misbehaving.
The same primitive, applied to a script instead of a person
A support session and an MCP connection create the identical shape of problem. Both hand a credential to something that isn’t the site owner. TrustedLogin already solves the human half of that for support agents connecting to customer sites: a scoped account in place of a standing admin login, an expiry that runs on its own, and a revoke that is a single action rather than a per-site cleanup. Scoped abilities answer what an agent can touch. Time-boxed, revocable credentials answer how long it can touch it. A WordPress MCP setup needs both, and right now, most implementations only ship the first.
GravityKit, built by the same team as TrustedLogin, covers the MCP landscape from the plugin-builder’s side; this piece is the credential-security half of that same conversation.