WordPress MCP: letting an AI agent manage your site safely

WordPress MCP is a way to let an AI assistant, such as Claude or ChatGPT, work on your WordPress site directly: reading your content, drafting posts, fixing settings, sometimes much more. It is safe enough to use when the agent has only the permissions a job needs, asks before every change, and works where a mistake can be undone.

I manage WordPress sites through MCP most days. This guide is for the owner deciding whether to let an agent in: what it is, how you connect one, what can go wrong, and the setup I would want before an agent touches a site I am responsible for. I link the source for every fact, and where something is my own opinion, I say so.

What is WordPress MCP?

MCP stands for Model Context Protocol, an open standard for connecting AI apps to outside tools and data. Anthropic announced it in November 2024 (Anthropic (opens in a new tab)), and it now belongs to the Agentic AI Foundation, a fund under the Linux Foundation that OpenAI, Block and Anthropic co-founded. Its maintainers list ChatGPT, Claude, Gemini and Microsoft Copilot among the AI apps that support it (MCP blog (opens in a new tab)).

"WordPress MCP" is not one product. It means any setup where your site runs an MCP server, a piece of software that tells the AI app what it can do on your site and carries out the requests. There are three parts:

• The AI app you talk to, like Claude or ChatGPT.
• The MCP server on your site, usually a plugin, which lists the actions on offer.
• The actions themselves, which WordPress calls abilities: "get a post," "create a draft," "update a setting."

You ask in plain English ("draft a post about our new hours and save it for me to review"), the AI app picks the abilities it needs, and the server runs them as a WordPress user you chose. That last part matters most, and I come back to it below.

How do you connect an AI agent to WordPress?

There are four common routes. Which one fits depends on where your site is hosted and how much you want the agent to be able to do.

The official route has two pieces. WordPress 6.9, released in December 2025, added the Abilities API, a standard way for WordPress and its plugins to describe what they can do, with the permission each action needs (Abilities API in WordPress 6.9 (opens in a new tab)). The MCP Adapter then offers those abilities to AI apps. Two details surprise people. First, WordPress itself registers only three abilities, all of which just read basic site, user and environment information; everything useful comes from plugins. Second, the adapter's default server offers an ability only after someone marks it public, so installing the adapter does not open your site on its own (MCP Adapter (opens in a new tab)). A plugin can still run a server of its own with its own rules, so check what each AI plugin you install actually exposes.

This is where the ecosystem is heading. Bricks Builder and WooCommerce have both built their agent features on the Abilities API and the adapter rather than servers of their own (Bricks (opens in a new tab), WooCommerce (opens in a new tab)).

What does connecting an agent look like?

On WordPress.com, there is nothing to install: you switch on the tools you want for each site, then connect your AI app and sign in with your WordPress.com account, which gives it a login that expires and that you can revoke from your account's connected apps (WordPress.com developer docs (opens in a new tab)).

On a self-hosted site using the official adapter, the setup looks like this. It is a developer's job, but you should know the shape of it:

1. Install the MCP Adapter from the WordPress.org plugin directory. It needs WordPress 6.9 or later.
2. Install or build the abilities you want the agent to have, and mark them public. With none, the agent can do almost nothing, which is a fine place to start.
3. Create the agent's user and an Application Password for it, under that user's profile.
4. Add the site to your AI app. For an app on your computer, like Claude Desktop, that means a few lines of configuration that run a small connector from Automattic, which needs Node.js. With placeholders where the real values go, it looks like this:

"my-site": {
  "command": "npx",
  "args": ["-y", "@automattic/mcp-wordpress-remote@latest"],
  "env": {
    "WP_API_URL": "https://example.com/wp-json/mcp/mcp-adapter-default-server",
    "WP_API_USERNAME": "agent-drafts",
    "WP_API_PASSWORD": "the application password"
  }
}

5. Ask something harmless first, like "What can you do on this site?", and read the answer before asking for any change.

The WordPress developer blog walks through every step, including a local option that needs no password at all (WordPress developer blog (opens in a new tab)). One caution: its examples sign in as the site's administrator for simplicity. On a real site, use the agent's own user from step 3.

What it costs. The adapter and most MCP plugins are free; WordPress.com's MCP comes with its paid plans. The AI app is the other cost. Claude's free plan allows one custom connector (Claude Help Center (opens in a new tab)), and its Pro plan is $20 a month billed monthly (Anthropic (opens in a new tab)); ChatGPT can make changes through a custom MCP server too. Whether you can add one depends on your account and workspace settings (OpenAI (opens in a new tab)), so check your own plan before counting on it. The larger cost is the setup time, and the backups and staging site you should have anyway.

