Headless CMS MCP support went from novelty to table stakes in about five months, and almost nobody wrote it up as a single event. Each vendor announced its own server, each announcement was read as a product update, and the pattern underneath went uncovered.
The pattern is that an entire product category agreed on how software agents talk to it, without anyone convening a standards body. That is rare, and it happened faster than the surrounding permission thinking did.
What happened, in date order
Working from the vendors’ own announcements rather than secondary coverage:
Storyblok documents a production-ready MCP server on a page dated March 23, 2026.
Sanity ships an MCP server as a listed content-backend product, alongside an Agent Context feature its April 22, 2026 developer post describes as giving "you MCP tools for your content."
Strapi released its MCP server on May 28, 2026, published a guide to extending it with custom tools on June 13, and declared it generally available on July 30 in v5.49.0. The GA announcement describes it as "a stable surface to wire agents to your content" that lets you "Expose your content types as agent-callable tools, scoped by an Admin token."
Contentful announced on July 21, 2026 that "Remote MCP is now generally available, bringing Contentful into AI workflows at enterprise scale."
Five months, four vendors, one protocol, no coordination. If you were choosing a headless platform in February on the basis of agent support, that criterion no longer distinguishes anything, because headless CMS MCP support is now the floor rather than the differentiator.
These are not read-only integrations
This is the part that gets lost when each announcement is read separately, and it is the reason this matters more than a typical feature roundup.
Storyblok’s own capability list is the clearest. Its server lets a connected agent "Fetch and filter content entries across spaces," then "Create, update, or publish stories programmatically," then "Manage component schemas and content models," then "Query and manipulate assets, folders, and media," and finally "Inspect and modify space configuration." The documentation is explicit that this is for "real work, not toy examples."
Read that list again as a permissions grant rather than a feature list. Publishing is in it. Content modeling is in it. Space configuration is in it. That is not an integration that fetches your blog posts. That is administrative access to the repository, delivered over a protocol, to a caller whose behavior is probabilistic.
Headless CMS MCP standardized the wire, not the authority
Here is the gap. The tier standardized on the transport and did not standardize on authority.
Strapi scopes its server with an Admin token, which is a clear and auditable choice but a coarse one: the token carries whatever that admin can do. Storyblok’s surface reaches space configuration. Sanity routes through its own Agent Context layer. Contentful frames its release around enterprise scale, which implies its existing role model does the work.
Four reasonable designs, four different answers to "what is this agent allowed to do," and no shared vocabulary for expressing the answer. MCP itself specifies how a client and server talk. It does not specify what a server should be willing to do, which is correct scope for a transport protocol and unhelpful if you were hoping the protocol would solve authorization for you.
So the interoperability you gained is real and the portability you might have assumed is not. Swapping one headless CMS MCP server for another means rewriting your permission model, even though the wire format is identical. Our earlier survey of what each platform will and will not let agents do went through this platform by platform, and the picture has only gotten broader since.
Why the headless tier moved first
Not an accident, and worth understanding if you are waiting on a platform that has not shipped one.
A headless CMS is already an API-first product. Its content is already modeled as structured, addressable resources; its access is already token-based; its consumers are already remote. An MCP server over that is a new façade on an existing surface, not a new architecture. The work is real but it is bounded.
A traditional CMS is a different proposition, because the content model, the rendering layer, the plugin ecosystem and the permission system are entangled by design. Exposing an ability safely means deciding what "safely" means across all of it. That is the work WordPress has been doing in the Abilities API, and it is slower for structural reasons rather than cultural ones.
Which is to say: headless being first is a statement about coupling, not about ambition.
What WordPress and Drupal are doing instead
The two large open-source platforms are visibly not following the same path, and the divergence is instructive.
WordPress is building a capability surface first. The Abilities API landed as bare infrastructure and has since gained the machinery that makes it governable: a default-deny exposure flag, filtering, validation filters and an invocation hook. The protocol adapter sits on top of that, deliberately, rather than the other way around.
Drupal is leading with governance and editorial control, running its AI work as a public initiative with published roadmaps that separate AI used inside the CMS from external agents acting on it. That framing puts the authorization question before the connectivity question.
Both approaches are slower to produce a working agent integration than shipping a server over an existing API. Both produce a clearer answer to who approved a change. Neither has yet produced a governance model that a headless CMS MCP deployment could simply adopt, which is the gap the whole category is now standing in.
The question nobody is asking
A content repository’s value to an agent ecosystem depends partly on being a neutral place to put content. That neutrality is a structural property, and structural properties change hands.
This tier has been consolidating for years, and a repository owned by a larger platform vendor has different incentives than an independent one, particularly about which agents get privileged access and which integrations get built first. None of that is hypothetical in adjacent markets. The same question is live one layer up, in the routing tier that sits between applications and AI models, where deliberately neutral switching layers have become acquisition targets for companies with their own commercial positions. It is the same shape of problem we traced through open versus closed model strategies: neutrality is a property of ownership, not of architecture.
I am not going to attach that argument to a specific pending transaction here, because the reporting I could verify does not support naming one. The general point stands on its own and is worth holding: if your agent architecture assumes your content repository is a neutral party, write down what changes if it stops being one.
What to do before you turn one on
Five positions, in the order I would take them.
Find out whether your server can publish. Not whether it can write. Whether the change becomes visible to the public without a human step. If yes, that is the control you need to think hardest about.
Give the agent its own identity, never a shared admin token. A token scoped to a real administrator inherits everything that administrator can do, including the parts nobody intended to delegate. A dedicated, minimally scoped identity also makes the audit trail mean something.
Check whether configuration is in scope. Content mistakes are recoverable. Content-model and space-configuration mistakes are migrations. If the server can reach schema or config, that is a different risk class and deserves a different answer.
Log invocations on your side. If the only record of what an agent did lives in the vendor’s system, you cannot reconstruct an incident on your own timeline.
Do not treat protocol support as portability. Headless CMS MCP gave the tier a common wire format and nothing more. The authorization model is not. Budget for rewriting it if you migrate, which is the same lesson the headless landscape comparison reached about every other supposedly interchangeable layer.
Frequently Asked Questions
Which headless CMS platforms now have MCP servers?
Storyblok documents a production-ready server on a page dated March 23, 2026. Sanity lists an MCP server as a content-backend product alongside its Agent Context feature. Strapi released one on May 28, 2026 and marked it generally available on July 30 in version 5.49.0. Contentful announced general availability of Remote MCP on July 21, 2026. The practical effect is that headless CMS MCP support no longer differentiates platforms in this tier.
What is MCP, briefly?
Model Context Protocol is a specification for how an AI client and an external tool server exchange capabilities and calls. It gives agents a consistent way to discover what a system can do and to invoke it, instead of every integration being bespoke. It governs the conversation between client and server. It deliberately does not define what a given server ought to permit, which is left to the implementer.
Can these servers publish content, or only read it?
Several can publish. Storyblok’s documented capabilities include creating, updating and publishing stories programmatically, plus managing component schemas and inspecting and modifying space configuration. Others expose content types as callable tools scoped by an administrative token. Read-only is not a safe default assumption, so check the specific capability list for your platform before enabling anything.
Does using MCP make my CMS choice portable?
Less than you would hope. The protocol is common, so the mechanics of connecting an agent look similar across vendors. The permission model underneath is not standardized, so what an agent is allowed to do, how that is scoped, and how it is audited differ substantially. Migrating between MCP-enabled platforms still means redesigning authorization even though the transport is identical.
Why did headless platforms ship this before WordPress or Drupal?
Mostly architecture. A headless CMS already exposes structured content over a token-authenticated API to remote consumers, so an MCP server is a new façade over an existing surface. In a traditional CMS the content model, rendering, plugins and permissions are deliberately entangled, so exposing capabilities safely means answering harder questions first. WordPress is building a governable abilities layer beneath the adapter, and Drupal is leading with governance, which are slower routes to a clearer answer.
What is the single biggest risk?
Granting an agent an administrative token and discovering later that the scope included publishing or configuration. The failure is rarely dramatic. It looks like content appearing without review, a field quietly retyped, or a schema change that breaks a downstream build. Giving the agent its own narrowly scoped identity and logging every invocation on your side addresses most of it.
Should I enable an MCP server at all?
For internal, authenticated workflows with a human approval step before anything publishes, the value is real and the risk is manageable. Content operations at volume is a genuinely good fit. What deserves more caution is any configuration where untrusted input can reach the agent’s context, because at that point the permissions you granted become the blast radius of a prompt injection rather than a productivity feature.
Does this mean agents can now edit my live site?
Only if you let them, but the capability is present in several products by default once connected. The determining factors are which token the server runs under, whether that token can publish, and whether your workflow requires a human transition between draft and live. If publishing is reachable and no human step exists, then yes, an agent can change what the public sees without anyone approving it.
