DatoCMS MCP Server: Setup, Tools, and Real Workflows

A content editor asks Claude Code to pull the latest five product records from DatoCMS, rewrite the SEO descriptions in a tighter voice, and save them as drafts for review. A minute later the drafts are sitting in DatoCMS waiting for an editor’s sign-off. No browser tab on the CMS, no copy-paste, no developer in the loop.

That is what the DatoCMS MCP server makes possible. The setup is a single command. The interesting part is how the server is built, because DatoCMS made some deliberate choices that change what is safe to hand an AI agent.

This post is the DatoCMS companion to the same pattern we wrote about for Storyblok. The principle is identical. The DatoCMS implementation is specific enough to be worth its own walkthrough, and it changed enough in 2026 that the old how-tos floating around are already wrong.

What is the DatoCMS MCP server?

The DatoCMS MCP server is an official Model Context Protocol server that lets an AI assistant read and edit your DatoCMS content. The current version runs remotely at mcp.datocms.com, authenticates over OAuth, and exposes a small set of tools that an agent like Claude Code can call directly.

MCP is the open standard that lets an assistant talk to an external system through a defined set of tools. DatoCMS implements that standard on top of its Content Management API, so instead of you copying record IDs into a chat window, the agent queries the project itself. The work that used to be three tools and a spreadsheet becomes one conversation.

One thing to get straight before you start. There used to be a local npm package, @datocms/mcp, that you installed and ran on your own machine. That package is deprecated. DatoCMS replaced it with the hosted server, and the old GitHub repo now points you there. If you find a tutorial that tells you to pnpm add @datocms/mcp-server or pass a --mode=draft flag, it is describing something that does not exist. Use the remote server.

How does the DatoCMS MCP server work?

It works in three layers: discovery, planning, and execution. The agent first explores your project and loads API documentation, then commits to specific method names, then runs a type-checked TypeScript script inside a sandbox. The script batches many operations into one call instead of firing dozens of separate API requests.

This is the part worth understanding, because it is unusual and it is the reason the integration holds up on a real project.

Most CMS integrations expose the raw API. The DatoCMS Content Management API has more than a hundred endpoints, and handing all of them to a model is how you get malformed calls and confident nonsense. DatoCMS went the other way. The server ships a deliberately small tool set, fewer than a dozen tools, and forces the agent through a sequence.

First the agent discovers what exists. It searches your projects, lists the available API resources grouped by theme, and pulls your content models with their fields, relationships, and nested blocks. Then it plans. Before it writes any code, it has to load the real method signatures and reference them, which means it commits to method names that actually exist rather than inventing plausible ones. Then it executes. The agent writes a complete TypeScript program and the server runs it.

The script-based model is the second clever choice. Rather than the agent making one API call, looking at the result, and making another, it writes one program that does the whole job and runs it once. That batches the operations, cuts the round-trips, and burns far fewer tokens. The script is type-checked before it runs, so a typo in a field name fails fast instead of halfway through a bulk edit.

And it all runs in a sandbox. Network access is restricted to the DatoCMS APIs, your project’s own asset storage, and a short whitelist of image services. The script never sees your real API token. The sandbox injects credentials at the network layer, so a script cannot read the token and exfiltrate it. Static analysis rejects scripts that lean on any or unknown types, cast through never, use TypeScript ignore directives, or call a method that was not declared during planning. That is a lot of guardrail for something an AI wrote, which is exactly the point. Sandboxing decides how safely the agent runs, and it is a separate question from which operations we keep away from an agent entirely.

How do you set up the DatoCMS MCP server?

Point your MCP client at the remote server. In Claude Code, that is one command: claude mcp add --transport http DatoCMS https://mcp.datocms.com. The first call opens an OAuth login in your browser, you approve access to a project, and that is the setup. No token to copy, no Node.js to install.

For VS Code, the equivalent is:

code --add-mcp '{"name":"DatoCMS","type":"http","url":"https://mcp.datocms.com"}'

For Cursor, Windsurf, and ChatGPT in developer mode, you add the same HTTP server through that client’s MCP config. The shape is the same in most clients:

{
  "mcpServers": {
    "DatoCMS": {
      "type": "http",
      "url": "https://mcp.datocms.com"
    }
  }
}

The OAuth flow runs through oauth.datocms.com using the standard MCP OAuth handshake. Your MCP client holds the token. Nothing lands on your filesystem, which removes the whole category of leaked-token problems that the old local-token setup created.

Then try it. Restart your client and ask: “List the last five records of model blog_post and show me their slugs and titles.” The agent discovers the schema, plans the call, runs a read-only script, and hands back the data. Once that works, ask it to draft something, and watch the approval prompt appear before any write leaves the agent.