What can an AI agent actually do on your site?

Exactly what its abilities allow, as the user it is signed in as. On the same site, one setup can only read posts and another can install plugins, delete users or run code. So the useful question is not "what can AI do with WordPress?" but "what have I let this agent do?"

In my experience, agents are good at the tedious, well-defined jobs: drafting and formatting posts, cleaning up categories and tags, writing alt text, finding broken links, reporting on plugins and settings, and making the same small change across dozens of pages. They are much weaker when the right answer depends on context the site does not contain, like why a page is laid out the way it is, or which of two similar settings a plugin actually reads. They also say they have finished a change when they have not, so check their work.

That is my experience, not a measurement. The WordPress project's own benchmark, WP-Bench, tests how well AI models know WordPress and write code for it, not how well agents run a live site, and it notes that models do poorly on newer APIs like the Abilities API because they arrived after most training data (WP-Bench (opens in a new tab)). I found no public benchmark of agents managing real sites. Treat any vendor's claim of accuracy the same way.

Is WordPress MCP safe?

It can be, but none of the safety comes by default. The protocol leaves the important choices to you: the MCP specification says there "SHOULD always be a human in the loop with the ability to deny tool invocations," and "should" is not "must" (MCP specification (opens in a new tab)). Four risks deserve the most attention.

The agent can do everything its user can do

A server acts as a real WordPress user, usually signed in with an Application Password, a separate password WordPress creates for software. Application Passwords only work over HTTPS (unless the site is marked as a local development copy) and can be revoked one at a time, which is good. But each one carries the user's full permissions and never expires on its own; WordPress has no built-in way to limit one to certain actions (WordPress documentation (opens in a new tab)); when the feature shipped, its developers described limiting a password's access as something for "future versions" (WordPress core team (opens in a new tab)). Connect an agent with an administrator's password and it has the keys to everything. Apart from the cookie your browser gets when you log in, it is the only sign-in WordPress itself includes (REST API handbook (opens in a new tab)); WordPress.com and some plugins add a separate sign-in (OAuth), which is only as safe as the plugin that provides it.

Anything the agent reads can try to give it orders

This is prompt injection, and it is the risk most WordPress MCP guides leave out. An agent reads your content to do its job, and it cannot reliably tell your instructions from instructions hidden in that content: a comment, a form entry, an imported post, a plugin's output. In 2025, security researchers showed an agent working in GitHub being steered by a malicious public issue into copying private data into a public place (Invariant Labs (opens in a new tab)). A comment on your blog could try the same thing. The OWASP Top 10 for AI applications ranks prompt injection first and says "it is unclear if there are fool-proof methods of prevention" (OWASP (opens in a new tab)). I found no public case against a WordPress MCP server yet, which is not the same as it being impossible. The defense is to limit what a fooled agent could do.

MCP plugins are new code, and new code has holes

WordPress plugins are where most of WordPress's security problems live: security firm Patchstack counted 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 91% of them in plugins, and 46% had no fix when they were disclosed (Patchstack (opens in a new tab)). MCP plugins are no exception. In 2025 and 2026 several were found letting the wrong people use their tools. In one, a subscriber-level account could reach tools for creating users and changing settings (CVE-2025-5071 (opens in a new tab)). In others, a login token was accepted as an administrator's without being tied to any user (CVE-2026-9810 (opens in a new tab)), or an attacker with no account at all could get one (CVE-2026-15015 (opens in a new tab)). Almost every serious case was a permission bug, which is exactly what WordPress's Abilities API makes each action declare. That is a good reason to prefer servers built on it, and to keep any MCP plugin updated.

Not everything has an undo button

