A WordPress MCP server is the piece that lets an AI assistant like Claude or ChatGPT read and change a WordPress site through a controlled set of tools, instead of through pasted instructions and copied snippets. I have built one, SiteHelm, and I run it against real client sites, so this post is the version of the explainer I wish had existed when I started: which of the confusingly named options is which, and where the actual danger sits.
The confusion is worth clearing first, because the search results mix up two different things called “WordPress MCP”. One is the MCP server run by WordPress.org itself, which is about the plugin directory: it lets an AI validate a readme or work with plugin submissions. It cannot touch your site. The other is a site-management MCP server, something installed on or pointed at your own WordPress site, and that is the kind this post is about.
Which server should you actually use?
The Model Context Protocol is an open standard, so there are many implementations, and the graveyard matters as much as the list. Automattic’s original wordpress-mcp plugin is archived and no longer maintained; a lot of guides still point at it. The active official successor is the WordPress/mcp-adapter project under the WordPress GitHub organisation. Around those sit commercial and plugin-vendor options, most of which are honest wrappers with a product attached.
Whatever you pick, the credential model is the same underneath: WordPress application passwords. They are shown once, stored hashed, revocable one at a time, and cannot be used to log into wp-admin. That is the right shape for giving software a key. I walked through a real case of handing one to a support agent in the Rank Math support agent and application passwords, and the same care applies tenfold when the agent is an AI that acts on its own.
The permission question nobody answers
Every guide lists risks in the abstract: over-permissioning, prompt injection, data leakage. Almost none of them will publish a concrete list of what an AI agent should not be allowed to do. Here is the deny list I enforce in SiteHelm, and why each item is on it:
- User accounts. Creating or editing users is account takeover with extra steps. No tool exists for it.
- Plugin and theme activation. One activation can take a site down or open a vulnerability. A human clicks that button.
- Site options.
wp_optionsholds the site URL, the “discourage search engines” toggle and dozens of switches where one wrong write is an outage or a silent deindexing. - Theme and plugin files. File editing is code execution. That is not an SEO tool, that is a shell.
What is left, posts, titles, meta descriptions, redirects, alt text, is the work an SEO agent is actually for, and even there every write goes through a diff the human approves.
What breaks in production
The demos never show the failure modes, so here are the ones I hit doing this for real:
WordPress mangles content on save. Backslashes get stripped when content goes through WordPress’s save path, which silently corrupts any regex or escaped string an agent writes into a snippet. An agent that does not re-read what it wrote will believe a change landed when it did not.
Page builders hide the real content. On an Elementor site the rendered content does not live in post_content; the code lives in Elementor’s own meta fields. An agent that dutifully edits post_content reports success and changes nothing a visitor sees. Any MCP server that claims WordPress support but only knows post_content is only supporting a fraction of real sites.
The SEO consequences are unsupervised. This is the part that belongs on this site: an agent editing at scale can rewrite title tags, churn canonicals and touch things Google reads, faster than any human review cycle. The same reasoning I laid out for WebMCP and whether it affects SEO applies here: the protocol is neutral, the blast radius is not. Rate-limit writes, keep revisions on, and treat live title tags the way you treat production code.
Should you connect an AI to your site at all?
If the server has a written deny list, shows diffs before writes, and authenticates with a revocable application password: yes, for content and metadata work it is genuinely faster than the copy-paste loop. If the pitch is “give us your admin credentials and the AI handles everything”, the correct answer is no. The difference between those two offers is the entire subject of this post.
Sources
- Model Context Protocol, specification and overview, checked 14 September 2026
- WordPress.org, using the MCP server, for the plugin-directory MCP being a separate thing
- GitHub, Automattic/wordpress-mcp (archived) and WordPress/mcp-adapter (active successor), checked 14 September 2026
- WordPress core handbook, application passwords, for the credential properties
- SiteHelm, my own WordPress MCP server, for the deny list and the production failure modes described first-hand