AI Blog Publishing: Draft, Review, and Publish in Strapi with Claude Desktop

You have a rough draft in a doc, a publishing slot tomorrow, and no time for clicking through a Content Management System (CMS) to get it live. This guide focuses specifically on the editorial draft-to-publish loop: it shows exactly how to publish a blog with AI on Strapi 5 without touching the Admin Panel for anything except the featured image.

Strapi is an open-source headless CMS, and its built-in Model Context Protocol (MCP) server lets Claude Desktop create, read, update, and publish blog entries directly in your Content Manager. Once a developer enables the Strapi MCP server and hands you an Admin token, the whole loop runs in one conversation: draft from notes, review the fields, revise by conversation, publish.

The workflow below assumes a Strapi 5 release with the built-in MCP server, and the same prompts apply to the generally available feature. Every operation Claude performs goes through the same Content Manager your team already uses, so nothing bypasses your roles, permissions, or Draft and Publish settings.

In Brief

• The MCP server exposes eight Collection Type tools (list, get, create, update, delete, publish, unpublish, discard_draft) that map cleanly onto a draft, review, revise, publish loop.
• New entries land as drafts automatically when Draft and Publish is enabled, so nothing goes live until you say so.
• Slugs, excerpts, and categories need explicit prompts. The server does not auto-fill unique identifier (UID) fields.
• New featured images still need to be uploaded through the Media Library before Claude can reference them.

Together, these points define which parts of the workflow stay in Claude Desktop and where the Admin Panel remains necessary.

The Draft-to-Publish Workflow at a Glance

The Strapi MCP server exposes a small, predictable tool surface, and each stage of the publishing loop maps to one or two of those tools. Strapi's documentation lists the prompts it supports under content management through prompts, and the table below arranges them by stage. Seeing the whole CMS AI workflow before you start makes each prompt below easier to place.

Which tools appear in Claude depends on the permissions on the Admin token. Strapi's launch post spells this out: a read-only token exposes only listing and reading tools, while a full-access token exposes the full create, read, update, delete, and publish surface.

One-Time Setup Before You Begin

Claude Desktop connects to Strapi through the built-in MCP server, which is disabled by default until a developer enables it once and pairs it with an Admin token; the full steps live in the Connecting Claude Desktop section of the docs. One requirement when you ask for the token is that it has to be an Admin token. Content API tokens return a 401.

Strapi announced the MCP server's General Availability.

Step 1: Draft Your Post from a Prompt

Start with the simplest documented form of the creation prompt, straight from the Strapi MCP docs:

Create a new article titled 'Hello World' with body 'First post'.

Claude calls the create tool and Strapi saves the entry as a draft. For a real post, you'll paste in more than a title and a one-line body. A prompt shaped like the one below does the job:

Here are my notes for a post on migrating a newsletter to Strapi. Write a
900-word article in a conversational tone with an H2 every 200 words or so.
Create it as a new article titled 'Moving Your Newsletter Archive to Strapi'
with the full text in the body field. Do not publish it.

The last sentence is an extra safeguard. When Draft and Publish is enabled on the Content-Type, entries are drafts by default, but they can also be created directly in a published state (for example, by specifying a published status when creating them via the API). Strapi's Claude Desktop guide puts it this way: "When using Draft and Publish on the Content-Type, new entries are always saved as drafts… it can also be created directly in a published state if the creation request specifies status: 'published'." Since Claude decides what to pass to the tool, telling it explicitly not to publish keeps that second path closed.

Strapi's Content-Type Builder offers two rich text types: Rich Text (Blocks) expects a nested array of paragraph and text nodes that Claude has to construct correctly, while Rich Text (Markdown) accepts plain Markdown. If your developer is still deciding on the article schema, a Markdown body field gives Claude less structure to get wrong.

Anthropic's own prompting guidance applies here too: "Be specific about the desired output format and constraints." Word count, heading cadence, tone, and the exact field to write into all belong in the first prompt. And if you write in more than one language, name the language outright ("Create an article in French") so Claude passes the correct content locale; the docs call this out because a French title alone leaves the locale ambiguous.

Step 2: Review the Draft in Strapi

Before you change anything, pull the draft back and read it. The content management tools that handle this are list and get. Two documented prompts cover most cases:

List the five most recent articles.

