WordPress MCP vs Headless CMS MCP: Which Fits AI Agents?

WordPress MCP now has an official route: the Abilities API, which arrived in WordPress 6.9, plus the MCP Adapter that turns abilities into tools an agent can call. Good. Headless CMSs reached that point earlier with first-party servers of their own, while git-based sites avoid much of the same mess by forcing every agent edit through a pull request before it can reach production. None of these stacks is safe by default. The real difference is where the safety lives: in the box, or in the work you do around it. This post compares stacks rather than plugin against plugin, then gives you a scorecard and a cautious view on where agent-run sites may live by 2027.

What MCP changes: your site gets an agent that can write

Read-only MCP is a better-mannered search box. An agent fetches posts, summarises them and spots gaps, and if it gets the work wrong, the site is not damaged. Nothing breaks.

Write access is different. Once a server exposes create, update, publish and delete tools, the agent becomes a working user of your site, with every right its token carries. It can rewrite a pricing page at 3am. It can publish a draft nobody approved, and it can be pushed towards either mistake by text it reads on the way. More on that shortly.

CMS choice therefore stops being mostly about editors and templates. It becomes a permissions question, and four sub-questions do most of the hard work.

1. How finely can you scope what the agent is allowed to do?
2. Can it stay in draft, or does every write go live?
3. Is there an audit trail, and can you roll back?
4. Can a human see the result before the public does?

This is no niche worry now. The UK AISI counted publicly released MCP tools rising from around 5,000 to 177,000 over a year, with downloads going from 80,000 to 14 million. That is a lot of servers to trust, or refuse to trust. If you want a routine for making that call, I wrote one in vetting Claude Code skills, plugins and MCP servers, and the broader picture of running MCP in production is in the MCP servers production stack post.

WordPress, the official route: the Abilities API and the MCP Adapter

The Abilities API landed in WordPress 6.9. It gives core, themes and plugins a standard way to declare what they can do, with input schemas and permission callbacks attached. The MCP Adapter sits above that layer. It is described as the official WordPress package for MCP integration, lives under the WordPress GitHub organisation, and belongs to the AI Building Blocks for WordPress initiative. Its job is narrow but important: expose abilities as MCP tools, resources and prompts.

What the README documents:

• HTTP and STDIO transports, plus a McpTransportInterface for custom protocols. Clients connect through WP-CLI over STDIO, or by pointing an HTTP client at /wp-json/mcp/mcp-adapter-default-server.
• A feature it calls granular permissions: transport authentication per server and permission checks per ability.
• Abilities are private by default. Setting meta.public (or meta.mcp.public) to true exposes one.
• The default server offers three meta-tools: mcp-adapter/discover-abilities , mcp-adapter/get-ability-info and mcp-adapter/execute-ability.
• Pluggable error handling and observability through McpErrorHandlerInterface and McpObservabilityHandlerInterface.

Private by default is the right instinct. An ability nobody marked public cannot be reached by an agent, however clever the prompt may be. Now look at what is absent from that list: no draft-only agent role, no built-in approval step, no audit log. The observability hooks are a place to build one. They are not a finished audit trail.

Draft control lives inside the abilities. Someone has to write them. A third-party plugin, MS WordPress Abilities, shows the shape of that work rather well. It registers 29 abilities (26 custom, plus three core ones opted into MCP visibility) and offers a two-step staged update, preview-post-update then apply-post-update , while patch-post-content needs no staging. Sensible design. It is still that author's choice, not WordPress's. Per the same README, core and the official AI plugin only ship a handful of abilities out of the box.

It is also still settling. An issue opened on 18 March 2026 pointed out that the adapter README still talked about needing the Abilities API after it had merged into core (issue 150). On 24 June 2026 a contributor commented there that new core and site abilities belong in the AI plugin and the Abilities API, not on the adapter, and that many adapter docs still teach the older model of registering arbitrary abilities and setting mcp.public. Then, on 5 February 2026, a WordPress AI maintainer said he knew of no directory of plugins implementing Abilities API or MCP support (discussion 204). The plumbing is official. The catalogue of safe, useful abilities remains thin.

