Model Context Protocol is a way for an AI client to call tools. WordPress MCP is that idea pointed at a WordPress site: list posts, read a page, inspect plugins, fetch media metadata, sometimes write.
It is not a chatbot in the admin. It is not a “WordPress AI” plugin that generates meta descriptions. It is not a Nought product. It is a protocol surface that agencies will increasingly be asked to connect, because clients already use Cursor, Claude, or similar tools and they want those tools to see the site they actually maintain.
Used carefully, that is useful. Used as “give the agent admin”, it is a remote control with no seatbelt.
The job MCP is good at
An MCP server exposes a small catalogue of tools. A coding agent or desktop client can call those tools with structured arguments and get structured results. For WordPress, the valuable calls are the ones that replace clicking around wp-admin when you already know what you are looking for.
Typical agency work that fits:
- Inventory. Which plugins are active, which theme, which versions, how many posts of each type.
- Content inspection. Fetch a page by ID or slug, including ACF-shaped meta if the server exposes it, without loading the block editor.
- Search. Find posts that still mention a retired brand name, or pages that embed a given shortcode.
- Local operations. Point the agent at a local or staging site and ask it to draft a change, then you review the diff.
- Structured audits. Pull a list of templates, field groups, or REST routes and write the findings in the repo, not in a spreadsheet of screenshots.
None of that requires the agent to “be WordPress”. It requires WordPress to answer questions the same way an API would, with a session the agent is allowed to use.
That is closer to WP-CLI and the REST API than it is to Jetpack AI. If you already trust a developer with WP-CLI on staging, you already understand the shape of the risk. MCP is the same class of access, wired into a tool that will call it in a loop.
What it is not for
It is not a replacement for an editorial workflow. Publishing a week of blog posts through an agent because the MCP server has create_post is how you get tone drift, missed reviews, and a sitemap full of near-duplicates. If you want publishing assistance, put a human between draft and publish. MCP can fetch context. It should not be the publisher of record.
It is not a performance strategy. An agent that lists every post, then fetches every post, then summarises them, will hammer a site the same way a careless crawler will. Production WordPress is not a playground for unbounded tool loops.
It is not a security product. Connecting MCP does not make the site safer. It adds another client that can act as a user. If that user is an administrator, the agent can do administrator things.
It is not magic access to ACF internals. Some servers will expose post meta. Some will not. Schema changes — renaming a field, moving values, linking pages — still belong to tools that understand ACF storage. We built FieldCraft for that job. An MCP client can inspect a field group. It should not be the thing that rewrites wp_postmeta because a prompt said “clean this up”.
How this sits next to REST, WP-CLI and the admin
WordPress already has three ways in.
Admin is for humans. Slow, visual, permissioned by roles you can explain to a client.
REST is for applications. Application passwords, cookies, or OAuth; routes that already exist; the same capability checks as the admin if you have not disabled them.
WP-CLI is for operators. Shell access, full power, usually SSH to a specific environment.
MCP is a fourth client, not a fourth data model. Under the hood it will call REST, custom PHP, or CLI-equivalent functions. The reason to care is the caller: an LLM that will retry, chain tools, and improvise when a call fails.
That improvisation is the point of an agent and the reason WordPress MCP needs a smaller surface than “whatever an administrator can click”.
A practical split:
| Surface | Who it is for | Default environment |
|---|---|---|
| wp-admin | Editors and implementers | Production, with roles |
| REST | Your apps and headless fronts | Production, scoped |
| WP-CLI | Engineers | Local and staging first |
| MCP | AI clients used by engineers | Local and staging first |
If a task is not something you would run via WP-CLI on production, it is not something to hang on a production MCP server either.
What agencies should actually offer
Clients will ask for “ChatGPT on our WordPress”. Translate that before you sell it.
If they want faster drafting, that is an editorial process with a model in the sidebar or in a doc, then a human paste into Gutenberg. MCP is optional.
If they want the coding agent to see the site, that is MCP or REST against local and staging, with a written list of tools, a non-admin user, and no production writes. That is a delivery workflow, billed as engineering, not as a plugin SKU.
If they want an agent that updates production content overnight, the answer is no until you have staging, backups, capability scoping, and an approval step. The follow-up post is how to harden that path. Most sites should never turn it on.
Nought’s WordPress work is the surrounding platform — Suite, Nought.io, Local — and custom engineering when the CMS is not enough. MCP sits in the engineering bucket: a way for our tools, and a client’s tools, to interrogate a site we are already allowed to touch.
A sensible first setup
Start on a local copy. Nought Local exists to make that copy host-neutral; any honest local environment will do.
Create an application user that is not an administrator. Give it the capabilities the tools need and nothing else. If the agent only needs to read pages and list plugins, it does not need install_plugins.
Expose a short tool list. Read posts, list plugins, get site health, maybe list ACF field groups. Do not start with update_option, install_plugin, or delete_post.
Point the MCP client at that local URL only. Keep production credentials out of the agent’s config. If the agent needs a fact from production, an engineer fetches it.
Write down what you enabled. Future you will not remember whether create_post was on.
Then use it for a real task: “list the plugins that are not in our composer file”, “find pages still using this shortcode”, “summarise the ACF groups on this site before we plan a FieldCraft run”. If those tasks are faster than clicking, keep the server. If the agent spends tokens wandering, shrink the tool list.
The test
WordPress MCP is worth adopting when it shortens inspection and local change. It is not worth adopting when it is a story about AI on a brochure site.
Give the agent the same access you would give a new contractor on day one: a staging site, a limited role, and a ticket. If you would not give that contractor production admin, do not give it to a protocol either.