Show me article with ID abc123.

The first returns a paginated list, newest first, which is usually enough to spot the entry you just created and grab its ID. If you've lost track of the ID and remember only the title, there's no dedicated "find by title" parameter; the documented route is a list call with a filter on the title field. Ask for it in plain language and Claude builds the filter:

Find the article whose title contains 'Newsletter Archive' and show me the
full entry.

Behind that request, the list tool accepts Strapi filter syntax with operators like $eq, $contains, and $startsWith, plus sort, page, and pageSize (default 25, max 100). Filters only work on scalar fields, so you can search by title or a date, but not by the contents of a related category.

Once the entry is in front of you, read the body as your audience would. Strapi's Claude Desktop guide offers both options: "You can review the draft in the Admin Panel exactly as you would any other, or ask Claude to read it back to you first." Reading it back in chat is faster for catching a flat intro or a heading that doesn't match its section. The Admin Panel is better for seeing how the Blocks render.

While you're there, check three things the get response tells you. The status should read draft. The documentId is the persistent identifier Strapi 5 uses across locales and draft/published versions, per the Document Service API docs, so note it down for the rest of the session. And look at which fields came back empty; that list becomes your next prompt.

Add the Finishing Details

Slug, excerpt, and category are the fields most likely to be blank after Step 1, and the slug in particular catches people off guard. In the Admin Panel, a UID (slug) field auto-generates from its Attached field (the schema's targetField), so creators expect the same when Claude creates an entry. It doesn't happen. Strapi's custom tools post is direct about this: slug fields stay empty unless the prompt provides a value. Fill it explicitly with a follow-up:

Update article abc123: set the slug to 'moving-newsletter-archive-to-strapi',
set the excerpt to a two-sentence summary of the body, and set the category
to 'Tutorials'.

The models documentation limits the resulting UID to letters, numbers, hyphens, underscores, periods, and tildes. No spaces. If Claude proposes something with punctuation, correct it before it hits the field.

The category assignment is a relation write. Claude handles the syntax, as long as your token can read the Category Content-Type, per the MCP tools reference. If the category prompt fails, that missing read grant is the first thing to check with your developer.

Step 3: Revise with Follow-Up Prompts

The update tool changes only the fields you name and leaves everything else untouched, which is what makes conversational revision safe. The documented example is deliberately small:

Update article abc123, change the title to 'Hello Strapi'.

Strapi's docs don't publish examples of paragraph-level rewrites, but the mechanism is the same tool writing to the same body field, and Claude already has the current body in the conversation from Step 2. So the revision prompts you'd give a human editor work as written:

The intro of article abc123 is too formal. Rewrite the first two paragraphs
in a more direct, second-person voice and update the body.

Cut article abc123 down to about 700 words without dropping the section on
redirects.

In article abc123, the paragraph starting 'One common mistake' repeats the
point above it. Merge them and update the body.

A habit that saves cleanup: ask Claude to show the rewritten passage in chat before it writes to Strapi. Anthropic's prompting guidance also notes, "Examples are one of the most reliable ways to steer Claude's output format, tone, and structure." If the second paragraph has the tone you want, say "match the voice of paragraph two" rather than describing the voice abstractly.

Keep going until the draft reads the way you want. Claude can send only the changed fields in the update call, but from your seat it feels like editing by conversation.

If the post was already published and you're revising it later, the Draft and Publish docs explain what you'll see: saving draft changes to a published entry moves its status to Modified, the live version stays intact in the read-only Published tab, and nothing changes for readers until you republish. Should a round of edits go wrong, discard_draft reverts to the published version.

Step 4: Publish When You're Ready

When the draft is approved, the prompt is one line:

Publish article abc123.

Claude calls the publish tool and the entry's status flips to published. Two conditions have to hold for this to work:

• The token needs publish permission.
• The Content-Type needs Draft and Publish enabled.

The publish, unpublish, and discard_draft tools are only generated when Draft and Publish is enabled, per the tools documentation.

Before sending that prompt, check the category and any other relations you attached. The Draft and Publish docs carry an important caution for blog teams: "Before publishing a draft, make sure it doesn't have relations with other non-published content, otherwise some of the content may not be available through the API." A brand-new 'Tutorials' category that nobody published yet may be missing from the API response even though the article itself went live.

Confirming the publish takes one more get:

Show me article with ID abc123 and tell me its status.

The response should report published. In the Admin Panel, the same entry shows a Draft tab and a Published tab whose contents match. If your frontend fetches from the REST API, remember that Strapi 5 replaced Strapi 4's publicationState with a status parameter, and the REST API defaults to published, so the post appears in a default fetch without extra parameters. Only the Document Service defaults to draft.

For teams, consider whether the person drafting should hold publish at all. Strapi's token scoping guide is blunt about it: an agent that drafts blog articles needs create and update on Article, "probably read on Category, and nothing on User, Settings, or your pricing Content-Types.

It almost certainly doesn't need publish; keeping that human-gated provides a confirmation step before state changes." A writer's token without publish won't expose the tool, and the editor either publishes from their own Claude session or clicks Publish in the Content Manager. Either way, the loop closes with a human decision.

Building a Repeatable AI Blog Publishing Habit

A new post reduces to four short messages: paste notes and ask for the draft, ask to see it, give revision notes, say publish. Those prompts stay the same from post to post, so it pays to save them as templates instead of retyping them.

Strapi's prompt-driven content documentation covers sorting, filtering, pagination, i18n, and relations through the same conversational interface, so the habit extends to housekeeping tasks like "list every draft older than two weeks" without learning anything new.

Claude Desktop gives you two optional places to keep the standing instructions:

• Projects: Claude Projects are workspaces with their own instructions, chat history, and uploaded reference material, and Claude Academy notes in its Projects course that project instructions "apply to every conversation within the project." A blog-publishing Project might carry an instruction like "Every article you create in Strapi must include a slug derived from the title, a two-sentence excerpt, and a category. Never publish unless I say the word publish."
• Skills: Skills, per Anthropic's Skills article, are "folders of instructions, scripts, and resources that Claude loads dynamically," and Claude Academy's Skills and Projects guidance recommends Skills for repeatable procedures like brand guidelines and report formats, and Projects for work that needs accumulated context.

Projects fit work that needs accumulated context, while Skills fit repeatable procedures.

What to Handle Manually

The main limitations that may require the Admin Panel are:

• Media uploads: Featured images are the one step that still sends you to the Admin Panel. The known limitations section states that the server cannot upload files and accepts only references to existing Media Library assets. Strapi's Windsurf integration post describes the workaround: "Media fields accept references to existing assets, but the server can't upload new files. Add files through the Media Library or upload API first, then reference them in tool calls." So the practical order is: upload the cover image to the Media Library while Claude is drafting, then reference that existing asset in a follow-up update.
• Dynamic Zones: Dynamic Zones arrive as untyped arrays, meaning Claude receives no description of the components inside them. Strapi's suggestion in the custom tools post is to put the prose into a single shared.rich-text block and split it into other blocks by hand in the Admin Panel afterward.
• Custom fields: Custom fields from Strapi plugins may fall back to an unknown type if their registry wasn't populated when the MCP tools registered.
• Nested population: The list and get tools don't support nested population, so a review in chat won't expand a category's own relations.

These gaps are where a quick pass through the Admin Panel remains useful after the conversational work is complete.

The human read is not optional. The official MCP documentation includes no built-in review-before-publish safeguard. With Draft and Publish enabled, new entries are drafts by default in the backend Document Service API, but the public REST API still creates and returns published entries by default unless you explicitly set status=draft, and scoping publish away from the drafting token keeps the final step in human hands, but neither one reads the post for you.

Treat every draft as copy that needs verification against your product, dates, and intended position. Read the whole thing, in the Admin Panel or in chat, before you type the word publish.

Four Prompts from Notes to a Live Strapi Post

No-code content publishing through Claude Desktop turns a pile of notes into a live Strapi post in one sitting: create saves the draft, list and get bring it back for review, update handles slug, excerpt, category, and every round of edits, and publish flips it live once you've read it. The only detours are uploading the cover image to the Media Library and keeping a human on the publish button.

Your next article is the right test. Have your developer enable the built-in MCP server on a supported Strapi 5 instance, scope a token to create, update, and read on the Content-Types you actually write, and run the four prompts from this guide against a real draft. If you need the Strapi installation guide, start from the Strapi 5 live demo at the Strapi homepage.