How to use Claude Code with a headless CMS

With a headless CMS, Claude Code works on two separate things. The front end, the site visitors see, is code in a git repository, so Claude edits it like any project and a person reviews the diff. The content lives in the CMS, and Claude reaches it through the vendor's MCP server. Sanity, Contentful, Storyblok and Strapi all publish official MCP servers as of October 2026, and all four can write content. Several can publish or delete it too.

That split decides the workflow. Code changes go through branches, previews and pull requests. Content changes go through the CMS's own safety nets: drafts, non-production environments or datasets, and your Claude Code ask rules on publish and delete tools. This guide compares the four servers using only what each vendor documents, then gives a setup that keeps a person in charge of what goes live.

Code vs content: two workflows

Schema changes sit in between. Some CMSs define content models in code, others in the CMS, and several MCP servers can change models directly. Treat a model change like code: plan it, test it on a copy, and have a person approve it.

The four MCP servers compared

"None shown" means the vendor's docs page doesn't label the server beta, preview or GA. Check the page again before a big job, since these servers change often.

What each server can do

The details below come from each vendor's own docs. They matter most for one question: which tools can publish or delete, so you know what to put behind an ask rule.

Sanity

Sanity's MCP docs say agents "can execute GROQ queries, manage releases, and patch documents with full awareness of your schema." For Claude Code, Sanity gives claude mcp add Sanity -t http https://mcp.sanity.io --scope user, or npx sanity@latest mcp configure, which detects Claude Code and sets it up using your logged-in Sanity CLI user.

Useful safety details: create_documents creates drafts unless you pass a release, Sanity says patches are saved "to the draft or release version, never directly to published content," and publishing is a separate tool, publish_documents. Sanity says scheduling, publishing and deleting a release aren't available through MCP and must be done in Sanity Studio or its HTTP API. Other tools can deploy a schema or a Studio, create datasets and manage CORS origins, so keep those behind ask rules too. Most tools are standard API calls that don't use AI credits; the exceptions are generate_image and transform_image, which you can switch off in your client.

Contentful

Contentful's MCP docs describe a remote, hosted server and a local, open-source one that "expose the same core toolset." Claude Code: claude mcp add --transport http contentful https://mcp.contentful.com/mcp, then a browser sign-in where you choose spaces and environments. EU customers use the EU endpoint instead.

The remote server has two permission layers: your own Contentful permissions, and an allow-list in the Contentful MCP app where admins pick which tool categories (entries, assets, content types, environments and so on) work in each environment, each as read-only or read/write. The local server has only one: every call runs as the owner of the personal access token. The write tools are broad, including publish_entry, delete_entry, create_content_type and delete_environment. The allow-list works by category, not by single tool, so set production categories to read-only, as Contentful suggests starting out, and use ask rules for individual publish and delete tools.

Storyblok

Storyblok's server "exposes the Management API and makes it available to any MCP-compatible AI client." Its setup page gives claude mcp add --transport http Storyblok https://mcp.storyblok.com/mcp, then /mcp to sign in. Instead of one tool per endpoint, it uses a search, describe and execute flow: reads go through execute_readonly, create and update calls through execute_mutating, and delete calls through execute_destructive, which "Requires explicit confirmation from the user before use." That split makes ask rules simple: put the mutating and destructive tools behind them.

Storyblok's own advice is worth repeating: "results are non-deterministic and unsuited for repeatable, high-volume work." Use the MCP for one-off changes and exploring, and Storyblok's CLI for repeatable jobs. That fits Claude Code well: have Claude write a CLI or API script you can review and re-run, rather than making hundreds of MCP calls. Storyblok's older GitHub repository for the server is archived; use the endpoint on its docs page.

Strapi

Strapi's MCP docs say it "includes a built-in Model Context Protocol (MCP) server" that can "create, read, update, delete, publish, and unpublish content directly through Strapi's Content Manager." It needs Strapi 5.47.0 or later, is off by default, and is enabled in your server configuration. Because it runs on your own Strapi server, the endpoint is your server's address plus /mcp, such as http://localhost:1337/mcp in development.

Strapi's Claude Code example passes the Admin token in a header: claude mcp add strapi-mcp --transport http http://localhost:1337/mcp -H "Authorization: Bearer YOUR_ADMIN_TOKEN". Each session gets that token's permissions, and Strapi only shows tools the token can use: a token without delete on a content type gets no delete tool for it. So create a token with only the content types and actions the job needs. Publish and unpublish tools appear only on content types with Draft and Publish turned on. Known limits include dynamic zone fields passed as untyped arrays. Strapi's page is inconsistent on media: its limitations list says the server can't upload new files, while a separate Media Library section describes write tools from version 5.54.0. Test media handling on your version before relying on it. Audit logging of MCP actions is an Enterprise feature from 5.52.0.

A safe setup for any headless CMS

1. Point Claude at a non-production copy. A Sanity dataset, a Contentful environment, a Storyblok space or a local Strapi instance that isn't your live content.
2. Grant the narrowest access. Pick only the spaces or environments needed at sign-in, or a token with limited permissions.
3. Add ask rules on publish and delete tools. Claude Code permission rules can name one MCP tool, in the form mcp__ plus the server name, two underscores, and the tool name. Ask rules make Claude Code stop and ask, even in auto mode. Our guide to MCP servers for website teams covers rule scoping.
4. Keep tokens out of shared files. Claude Code's default local scope keeps a server's settings private. If a team shares a project .mcp.json, use its environment variable expansion for tokens instead of writing them in.
5. Write the rules down. Your CLAUDE.md should name the content model, the environment to use, and "never publish or delete without asking." Our guide to writing a CLAUDE.md for a website covers the format.
6. Ask for a report before changes. List the entries that would change and how, review, then apply.
7. Review in the CMS. Check drafts and version history before anything is published.

One more risk: content is input. If an entry contains text that looks like instructions, an agent reading it could act on it. Anthropic notes that servers which fetch external content can expose you to prompt injection. Our guide to prompt injection risks on websites explains how to reduce it.

Good jobs for Claude Code on a headless site

For moves between platforms, see moving content with Claude Code. If your front end is Next.js, Claude Code for Next.js sites covers that side, and our headless CMS hub covers choosing a CMS in the first place.

When to use the CMS's own tools instead

• Repeatable bulk jobs. A reviewed script using the vendor's CLI or API is easier to test and re-run than many MCP calls. Storyblok recommends exactly this.
• Editorial work. Writers and editors should keep using the CMS's editor, with its previews and workflows.
• Publishing and scheduling. Leave these in the CMS, in a person's hands. Sanity, for one, leaves scheduling and publishing a release to Sanity Studio or its API.

Conclusion

A headless CMS is a good match for Claude Code, because the front end is ordinary code and all four major CMSs here publish official MCP servers for content. Keep the two workflows separate: code through git and reviewed pull requests, content through drafts and non-production environments, with narrow tokens and ask rules on every publish and delete tool. If you'd like help building a headless site or moving content into one, see our Claude Code development services. More guides are in our Claude Code Guide.

Frequently asked questions