Your product got renamed, the homepage still shows the old name, and the fix is sitting fourth in next sprint's backlog. An AI-powered headless Content Management System (CMS) can remove routine content changes from that queue, and Strapi, an open-source headless CMS, ships a built-in MCP server that supports routine publishing and localization through AI content operations.
Engineering sets up the connection once and defines what the AI can touch; after that, your team can handle approved routine tasks through an AI assistant at the pace the campaign calendar demands. Engineering retains responsibility for schemas and integrations while also setting the guardrails.
In brief:
- Strapi 5.47.0 and later include a built-in MCP server (generally available since 5.49.0). It's built into Strapi and turned off by default.
- Marketing teams can create, update, publish, and localize entries through plain-language prompts in Claude Desktop, Claude Code, Cursor, Windsurf, or any MCP client that supports Streamable HTTP.
- Engineering handles a one-time setup: turn on the server in config and issue a scoped Admin token that defines exactly what the AI can do.
- Permissions are enforced at four layers, so the AI does not receive tools outside the token's scope. The same restriction applies to fields and locales. Drafts stay drafts until someone with publish rights publishes them.
These controls let marketing handle routine work while engineering retains responsibility for setup and governance.
The Bottleneck: Content Operations That Depend on Engineering
At a CMS-driven company, a landing page may need a pricing update, while a legal disclaimer may have changed. Every one of those tasks lands in a developer's queue behind actual feature work. The change itself takes minutes. In this scenario, the wait takes days or weeks because sprint priorities were set before the campaign existed.
Content bottleneck research shows that the volume side of this problem is getting worse. Forrester's State of B2B Content Survey, 2025 identifies inefficient content creation and review as the top challenge for content teams, driven by fragmented workflows and manual governance.
Every small change still routes through a person who knows the system, and that person has other work. Strapi's MCP server lets approved content tasks bypass the engineering queue. Instead of filing a ticket, a content manager types "Update article abc123, change the title to 'Hello Strapi'" into an AI assistant, and the change happens.
What an AI-Powered CMS Changes for Marketing Teams
Strapi's MCP server is built into the headless CMS itself. It first appeared in Strapi 5.47.0 and became generally available in 5.49.0. It's a built-in feature that works in both development and production environments, and it's opt-in: a developer must explicitly turn it on before Strapi exposes the endpoint.
MCP stands for Model Context Protocol, an open standard for connecting AI assistants to external systems. The official introduction describes it this way: "Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems." The AI assistant your team already uses, whether that's Claude Desktop, Claude Code, Cursor, or Windsurf, can connect directly to your Strapi instance and act on content there.
An assistant connected through MCP can act on content in Strapi. It uses the same permission system that governs the Admin Panel to create or update an entry. With publish rights, it can also publish an approved version. Routine content operations can proceed without waiting for a developer to handle each task. Engineering still owns the schema and the Strapi integrations. It also sets the guardrails; your team owns the daily work inside them.
What Your Team Can Do Without Writing Code
Once connected, the assistant works from plain-language prompts. The Strapi documentation includes examples such as "Create a new article titled 'Hello World' with body 'First post'" and "List the 5 most recent articles." It also shows the prompt "Delete article abc123." No API calls, no query syntax, no code.
Draft and Update Campaign Content
A campaign manager can ask the assistant to create new entries, and when Draft and Publish is active on the Content-Type, everything the AI creates lands as a draft, not a live page. That default matters: it means the AI's output enters your existing review flow instead of bypassing it.
Updates work the same way. "Update article abc123, change the title to 'Hello Strapi'" modifies one entry; a prompt asking for the five most recent articles returns a paginated list your assistant can then work through.
The list tool supports filtering and sorting on scalar fields, so "show me every article containing the old product name" is a realistic request, and revising each match becomes a conversation rather than a spreadsheet of ticket numbers. The drafts sit in Strapi ready for whoever reviews them, exactly as if a person had typed them into the Admin Panel.
Publish and Schedule on Your Timeline
When a draft is approved, publishing it is one prompt: "Publish article abc123." The docs describe the result plainly: it "changes the entry status to published." Three content management tools cover the publishing lifecycle: publish, unpublish, and discard_draft, which reverts draft changes back to the published version. All three require the publish permission on the token, and all three work without a developer touching anything.
Authorized publishing puts campaign timing in your team's hands. Once your team approves a launch announcement, an authorized user can publish it without waiting for the next deployment window, and if something goes out wrong, unpublish pulls it back just as quickly.
Localize for Multiple Markets
Teams running content in multiple languages get locale support built in. When Internationalization (i18n) is active on a Content-Type, MCP tools accept an optional locale parameter, so a prompt like "Create an article in French with the title 'Bonjour le monde'" creates a draft with the locale set to fr.
Per the Strapi documentation, "The AI client sees which locales are available in each tool's schema, so you can ask it to create or update content in a specific language." Omit the locale and Strapi uses the default.
Locale access is also permission-scoped. A token might allow reading content in en and fr but only creating content in en, which is useful when one market has a stricter review process than another. The locale of an existing entry is fixed at creation. To move content into a new language, you create a new localized entry rather than editing the locale on an old one.
A Day in the Life: Marketing Content Operations With AI
On a hypothetical launch afternoon, a company is renaming its flagship plan, and the new name needs to appear across a handful of blog posts and product pages in English and French before tomorrow's announcement.
Under the old workflow, the team files a ticket and probably hears "we can fit it in Thursday." With the MCP connection, the content lead opens their AI assistant and starts with discovery: list the articles that mention the old plan name. The list tool supports filtering with operators like $contains, so the assistant returns the matching entries with their document IDs.
The lead walks through the entries prompt by prompt: update this article's title and revise the intro paragraph in that one. Each change lands as a draft. For the French market, the same requests carry a locale: create the updated announcement in French, revise the fr version of the pricing explainer. Because i18n is active and the token permits both locales, the assistant handles each language as asked.
An hour in, every affected entry has an updated draft. The lead opens the Strapi Admin Panel, reads through each one (this is the review gate, and it stays human), fixes a phrase the AI got slightly off, and then returns to the assistant: publish these five, in both locales.
The entries go live. If the team is on an Enterprise plan running Strapi 5.52.0 or later, every one of those writes is recorded in Audit Logs with an origin key set to mcp, so anyone auditing later can distinguish AI-driven changes from Admin Panel edits.
In this hypothetical scenario, the workflow avoids an additional engineering handoff during the launch. The developer who configured the connection remains responsible for the schema and token permissions. The developer also sets the guardrails rather than handling each individual content change.
The One-Time Setup Your Developer Handles
The initial MCP setup belongs with engineering. It has three steps, and the MCP configuration is small enough to fit in a code review comment.
- Turn on the server. A developer turns on the server in
config/server.js. It's off by default, so nothing is exposed until this happens. - Issue a scoped token. They issue a scoped Admin token from Settings in the Strapi Admin Panel and select only the permissions your team needs: which Content-Types, which actions, which fields, and which locales. This token defines the boundary between marketing autonomy and engineering governance. The MCP server authenticates only with Admin tokens; Content API tokens are rejected.
- Connect the AI client. They add the Strapi MCP endpoint and the token to the client's config file. The docs include ready-made snippets for Claude Desktop, Claude Code, Cursor, and Windsurf, and any client supporting the MCP Streamable HTTP transport can connect. The server runs as a route on Strapi's existing HTTP server, so there's no separate process for anyone to maintain.
After those three steps, your team can handle approved routine content tasks without opening an engineering ticket. Adjusting what the AI can access later is a token permission change rather than a project, while schema and integration changes remain with engineering.
Keeping Control: Permissions and Guardrails
An AI assistant accesses production content through a scoped token whose permissions Strapi enforces at four layers:
- Tool visibility: "When an AI client connects, Strapi checks the Admin token's permissions and only exposes tools the token has access to." If the token doesn't grant
deleteon articles, the AI doesn't see a delete tool for articles at all. The client is not offered that capability. - Field filtering: Per the docs, "If the token grants
readonArticlebut excludes thebodyfield, the AI client will not see or receivebodycontent." - Locale filtering: The third layer applies the same narrowing to locales.
- Runtime enforcement: "Each handler calls Strapi's permission checker at runtime to verify access on the specific document being read, written, or published." Strapi checks condition-based rules, such as only updating entries you own, on every call.
These layers keep the client's available actions within the token's scope.
The MCP server uses the same permission system as the Strapi Admin Panel. Two properties follow from that design. Revocation is immediate in practice: the stateless server authenticates every request independently, and permission changes take effect on the next request. And ownership is enforced, since each token is bounded by its owner's permission ceiling and revoked upon owner deactivation.
Strapi recommends: "Create dedicated Admin tokens for each AI client or use case. Use the most restrictive permissions that still allow the AI to accomplish its task." Your team gets autonomy inside the fence; engineering decides where the fence is.
Where to Keep a Human in the Loop
The MCP specification takes a clear position on oversight: there should always be a human in the loop who can deny tool invocations, per the MCP tools spec. Strapi's known limitations tell you exactly where that human belongs.
Review before publishing. The publish tool is a discrete call with no built-in confirmation dialog, so the enforcement mechanism is the token. For Content-Types where editorial review is non-negotiable, withhold publish permission from the AI's token entirely. The AI can then draft and revise all day, but going live requires a person in the Admin Panel or a separate human-controlled token. For lower-stakes content, keeping publish on the token and confirming with the assistant before it fires works well too.
Handle media manually. The docs are direct about this one: "Media fields accept existing media asset references but the MCP server cannot upload new files." New campaign images go into the Media Library or through the upload API first; the assistant can then reference them. If your operation is image-heavy, plan an asset workflow alongside the MCP one.
Check structured content by hand. Structured block fields pass through as untyped arrays, so an editor should verify block structure in the Admin Panel after the AI creates an entry that uses them. Slug and UID fields aren't auto-populated either; include the slug in your prompt or have your developer add a lifecycle hook.
Account for these constraints when defining the pilot scope. They support a sensible division of labor: the AI moves text, humans approve what ships.
Getting Your Team Started
A small pilot is usually enough to get started.
Start by agreeing with engineering on which Content-Types to open up. Blog posts and internal announcements are good first candidates; the pricing page is not. AI pilot guidance is consistent on starting with low-risk, high-impact content before expanding, and Bain's 2026 research across 1,125 sales and marketing leaders found that companies redesigning workflows around AI capture 30% more productivity than those layering it onto existing processes. Picking the right starting scope is that redesign in miniature.
Request a scoped token. Your developer creates it in minutes through the Admin Panel settings and grants only the Content-Types and actions you agreed on. Locale access follows that agreed scope. read and update on one Content-Type is a perfectly good starting scope; you can add create and publish as trust builds, since expanding a token is a settings change, not a project.
Spend a week on low-risk edits. Start with typo fixes and metadata updates on existing posts. Then try copy refreshes. This builds the team's prompt habits and surfaces any schema quirks in structured blocks and custom fields before a campaign deadline depends on the workflow. Once the routine work feels routine, scale to campaign operations like the multi-entry, multi-locale launch scenario above, and look at the Strapi Marketplace for plugins that round out the rest of your stack.
Split Content Operations Where They Belong
An AI-powered headless CMS with a built-in MCP server splits content operations along the line where they should have been split all along: engineering configures the system and sets the guardrails once, and marketing runs the daily work of drafting, updating, publishing, and localizing at its own pace. Strapi's implementation enforces the split through the scoped Admin token and the four-layer permission model. These controls and draft-first creation use the same governance machinery as the Admin Panel.
Pick one recurring task that currently waits on a developer, perhaps the monthly stats refresh or the post-launch copy sweep, and run it through the MCP workflow first. If you're already using the Strapi platform on version 5.47.0 or later, the feature is a config change away; the feature documentation and MCP server docs have everything your developer needs for the one-time setup.
