"Claude Code CMS" is now a real search, a real category of blog posts, and a real thing people ship. The phrase hides a question worth answering directly: can you actually run a content site's CMS through Claude Code? This is the maximum-signal version — products and numbers named, no warm-up.
Short answer: Claude Code is a coding agent, not a CMS. On its own it has no content model, no drafts, no version history, no publish step, and no preview a non-developer can use. It edits files and calls tools. That's the whole primitive.
What people mean by "Claude Code CMS" is one of four arrangements that make the agent behave like a CMS. Three of them bolt Claude Code onto something that already exists. One of them throws the CMS out entirely. They have very different failure modes, and it's worth being precise about which one you're actually choosing.
1. Bolt an MCP server onto a headless CMS. This is the dominant pattern and the one most "Claude Code headless CMS" posts describe. You add a Model Context Protocol server and Claude Code can drive the CMS through natural language. ElmapiCMS ships an MCP server with 17 tools — list and create collections, define fields, CRUD entries, upload assets. Strapi has a community MCP for schema work and seeding. Sanity runs the most serious one in the category — a remote server at
2. Drive a traditional CMS over its REST API. No MCP, just scripts. With WordPress you create an application password and Claude Code does almost anything you'd do in
3. Roll your own mini-CMS. A slash command plus a few admin routes, or a packaged product like Claude CMS — plain PHP/MySQL, one
4. Throw the CMS out — markdown in the repo. No CMS at all. Claude Code edits
Each pattern has a different sharp edge. These are the ones that show up in real projects, not in the launch demo.
MCP tool definitions load on every request, not when you use them. They ride along with every message. The numbers are documented and not small: one breakdown clocks a five-server setup at roughly 55,000 tokens before a single message, and others report 66,000+ — a third of a 200K context window gone before the conversation starts. It was enough of a problem that it became a tracked bug in Claude Code itself. Claude Code now defers tool definitions with a tool-search step, which helps — but the bolt-on pattern still pays a content tax measured in context, every session, whether or not you touch the CMS.
Claude Code asks before it acts. For a developer that's a safety feature; for someone editing copy it's friction. As one non-technical guide puts it, the most annoying part is coming back to "Can I edit this file?" — type a prompt, walk away, return to find it waiting. A CMS for editors can't have a permission dialog between a marketer and a typo fix.
Claude Code assumes you're comfortable in a terminal, with git, with files. The skill files that make it sing are only as good as the expertise behind them — as one practitioner notes, the good SKILL files are good because the author already had thirteen years of editorial experience to encode. A marketer doesn't onboard to a blank-slate agent in an afternoon. Someone technical has to build the workflow first, every time.
The most concrete production bite is in this build log: posts statically generated at build time returned a 404 until the next redeploy, forcing a switch from static generation to dynamic server rendering. The deeper point that surfaced: content has to be server-rendered, because "LLMs often can't" parse client-rendered pages — and in an AEO world where answer engines read your HTML directly, a CMS that ships client-rendered content is invisible to the very systems sending you traffic.
This is the thread running through patterns 1, 2, and 3. In every MCP-on-a-headless-CMS setup, the LLM is a client calling an API that was designed for a human editor. The content models, the query language, the permissions, the editorial workflow — all of it was shaped around a person clicking through a dashboard. Sanity's server is genuinely the best-built version of this, and it is still an agent reaching into an editor's house through a window. As we argued at length in the manifesto: an AI layer bolted onto an editor built for humans is not an architecture built for agents. It is AI-enabled legacy architecture.
Flip the relationship. Instead of the agent being a client to a human's API, the agent is the primary actor and the human plugs in through it. That's the premise agntcms is built on, and it's a direct answer to each break above.
It is a complete CMS on day one, not a coding agent you have to teach: every edit is a draft first, publishing takes a dated snapshot so rollback is one step, assets are content-addressed with duplicate detection, and you can swap a section's layout while the page stays valid. The public site is frozen and fast — none of the editing machinery ships to visitors, and no AI runs in production, so it's a plain, server-rendered Next.js site that answer engines can read.
It does not bolt content onto MCP. There are no MCP CRUD tools for content — the agent reads and writes JSON in
And the editing surface is built for the editor, not the developer. In Claude Code Desktop, the chat and the live preview sit in one window — point at a block, "make this hero warmer," the agent edits it, the preview refreshes. For a non-developer, onboarding is roughly "open the project and describe what you want." The same controls a person drives by talking are the ones your automation calls for a scheduled refresh, a bulk translation, or an SEO pass — the same surface, not a webhook stitched to a vendor SDK. Bring your own models. MIT-licensed, self-hosted, no per-seat meter.
Five ways to answer "Claude Code as a CMS," and where each one fits:
No. Claude Code is a coding agent that edits files and runs tools. It becomes CMS-like only when paired with a content backend — a headless CMS over MCP, a REST API, a hand-built admin, or an agent-native framework that gives it a content model, drafts, history, and a preview.
Not easily with raw Claude Code — it expects comfort with terminals, git, and permission prompts. A non-developer needs a layer on top that hides the machinery: a content model, a preview, and skills that already encode how to add a page or roll one back. That layer is the difference between a coding agent and a CMS.
Beyond the model usage, the hidden cost is context. MCP tool definitions load on every request; a multi-server setup can consume 55,000–66,000+ tokens before you type a word — roughly a third of a 200K window. Architectures that drive content through native file tools instead of MCP CRUD avoid that per-request tax.
Yes. WordPress via the REST API and application passwords; Sanity via its 40+-tool MCP server; Contentful and Strapi via their own integrations. In every case the agent acts as a client to a CMS API that was designed for a human editor.
An AI-enabled CMS adds an assistant on top of an editor built for humans — the data, schemas, and workflow are unchanged, and the agent calls them as a guest. An agent-native CMS inverts it: the agent is the primary actor the system is shaped around, and the human plugs in through it.
If a team of developers who all write code runs the site, markdown in the repo is often the cleanest answer — that's the cursor.com lesson. If non-developers need to edit, and you still want drafts, history, previews, and content ops, raw markdown is too thin and a headless-plus-MCP setup makes the agent a second-class client. An agent-native CMS is built for exactly that middle.
"Claude Code CMS" works — the question is what the agent is plugged into. Bolt it onto a headless CMS and it's a guest paying a token tax to reach an editor's API. Script a REST API and you're back in the dashboard. Roll your own and you own it forever. Strip to markdown and only developers can edit. Agent-native is the option where the agent isn't a guest at all — the CMS is built around it, the editor onboards by talking, and the public site stays a fast, server-rendered page an answer engine can read.
For most content sites — marketing pages, landing pages, corporate sites, content portals — that's the better deal. Read the manifesto for the long argument, what makes agntcms different for the plain-words tour, Claude Code for marketing if you're on a marketing team, or the docs to try it. The code is open on GitHub under MIT.
github.com/agntcms
Can Claude Code be a CMS?
Short answer: Claude Code is a coding agent, not a CMS. On its own it has no content model, no drafts, no version history, no publish step, and no preview a non-developer can use. It edits files and calls tools. That's the whole primitive.
What people mean by "Claude Code CMS" is one of four arrangements that make the agent behave like a CMS. Three of them bolt Claude Code onto something that already exists. One of them throws the CMS out entirely. They have very different failure modes, and it's worth being precise about which one you're actually choosing.
The four ways people use Claude Code as a CMS today
1. Bolt an MCP server onto a headless CMS. This is the dominant pattern and the one most "Claude Code headless CMS" posts describe. You add a Model Context Protocol server and Claude Code can drive the CMS through natural language. ElmapiCMS ships an MCP server with 17 tools — list and create collections, define fields, CRUD entries, upload assets. Strapi has a community MCP for schema work and seeding. Sanity runs the most serious one in the category — a remote server at
mcp.sanity.io with 40+ tools and schema-aware Agent Actions. Credit where it's due: these work, and Sanity's is a real investment. The catch is structural, and we'll get to it.2. Drive a traditional CMS over its REST API. No MCP, just scripts. With WordPress you create an application password and Claude Code does almost anything you'd do in
wp-admin through the REST API — publish posts, upload media, edit pages from the terminal. It works. You are scripting the dashboard you were trying to escape.3. Roll your own mini-CMS. A slash command plus a few admin routes, or a packaged product like Claude CMS — plain PHP/MySQL, one
install.php, an MCP connector into claude.ai, 15+ tools for page CRUD, files, SQL, and backups. Changes deploy straight to production with no staging phase. Fast to start, and you now own a CMS you built in an afternoon and have to maintain forever.4. Throw the CMS out — markdown in the repo. No CMS at all. Claude Code edits
.md/.mdx files and a static framework renders them. The reference case: in December 2025, Lee Robinson migrated cursor.com off a headless CMS and back to markdown with agents — three days, $260 in tokens, 322,000 lines deleted. His line lands: "With AI and coding agents, the cost of an abstraction has never been higher." Simple, fast, and you've just handed every content edit to whoever can use git.Where it breaks
Each pattern has a different sharp edge. These are the ones that show up in real projects, not in the launch demo.
MCP token overhead eats your context before you type
MCP tool definitions load on every request, not when you use them. They ride along with every message. The numbers are documented and not small: one breakdown clocks a five-server setup at roughly 55,000 tokens before a single message, and others report 66,000+ — a third of a 200K context window gone before the conversation starts. It was enough of a problem that it became a tracked bug in Claude Code itself. Claude Code now defers tool definitions with a tool-search step, which helps — but the bolt-on pattern still pays a content tax measured in context, every session, whether or not you touch the CMS.
Permission prompts break the flow
Claude Code asks before it acts. For a developer that's a safety feature; for someone editing copy it's friction. As one non-technical guide puts it, the most annoying part is coming back to "Can I edit this file?" — type a prompt, walk away, return to find it waiting. A CMS for editors can't have a permission dialog between a marketer and a typo fix.
It's built for developers, not editors
Claude Code assumes you're comfortable in a terminal, with git, with files. The skill files that make it sing are only as good as the expertise behind them — as one practitioner notes, the good SKILL files are good because the author already had thirteen years of editorial experience to encode. A marketer doesn't onboard to a blank-slate agent in an afternoon. Someone technical has to build the workflow first, every time.
Static builds 404 your new posts — and LLMs can't read client-rendered pages
The most concrete production bite is in this build log: posts statically generated at build time returned a 404 until the next redeploy, forcing a switch from static generation to dynamic server rendering. The deeper point that surfaced: content has to be server-rendered, because "LLMs often can't" parse client-rendered pages — and in an AEO world where answer engines read your HTML directly, a CMS that ships client-rendered content is invisible to the very systems sending you traffic.
The structural one: the agent is a guest in a house built for humans
This is the thread running through patterns 1, 2, and 3. In every MCP-on-a-headless-CMS setup, the LLM is a client calling an API that was designed for a human editor. The content models, the query language, the permissions, the editorial workflow — all of it was shaped around a person clicking through a dashboard. Sanity's server is genuinely the best-built version of this, and it is still an agent reaching into an editor's house through a window. As we argued at length in the manifesto: an AI layer bolted onto an editor built for humans is not an architecture built for agents. It is AI-enabled legacy architecture.
What agent-native actually changes
Flip the relationship. Instead of the agent being a client to a human's API, the agent is the primary actor and the human plugs in through it. That's the premise agntcms is built on, and it's a direct answer to each break above.
It is a complete CMS on day one, not a coding agent you have to teach: every edit is a draft first, publishing takes a dated snapshot so rollback is one step, assets are content-addressed with duplicate detection, and you can swap a section's layout while the page stays valid. The public site is frozen and fast — none of the editing machinery ships to visitors, and no AI runs in production, so it's a plain, server-rendered Next.js site that answer engines can read.
It does not bolt content onto MCP. There are no MCP CRUD tools for content — the agent reads and writes JSON in
content/ with native file tools, guided by skills the project already ships. Skills first, files second. So there's no per-request token tax for content operations, and no separate API to keep in sync with your code — your content store and your app are one system.And the editing surface is built for the editor, not the developer. In Claude Code Desktop, the chat and the live preview sit in one window — point at a block, "make this hero warmer," the agent edits it, the preview refreshes. For a non-developer, onboarding is roughly "open the project and describe what you want." The same controls a person drives by talking are the ones your automation calls for a scheduled refresh, a bulk translation, or an SEO pass — the same surface, not a webhook stitched to a vendor SDK. Bring your own models. MIT-licensed, self-hosted, no per-seat meter.
Claude Code CMS approaches at a glance
Five ways to answer "Claude Code as a CMS," and where each one fits:
- MCP on a headless CMS — real content model (the vendor's), drafts and history depend on the vendor, onboarding is developer-led, and the per-edit context cost is high because tool definitions load on every request. Best for teams already standardised on Sanity or Strapi.
- REST API (WordPress) — full legacy content model with drafts and history, developer-led onboarding, low-to-medium token cost. Best for sites already on WordPress.
- Roll-your-own / Claude CMS — you build and maintain the content model and history yourself, developer-led, low-to-medium cost. Best for tinkerers and small projects.
- Markdown in the repo — no content model, version history is just git, you must know git to edit, lowest token cost. Best for developer teams who all write code.
- Agent-native (agntcms) — content model, drafts, and dated-snapshot history built in; onboarding is "describe what you want"; low per-edit cost because content moves through native file tools, not MCP CRUD. Best for marketing and content sites.
FAQ
Is Claude Code a CMS?
No. Claude Code is a coding agent that edits files and runs tools. It becomes CMS-like only when paired with a content backend — a headless CMS over MCP, a REST API, a hand-built admin, or an agent-native framework that gives it a content model, drafts, history, and a preview.
Can a non-developer edit a website with Claude Code?
Not easily with raw Claude Code — it expects comfort with terminals, git, and permission prompts. A non-developer needs a layer on top that hides the machinery: a content model, a preview, and skills that already encode how to add a page or roll one back. That layer is the difference between a coding agent and a CMS.
How much does it cost to run a CMS through Claude Code over MCP?
Beyond the model usage, the hidden cost is context. MCP tool definitions load on every request; a multi-server setup can consume 55,000–66,000+ tokens before you type a word — roughly a third of a 200K window. Architectures that drive content through native file tools instead of MCP CRUD avoid that per-request tax.
Does Claude Code work with WordPress, Sanity, or Contentful?
Yes. WordPress via the REST API and application passwords; Sanity via its 40+-tool MCP server; Contentful and Strapi via their own integrations. In every case the agent acts as a client to a CMS API that was designed for a human editor.
What's the difference between an AI-enabled CMS and an agent-native CMS?
An AI-enabled CMS adds an assistant on top of an editor built for humans — the data, schemas, and workflow are unchanged, and the agent calls them as a guest. An agent-native CMS inverts it: the agent is the primary actor the system is shaped around, and the human plugs in through it.
Should I use Claude Code with a headless CMS or with markdown files?
If a team of developers who all write code runs the site, markdown in the repo is often the cleanest answer — that's the cursor.com lesson. If non-developers need to edit, and you still want drafts, history, previews, and content ops, raw markdown is too thin and a headless-plus-MCP setup makes the agent a second-class client. An agent-native CMS is built for exactly that middle.
The short version
"Claude Code CMS" works — the question is what the agent is plugged into. Bolt it onto a headless CMS and it's a guest paying a token tax to reach an editor's API. Script a REST API and you're back in the dashboard. Roll your own and you own it forever. Strip to markdown and only developers can edit. Agent-native is the option where the agent isn't a guest at all — the CMS is built around it, the editor onboards by talking, and the public site stays a fast, server-rendered page an answer engine can read.
For most content sites — marketing pages, landing pages, corporate sites, content portals — that's the better deal. Read the manifesto for the long argument, what makes agntcms different for the plain-words tour, Claude Code for marketing if you're on a marketing team, or the docs to try it. The code is open on GitHub under MIT.
github.com/agntcms