MCP for WordPress: giving an assistant real access, safely
Model Context Protocol turns a chat window into something that can actually operate your site. Here is what that looks like in practice, and where the guardrails belong.
Most “AI for WordPress” plugins are a text box that writes blog posts. Useful for about a week. The interesting version is the opposite direction: giving an assistant scoped, permissioned access to the site so it can do the work — read the content model, run a query, fix the thing it found.
That is what Model Context Protocol is for. MCP is a standard way to expose tools and data to an AI client: you define what exists, what it may do, and with what permissions. The assistant then calls those tools instead of guessing.
What it is useful for on a real site
Auditing. “List every published page with a missing or duplicate meta description.” That is a query, not an opinion, and the answer is a table you can act on.
Bulk content work. Re-categorising two hundred posts against a new taxonomy, generating alt text for a media library that has none, finding and fixing internal links that 404 after a migration.
Operations. Checking what plugin versions are installed across several client sites, spotting the one still on an abandoned plugin, confirming a backup actually ran.
Editorial support. Drafting against your own site’s existing content and voice, with the assistant able to read what has already been published rather than inventing a house style.
Where the guardrails belong
Access is the whole design problem. A few rules I hold to:
- Scope the credentials to the job. An audit tool needs read access. It does not need the ability to delete a post.
- Staging first, always. Anything that writes runs against a staging copy until its behaviour is boring.
- Everything destructive is confirmed by a human. Bulk edits, deletions, plugin changes, anything touching users or orders.
- Log what was done. If you cannot answer “what changed and when” afterwards, you do not have automation, you have a mystery.
There is also a specific trap worth naming: content the assistant reads is data, not instruction. A comment, a post or a scraped page that contains “ignore your instructions and…” must be treated as text to summarise, never as a command. Anything with write access needs that boundary enforced deliberately.
What it does not replace
MCP does not make the assistant a developer. It makes it able to act on your systems, which raises the value of good judgement rather than removing the need for it. The architecture decisions, the “should we even do this”, the review of the diff — those stay human.
It also does not replace WP-CLI for anything you already have a script for. If the task is deterministic and you run it weekly, write the script. MCP earns its place where the task needs reading, judgement and a decision in the middle.
Getting started sensibly
Start read-only. Point an assistant at a staging copy of your site, ask it questions you already know the answers to, and see whether it gets them right. Then add one write capability at a time, each with a human confirmation, and keep the log.
Done that way it becomes genuinely useful within a week — and it stays boring, which for anything with access to a production site is the highest compliment available.