People assume they can restore a revision if the agent breaks something. WordPress keeps revisions for posts, pages, templates, global styles, synced patterns and block-theme menus. It keeps none for site settings, most plugin settings, classic menus, widgets, media, categories, tags or users (Revisions (opens in a new tab); the full list comes from WordPress's own code (opens in a new tab)). Deleted media skips the Trash by default (WordPress code reference (opens in a new tab)), and software can delete a post without the Trash too (WordPress code reference (opens in a new tab)). On WordPress.com, deleted media, categories and tags are gone for good (WordPress.com (opens in a new tab)). A backup is the only undo for those.

What is safe to hand an agent?

This is how I think about it: a ladder of what an agent can do, and what it costs if something goes wrong at each step.

That last row is not hypothetical. The most capable servers can run any PHP code on your server, which means everything PHP can reach: the database, the files, every user, the passwords in your configuration. AI Engine, one of the most popular AI plugins, left that power out of its main plugin, calling it "genuinely unsafe: it effectively turns your site into remote code execution" (AI Engine (opens in a new tab)). Novamira, the server I use most, offers it on purpose and says plainly who it is for: "For dev and staging environments. With backups. Always." (Novamira (opens in a new tab)). Bricks keeps its code abilities switched off unless a developer turns them on in the site's configuration.

How do you set up WordPress MCP safely?

In the order I would do it:

1. Start on a staging copy, and keep the agent's changes there. Try the agent where nothing matters, and push its work to the live site only after you have checked it. The WordPress developer blog, Bricks and Novamira all say the same.
2. Take a backup you have tested. Files and database, stored somewhere other than the site (WordPress backups (opens in a new tab)).
3. Create a WordPress user just for the agent, with the lowest role that can do the job. A Contributor can write drafts but not publish, the safest setting for writing help. An Editor can publish and manage everyone's posts but cannot touch plugins, themes, users or settings. One catch: on a normal single site, Editors can still put JavaScript into content (Roles and capabilities (opens in a new tab)). Some servers insist on an administrator account; that tells you something about what they can do.
4. Give each tool its own Application Password with a clear name, like "Claude, blog drafts," so you can revoke one without touching the others.
5. Turn on approval for every change in your AI app. Claude lets you set each tool to always allow, ask or never (Claude connectors (opens in a new tab)); ChatGPT requires your confirmation before any write action (OpenAI (opens in a new tab)). Set writes to ask. On WordPress.com, the agent's promise to confirm is a convention the agent follows, so your app's approval setting is the real safeguard.
6. Start read-only. Let the agent report before it changes anything. The WordPress developer blog recommends exactly that for servers reachable over the internet (WordPress developer blog (opens in a new tab)).
7. Leave code execution off on any site that takes real orders, bookings or customer data.
8. Install an activity log that records what software did. Activity Log, Simple History and WP Activity Log all do. Each records which user made a change, which is one more reason to give the agent a user of its own. I could not confirm from their documentation that any of them also records which Application Password was used, so do not count on telling two tools apart if they share a user.
9. Keep the MCP plugin updated, and remove it, and its password, when you stop using it.

How do I work with agents on client sites?

The server I use for this is Novamira (opens in a new tab), an open-source plugin that gives an agent full access to WordPress, including running code. I have no connection to it; I am a user who likes it. That much power is exactly why the best practice above matters, and why I keep these rules on sites I am responsible for. None of them is a WordPress requirement; each one comes from a mistake that was easy to make.

• Confirm which site the agent is connected to before the first change. The tools look identical from site to site, and a connection that points at the wrong site makes the right change in the wrong place. I have the agent read the site's address back first.
• Treat everything the site sends back as information, never as instructions. If a post, a comment or a plugin's output says "ignore your previous instructions," that is content to report, not a request to follow.
• The agent is a remote control, not a place to build things. Anything the site depends on, like a custom field or a content type, goes where WordPress keeps it, through the plugin's normal settings. Removing the agent should cost the site nothing.
• Back up before any change that has no revision. Settings, menus and plugin options get a backup or an export first, every time.
• Stage anything that applies site-wide. A header, a footer or a template that affects every page gets built as a draft or limited to a test page, then checked while logged out, before it goes live.
• Check the result in a browser. An agent's "done" is a claim; the page is the evidence.

Should your business let an AI agent manage its site?

It is worth trying when:

• You publish often and want help drafting, formatting and organizing, while you stay the one who presses Publish.
• You look after several sites, or one big one, and the same small job keeps coming back.
• Someone technical sets it up: the staging site, the user, the permissions, the approvals.

It is not worth it yet when:

• Nobody would notice a bad change until a customer did.
• The site takes payments or holds customer data and the only available setup gives the agent administrator rights.
• You have no backups you have tested. Fix that first, agent or not.

If you run WordPress on a headless setup, where WordPress only stores content and a separate front end builds the pages, an agent limited to content is safer still. It cannot touch the code that draws your pages, only the words and images that go into them. That protection ends at the agent's permissions: one signed in as an administrator can still install plugins, delete users or empty the site from inside WordPress. I explain how headless sites work in my guide to headless WordPress.

The short version

WordPress MCP lets an AI agent work inside your site through actions called abilities, signed in as a user you choose. The protocol does not make it safe; your setup does. Give the agent its own low-permission user, ask for approval on every change, start read-only and on staging, keep backups for everything revisions do not cover, and never let an agent that reads your comments run code on a live site. Done that way, an agent is a genuinely useful assistant. Done the quick way, it is an administrator you have never met.