MCP servers for CMS systems: AI agents in your CMS

What is an MCP server for a CMS?

MCP stands for Model Context Protocol, an open standard for connecting AI applications to external tools and data. In a CMS workflow, the AI client connects to an MCP server that exposes operations backed by the CMS API. The agent can discover available tools and inspect their inputs instead of guessing how a page is stored.

A prompt can ask for a better introduction; a tool can retrieve the actual introduction, its content type, and the fields around it. If writing is allowed, another call can save the proposed replacement. The server and CMS must enforce those permissions. A helpful tool description, or a prompt saying “be careful,” does not prevent an unauthorized write.

Instead of asking for text to paste somewhere later, you can ask for one specific change to one specific draft. You still need to check the target and the result. MCP provides a common way to use tools, not a guarantee that the agent chooses the right one.

What can an agent do in your CMS?

A structured CMS holds more than paragraphs: titles, reusable blocks, product fields, media, FAQ entries, and SEO metadata. An agent becomes useful when it can inspect those relationships before proposing a change. A page with a missing image field is a different problem from an image URL that exists but no longer points to a valid asset.

Depending on the available tools and permissions, useful tasks include:

• Finding outdated pages, empty descriptions, or inconsistent fields and reporting the exact entries that need attention.
• Preparing a new page or an update as a draft, with enough context for an editor to review it.
• Checking asset references and metadata against the underlying content model rather than judging only the visible page.
• Reviewing headings, internal links, and structured data as part of an ongoing SEO process.
• Recording what was proposed, what was changed, and what still needs approval.

Give the agent one of those jobs first. A list of concrete findings is easier to assess than a request to “optimize the entire website.” Read-only access is often enough to discover whether the workflow is useful before you grant any writing rights.

Recurring workflows need more than MCP

The repeated work is often the real reason to connect an agent. You might review Search Console data monthly, identify a page whose search intent needs attention, and prepare a draft for an editor. Or you might check whether new product entries have the required fields before anyone publishes them. For the first example, automating SEO with AI explains the measurement cycle in more detail.

MCP does not supply the schedule, the editorial rules, or a reliable bulk-processing engine. Those belong to the surrounding workflow. In particular, Storyblok’s current MCP documentation distinguishes exploratory work driven by a language model from repeatable, high-volume work. It recommends the CLI for the latter, with dry runs, idempotency guarantees, and reference mapping through manifests.

That is a useful boundary when someone proposes generating thousands of pages. Use an agent to explore the content model, investigate exceptions, or help prepare a plan. Use deterministic scripts or the appropriate CLI for a repeatable batch, then validate the output. Reliable source data and meaningful differences between pages still matter; automation does not make thin, repetitive content worth publishing.

A draft-first workflow in practice

This website uses Git, not a CMS

The website you are reading is a static Astro site built from Content Collections. Its articles and pages live as files in Git, with no CMS runtime. Hermes helps us prepare changes in that repository; schemas, builds, browser checks, and review guard the publication process. The website without a CMS article explains the choice, and the Straffe Sites case study shows the project.

For a client site with a CMS, the same review principles apply, but the change lands in a CMS draft rather than an MDX file. That is part of our approach to AI automation with clear rules and human control. A typical content round looks like this:

• Read the agreed data and identify the exact page or story. For SEO, use a defined reporting period rather than a few days of movement.
• Describe the issue and propose a small change, including the fields that must stay untouched.
• After authorization, save the change as a draft. Do not treat permission to edit as permission to publish.
• Read the draft back and compare the stored fields with the intended values. Review the copy, preview, links, and any build output.
• Publish only after approval, then verify the live page. For SEO changes, wait at least 30 days before measuring again.

What the recorded Storyblok session shows

The terminal below contains the original Dutch transcript from a real Storyblok MCP session recorded on September 9, 2026. It preserves the original Dutch output unchanged, not translated or rerun for this English article. It describes a separate CMS workspace, not the architecture of this website or a fresh check of that workspace today.

In that session, the agent scanned 22 articles and a hub page. A filter intended to find empty fields returned every story, so the agent checked the individual records instead. It found an image field with an asset ID of zero and an empty alt description, located the existing asset, and prepared a draft repair. Readback then confirmed the stored values and unpublished changes. A second draft edit corrected the alt wording after a language-rule check; nothing was published. This is one draft repair, not evidence of a bulk content rollout.

Storyblok MCP for headless websites

Storyblok’s MCP server gives a compatible AI client access to its Management API. The current documentation describes a discovery flow: search for the relevant operation, inspect its parameters and request schema, then execute it. Read, mutating, and destructive operations use separate tools. The historical transcript above records the operation names used in that session; it is not a current tool-reference guide.

For a new connection, follow the official Storyblok setup instructions. Storyblok recommends OAuth and asks you to choose the permissions and spaces the client can access. Grant only what the task needs. Review the operation, parameters, and target before a write, and check the returned record afterward. An access token is not something to paste into an article, a prompt archive, or a Git repository.

For our Storyblok website development projects, we can help define those permissions and the draft-to-publication workflow. If you are still evaluating the architecture, start with how a headless CMS works and the headless CMS service. MCP adds a way for agents to work with structured content; it does not replace the frontend or the editor’s judgment.

When a custom MCP server makes sense

Your CMS may not have a suitable MCP server, or its existing server may expose far more than your team needs. If the platform has a usable API, a custom layer can offer a smaller set of operations. For example, it could let an agent find an article and update selected draft metadata without offering publication or deletion tools.

Content teams may need page and asset lookups. Developers may need access to content models, validation rules, or webhook settings. Marketing may need controlled campaign drafts. Those are different permissions, not reasons to give every agent an administrator account. Agree on the allowed targets, fields, and failure behavior before implementing the tools.

At Straffe Sites, we can build that layer around a CMS, a Storyblok space, a Directus installation, or a custom content API. An editor should be able to inspect each change without having to reconstruct the agent’s whole conversation. If an ordinary script already performs the job predictably, adding a language model and MCP may only add review work.

What to check before allowing writes

A CMS connection that can change content deserves the same care as any other integration with write access. I would not start with an unattended publishing workflow. Start with a task whose result you can compare directly with the original, and check these boundaries:

• Permissions: limit access to the necessary spaces and operations. Keep publish and delete access separate from routine draft work.
• Draft behavior: verify which version an operation updates. Do not assume a tool named “update” is draft-only.
• Logging: keep the target, proposed change, previous values, and readback together so an editor can understand what happened.
• Validation: check required fields, image references, links, and structured data. A successful API response is not a content-quality check.
• Untrusted content: treat text found in a CMS entry as data, not as instructions that can broaden the agent’s permissions.
• Human review: check search intent, brand wording, and commercial claims before publication, and keep a way to recover the previous version.

The recorded session makes the reason concrete: the filter did not behave as expected, and the first alt description needed a correction. Both would have been easy to miss if the workflow stopped at the first successful tool call.

Start with one change you can verify

MCP makes a CMS accessible to an agent, but the useful result is a change you can explain and check. Pick one recurring task, restrict the tools, prepare a draft, and read it back. Expand the workflow only when reviewing it remains manageable.

If you want help choosing that first task, contact us. We can review your CMS setup or include the integration in a website development project. You do not need to hand an agent the keys to every page to get useful work out of it.