What tools does the DatoCMS MCP server give an agent?

The tools split along the three layers. The discovery and planning tools are read-only and map the territory. The execution tools run the scripts. The whole set is small on purpose, so the agent reasons about a handful of capabilities rather than a hundred endpoints.

The ones you will see in use:

• search_projects finds projects across your account and organization.
• list_api_resources lists the available API resources grouped by theme, so the agent knows what it can touch.
• get_api_methods pulls the real method signatures with TypeScript definitions, which is what the agent has to reference before it writes a script.
• get_schema returns your content models, fields, relationships, and nested blocks.
• upsert_and_execute_safe_script runs a read-only script. Non-GET requests are blocked at the sandbox layer, so this one cannot change anything.
• upsert_and_execute_unsafe_script runs a script with full create, update, and delete permission. This is the one that needs an approval gate.
• view_script shows a previously stored script.
• whoami confirms which account is signed in.
• report_api_issue sends a structured bug report back to the DatoCMS team.

The safe and unsafe split is the real governance boundary, and it is enforced in the sandbox rather than left to the model’s good behaviour. That matters more than it sounds, which is the next section.

Drafts, publishing, and the approval gate

The integration is only as safe as the friction around writes, and here DatoCMS gives you two real boundaries instead of one. The first is the safe-versus-unsafe script split. The second is DatoCMS’s own draft model. Together they mean an agent can do a lot of useful work without ever touching the live site.

DatoCMS separates a record’s draft from its published version at the API level. An agent can create a record or rewrite a field and leave it as an unpublished draft, and publishing stays a separate, explicit action. So the default working pattern is: the agent writes drafts, an editor reviews them in DatoCMS, a human publishes. The model never has to be trusted with the live site to be useful.

On top of that, three rules we apply on any project where an agent touches a real DatoCMS space:

1. Read auto-approves. Writes need confirmation. Publishing needs explicit confirmation. The three actions have different blast radii. The safe script handles all the read work with no friction. The unsafe script should sit behind a per-call approval in your MCP client. Treat a publish the way you treat a force-push to main.
2. Keep production and sandbox separate. DatoCMS sandbox environments exist so you can let the team try the workflow without any chance of a live-site mistake. Point the agent at a sandbox environment first. Move to the primary environment only once people are comfortable.
3. Keep the audit trail. Every change DatoCMS records carries a user attribution. An editor who finds a surprising change in three months should be able to ask who made it and when, and get an answer. The OAuth model keeps that attribution honest, because the agent acts as a real signed-in account rather than an anonymous token.

These are the same rules a sane DevOps team applies to any automation that touches production. The only difference is that the actor is a model instead of a CI job.

What is the DatoCMS MCP server good for?

It earns its keep on routine, structured work across many records: drafting variants, rewriting a field across a content set, introspecting the schema, and stitching together work that used to span several tools. The model handles the reasoning between steps. The team handles the calls that matter.

The patterns that pay off on a real project:

• Drafting record variants. Three versions of a hero, a CTA, a meta description, written into DatoCMS as drafts and reviewable before any of them go live.
• Field-level rewrites across many records. “Read every blog post tagged migration and rewrite the SEO description in a tighter voice.” The script opens a draft on each, you review them in DatoCMS. Because it is one batched script, a hundred records is one run instead of a hundred calls.
• Schema introspection and content modeling. “Show me every model that references the author model. Are any of them missing a fallback?” That kind of structured question maps cleanly onto DatoCMS’s typed schema, and get_schema answers it directly. We have written before about why strict data models make editors faster, and the same structure is what makes an agent reliable here.
• Bulk metadata work. Adding alt text, schema annotations, or category tags across a content set. Slower than a hand-written script, but you do not have to write the script.
• Cross-tool reasoning. Pulling a week of search analytics, mapping queries to the records that should rank for them, drafting an updated description against the right record. Three tools and a spreadsheet become one conversation.

The connecting theme is that the work is routine reasoning over structured content. That is precisely what the model is good at and what a typed CMS makes safe.

What are the limits of the DatoCMS MCP server?

There are hard sandbox limits and there are jobs it is the wrong tool for. As documented during the mid-2026 beta, each script runs up to 20 seconds on free plans and 60 on paid ones, against a weekly sandbox budget of 10 minutes free or 90 paid, and returns at most 32 KB of output. DatoCMS notes those numbers are provisional.

Those limits shape how you use it. A huge bulk migration that needs ten minutes of continuous execution does not fit in one script run, so you either chunk it or you do not use the MCP for it. The 32 KB output cap means you ask the agent to summarize and act rather than dump a thousand full records into the chat.