WordPress, the plugin route: plenty of choice, one thin security record

The other WordPress route is a plugin that ships its own MCP server. Names that appear on vendor comparison pages include Easy MCP AI, WPVibe, Novamira, Royal MCP, miniOrange Secure MCP Server and AI Engine. I am treating them as a category here. No ranking. I am also not repeating their feature claims as fact. One caution matters: the popular comparison pages are run by plugin vendors who list themselves, so read them as marketing with a table attached.

What the category offers is speed. Install the plugin, paste a token into your AI client, and you get tools for posts, media and often users and settings. What it costs is trust. You are handing a third-party author an endpoint that can act as a WordPress user, on a PHP site with a full admin area sitting behind it.

The only public security record I am citing here belongs to one plugin, AI Engine:

• CVE-2025-11749. In versions up to 3.1.3, with the No-Auth URL option enabled, the MCP bearer token leaked through the site's public REST routes. Unauthenticated attackers could authenticate to the MCP endpoint and create administrator accounts. Fixed in 3.1.4, and published to NVD on 5 November 2025 (SentinelOne's write-up, which places the leak at the /mcp/v1/ endpoint and says no verified public exploit code has been confirmed).
• CVE-2026-8719. Published 17 May 2026, rated high (CVSS 8.8). In version 3.4.9 the MCP OAuth bearer-token path did not check administrator capability, so a subscriber-level user with a valid token could reach admin-level MCP tools and become an administrator (GitHub advisory).
• A longer list. WPScan lists many more, including an MCP user tools account takeover on multisite (fixed in 3.6.1) and administrator account creation via CSRF (fixed in 3.6.6).

Be fair about what this proves. It is one plugin. Popular plugins draw scrutiny, which is partly why this one has a record, and an empty record elsewhere is not evidence of safety. Still, the pattern matters. Both headline bugs are authorisation failures at the MCP door, exactly where an agent receives its power. Remember that part.

Headless CMS MCP servers: Sanity, Strapi, Contentful and Payload

Headless platforms built their MCP servers around the data model. Not around a PHP admin. That difference shows in the documentation.

Sanity

Sanity runs a hosted server at https://mcp.sanity.io over Streamable HTTP, with OAuth by default and token auth as an option. Agents can run GROQ queries, manage releases and patch documents with awareness of your schema. Setup is npx sanity@latest mcp configure . The older local @sanity/mcp-server package is deprecated. That is the current route.

The docs describe draft-first writing: create_documents makes drafts unless you pass a releaseId , patch_documents saves to the draft or release version, and published content is never modified directly. Publishing is a separate tool. Patches to each document apply as a single transaction. A personal token shares your role and links you to changes in the revision history, while a token set in the Authorization header acts within its own role and scope. There are two catches. The server also exposes development and project administration (schema deployment, datasets, CORS origins), so scope the token carefully. And create_release does not schedule anything, which must happen in Studio or the HTTP Actions API.

Strapi

Strapi's MCP server is built in and runs inside your own instance. It first appeared in v5.47.0 and reached general availability in v5.49.0 (Strapi blog, 3 September 2026). By default it is off: server.mcp.enabled is false. It authenticates with admin API tokens and exposes find, create, update, publish and unpublish tools per content type. A token can never exceed its owner's permissions, and deactivating the owner revokes it. It does not create content types or upload media; those still go through the REST API (Strapi).

Contentful and Payload

Contentful publishes an official open-source MCP server (MIT licence, npm package @contentful/mcp-server) that lets agents manage entries and assets, update content types and automate jobs like tagging and migrations. It needs a management access token and a space ID (Contentful). A separate community server exists and points back to the official one. Payload adds MCP through an official plugin rather than a standalone server. That is as far as I will go on Payload here.

If you are weighing Sanity against WordPress more broadly, Sanity vs WordPress for enterprise covers the non-MCP side. Start there for that part of the decision.

Git-based Jamstack: the pull request is the safety net

The third pattern has no CMS server at all. Content lives in the repo as Markdown, MDX or typed JSON, and the site is Astro or Next.js. A coding agent edits files. It opens a pull request, the host builds a preview deploy, and a human reads the diff before merging. Vercel and Netlify both do git-based deployment and preview deploys, which is all this pattern needs from a host.

That pull-request loop is not exotic. Next.js documents how it supports AI coding agents, and a Microsoft Azure Static Web Apps tutorial shows the standard wiring: a GitHub Actions workflow that triggers on pull request opened, synchronize, reopened and closed, with a separate job to tear the preview down. It is ordinary delivery machinery. That is part of the appeal.

Why it suits agents is simple. Every change is a reviewable diff. Nothing reaches production until a person merges. Rollback is a git revert. The public site is static output, so there is no admin login for a stolen agent token to reach.

The costs are real, though. Non-technical editors get friction, because git is not their tool. Nothing here is a documented MCP server with a security record; the agent is a coding agent with repo access, so your exposure is the scope of its git token and whatever its shell can touch. Supply-chain hygiene still applies. I covered that in Next.js, Astro and Nuxt security in 2026.

MCP risks on any stack, and the controls that contain them

The NSA published a Cybersecurity Information Sheet on MCP security in June 2026, and Microsoft wrote up the state of MCP security in 2026. Strip away the vocabulary and four risks keep coming back.

• Inherited permissions. The agent can do whatever its MCP server's credentials can do. An admin token means an admin agent.
• Tool poisoning. Tool descriptions are read by the model, so a malicious or compromised server can hide instructions in them. That is why third-party servers deserve a review before install.
• Prompt injection. Content the agent reads (a comment, a scraped page, a support ticket pasted into a draft) can carry instructions. The agent may obey them with its own write access.
• Over-privileged tokens. Convenience pushes people to hand over one broad token. Don't.

The controls are dull. They work. Give the agent least-privilege tokens, prefer read-only or draft-only scopes, and put human approval in front of publish and delete. Keep audit logs you will actually read. Rotate tokens when anyone leaves. None of this is stack-specific, and that is the point. The stack only decides how much of the work is already done for you.

The agent-readiness scorecard

Here is the comparison in one place. Ratings come from documented features and the public record, with the sources named above. Nobody ran these stacks through a test suite for this table. Treat it as a documented comparison, not a lab result.

Strong means the documentation covers it by default. Partial means documented but incomplete, or backed by only a short record. Depends on setup means the stack does not decide. Your configuration does. Weak means documented problems.

Why each rating, briefly.

WordPress + Adapter. Permissions are strong because every ability carries its own check and abilities are private until marked public. Draft control depends on the abilities you install, as the staged-update example showed. Audit is partial: observability interfaces exist, but a native audit log does not. Authentication is partial, with per-server transport auth documented at a high level. The record is partial because the package is young and its docs are visibly mid-migration.

WordPress plugins. Nothing is uniform across a category, so most cells depend on the plugin. The record is weak where documented: the AI Engine entries above, and only those. That distinction matters.

Sanity. Role-scoped tokens, draft-by-default writes, releases and revision history earn the strong ratings. Preview is partial because a release is a staging concept, but the MCP server cannot schedule or publish releases. The record is partial in the sense of short. Not bad.

Strapi. Per-content-type tools and owner-bound tokens are strong on permissions and authentication. Publish and unpublish are separate tools, and the server stays off until you switch it on. Audit and preview depend on how you run your instance. Self-hosting also means patching is yours.

Contentful. The official server needs a management token and space ID, which reads as broad access, so I rate permissions and authentication partial. Draft handling, audit and preview depend on how you configure spaces and roles. The important work is in that configuration.