Then there are the jobs where an MCP server is the wrong tool, sandbox or not:

• Schema migrations. Renaming a field across an item type belongs in a proper Content Management API migration script with a dry run, version-controlled in your repo. The agent can help write that script. It should not be the runtime that performs it ad hoc.
• Multi-locale sync that needs glossary discipline. DatoCMS’s localized fields make AI translation tempting. Marketing copy is fine. Legal text, or anything where a glossary mistake is hard to spot, is not. We covered the trade-offs in translation workflows that don’t break your CMS.
• Anything where the audit trail matters more than the speed. Compliance edits, regulatory updates, contract terms. Run those through the UI so the change history reflects the human who made the call.
• Publishing without a human. Even with an approval gate available, the publish action should never be auto-approved. There is no version of “the agent publishes unsupervised” that ends well.

Being honest about this list is what makes the rest of it trustworthy. The MCP is a sharp tool for a specific shape of work. It does not replace your CMS.

Why this matters for content teams and AI agents

Your marketing team is already using AI tools. Giving them a clean, governed way to talk to DatoCMS turns that from a copy-paste habit into an actual workflow, with the CMS still enforcing every rule it always did. The structured-content model is what makes it safe rather than chaotic.

This is the practical version of an argument we have made before: websites now have two audiences. One is people. The other is the agents your own team points at your stack. The MCP server is how you serve the second audience without giving up the controls that protect the first.

And the reason it works on DatoCMS specifically comes back to structure. Records are typed. The model knows a field is rich text or a string before it touches it. Drafts and published versions are distinct, so a draft is genuinely safe. The schema is queryable, so the agent plans against reality instead of guessing. None of that is true on a free-text CMS, which is the whole case for structured content in an AI-first stack.

Where the DatoCMS MCP server fits a headless, structured-content stack

The MCP server is the cheap part. The component library underneath the schema is the expensive part, and it is the part that decides whether AI editing actually works on a real brand. The token model and the typed schema get you a safe connection. The rendered components are what keep the output on-brand.

This work is finished before the marketing team ever opens an agent. A development and design team builds the component library once, over months, and hands it over. The marketing team does not write frontend code, does not touch the Astro or Next.js components, does not edit DatoCMS block models. They operate the public surface, the agent and the drafts, and the rendered components handle the rest automatically.

What that looks like in DatoCMS:

• Every modular content block has one finished, brand-correct rendered implementation. The hero_block, feature_card, testimonial_block each map to a single component on the frontend. Layout, typography, spacing, colour are settled in code.
• Modular content fields constrain which blocks sit where. A page body accepts only page-level block types. The validator rejects a footer block inside a hero before the API call lands, so the agent cannot build something incoherent.
• Variants are separate models rather than free-form toggles. Two hero designs become two block types, both reviewed by design.
• A page-composition briefing lives alongside the project. A CLAUDE.md or equivalent, maintained by the dev team, specifies which blocks fit which page archetype, the order, the constraints to respect, and the brand voice rules for draft copy. The marketing team does not write it. They benefit from it.

This is the same principle as the Storyblok version of this post, applied to DatoCMS. The full argument for why the component library is the work that decides whether AI editing feels safe or chaotic lives in the Storyblok post.

Where this is heading

I think we are only months away from a working pattern where marketing teams publish daily without opening the DatoCMS back office UI. Drafts get written through the agent. Reviews happen in the existing preview. Publishing happens through the same agent with an explicit confirmation step.

DatoCMS is still doing all the work behind the scenes. The fields, the validation, the workflow, the audit log. What disappears is the surface. That shift does not happen because the AI gets better. It happens because the component library and the composition briefing are in place before marketing ever opens the agent. The MCP server is a weekend. The library plus the briefing is a quarter of design and engineering. Teams that start that work now will be publishing this way before the end of 2026.

This is not a case of AI replacing DatoCMS. DatoCMS is still where content lives. The visual editor, field validation, modular blocks, and workflow approvals all still happen there. What changes is the editing surface. Some edits happen in the UI because that is the right tool. Some happen through the agent because the team is already there. The choice is no longer browser tab versus terminal. It is which surface fits the edit.

Where to start

If you are running DatoCMS already, point Claude Code at mcp.datocms.com, approve access to a sandbox environment, and let one person on the team try it for a week. The friction points show up in days. Decide whether the draft-write pattern is worth rolling out broadly before you do.

If you are not on a headless CMS yet, this is one more reason to consider moving. Our headless website service covers what that move actually looks like, and the website subscription team handles the keep-it-running side, including the MCP wiring once it ships. Giving your team a clean way to talk to DatoCMS is one of the more concrete things you can do for them this quarter.