Payload. An official plugin exists. Beyond that, I have no primary documentation to rate against, so every cell reads as depends on setup. That is a gap in what I can verify. It is not a verdict.

Git-based Jamstack. Strong across four columns because the pattern itself provides them: branch-level repo permissions, a pull request as the publish gate, git history and reverts, preview deploys. Authentication depends on the coding agent and its git token. The record is partial because there is no CMS admin surface to attack. Agent tooling still carries the same MCP risks as everything else.

How to choose today, by situation

You have an existing WordPress estate

Stay put and be strict. Use the official adapter, mark only the abilities you need as public, and write or choose abilities that stage changes before applying them. A broad third-party plugin with an admin-capable token is the riskiest setup in this whole comparison. If you want to loosen WordPress from the front end first, headless WordPress development is a middle path.

You are starting a new build

If agents will help run it, start with headless or git-based. Sanity or Strapi give you drafts and scoped tokens out of the box. Astro or Next.js in a repo gives you diffs and previews. That is a strong default for new work.

Your content team is large, or non-technical

A team of editors who live in a visual interface will not enjoy pull requests. Headless with a proper editing studio suits them better, provided the agent is confined to drafts. WordPress's editor remains genuinely good here. That is a point in its favour.

You have compliance needs

Ask where the audit trail lives and who owns it. Git history is a strong answer. Sanity's revision history is another. For WordPress, you will be building logging yourself. Self-hosted options (Strapi, WordPress) keep data in your infrastructure but put patching on you, while a hosted server shifts that burden to the vendor.

Come 2027: why Jamstack may be the better home for AI-run sites

This section is opinion, not a finding, and I hold it loosely.

Why Jamstack may pull ahead. Content is structured and typed. Every agent change can be a diff that a human reviews. Preview deploys show the result before it goes live. Rollback is a git revert. The public site has no admin surface for a stolen agent token to reach. Agents are good at editing files and bad at being trusted, and this setup is built for exactly that combination.

Why WordPress may not lose. It has the largest install base and talent pool. The Abilities API is now in core, with an official adapter beside it. Plugin vendors iterate fast. Fast iteration fixes a lot, even if it created the CVEs above.

What WordPress would need. MCP in core, with abilities mapped to capabilities by default. Draft-only agent roles. A native audit log. A better security record for MCP plugins. That is a short list, and none of it is impossible.

If that view has you weighing a move, the guide to leaving WordPress is where to start.

Practical line: for a new site that agents will help run, start Jamstack or headless. For an existing WordPress estate, use the official adapter with least-privilege abilities rather than a broad third-party plugin. Be boring here.

FAQ

Can I run WordPress MCP in read-only mode?

Yes, in principle. Abilities are private by default, so expose only the abilities that read data and leave anything that writes unregistered or unmarked. The adapter does not have a single read-only switch. The discipline sits in which abilities you register.

Which AI clients can connect?

For WordPress, anything that speaks MCP over HTTP or STDIO (via WP-CLI). Sanity's documentation lists Claude Code, Cursor, VS Code, Lovable, Replit and v0 as compatible clients, and OAuth sessions there typically expire after 7 days. Client choice is not the hard part.

Is a hosted MCP server safer than a self-hosted one?

It trades one risk for another. A hosted server like Sanity's moves patching to the vendor, but you rely on their scoping and your token hygiene. A server inside your instance, like Strapi's, keeps everything in your infrastructure. Updates are your job.

Should I build my own MCP server instead?

Only if you need a narrow set of tools the official ones do not offer. A small, purpose-built server with three tools is easier to reason about than a broad one. There is a walkthrough in building an MCP server with Supabase and TypeScript. Keep the surface small.

The sharpest caveat is the dull one: an agent inherits everything its token can do, and the only public MCP security record in this comparison is one WordPress plugin's list of CVEs, which is reason enough to scope tokens before choosing a stack. The ratings above come from documentation and public advisories, not from testing. Treat the stack choice as secondary to the permissions model.