Building Multi-Step Content Pipelines with Strapi MCP, n8n, and AI Agents

A one-off prompt in a chat window can't run an AI agent workflow on a Monday morning while nobody is watching. A multi-agent content pipeline built on n8n and Strapi's Model Context Protocol (MCP) server replaces the chat loop with a scheduled, multi-step flow.

A research agent, a writing agent, a Slack approval step, and a publishing agent each do one job, and the last one calls create and publish on your Article Content-Type through a scoped token. This guide covers the connection settings, a research-to-publish pipeline, and the retry, idempotency, and token-scoping decisions that keep it running unattended.

In brief:

• Ship a built-in MCP server that exposes only the tools your Admin token permits.
• n8n's MCP Client Tool node connects to /mcp over Streamable HTTP with a Bearer Auth credential.
• Fixed prompt chaining with code gates and a human approval step beats one autonomous agent.
• Deterministic slugs and a list-before-create check give idempotency, with requestTimeoutMs and EXECUTIONS_TIMEOUT as ceilings.

Together, these choices make the pipeline repeatable, permission-aware, and safe to rerun.

Single Agent vs. Orchestrated Pipeline

A single AI client connected to Strapi's MCP server can, per the MCP usage docs, "create a blog article, list recent entries, or publish a page" from a natural-language prompt. That covers a developer in Cursor or Claude Desktop seeding test content. It does not cover a weekly editorial run, because a conversational agent has no trigger, no memory of last week's topics, and no gate between drafting and publishing other than the person watching.

An orchestrated pipeline chains a trigger, several narrow agents, deterministic code steps, and a final MCP call into one automation you can schedule and rerun. Microsoft's AI agent design patterns frame the same structural choice: use a single agent when it can reliably solve the scenario, and coordinate multiple agents when the task benefits from distributed responsibilities.

Content work maps onto the simplest multi-step pattern. Sequential orchestration lets one step produce an outline, another check that it meets defined criteria, and a later step write the document from the approved outline. This prompt-chaining approach fits situations where the task can be cleanly decomposed into fixed subtasks.

Splitting work across agents pays off only when the gates between steps are ordinary code: a dedup check, a schema-validated draft, an approval click. A failure then surfaces at the step that produced it instead of three stages later.

How the Pieces Fit Together

Three layers do three different jobs. n8n owns sequencing: triggers, data passing, dedup, approval waits, retries, and error workflows. AI Agent nodes own judgment: what to research, how to draft, whether an existing entry should be updated instead of a new one created. Strapi's MCP server owns execution against the headless CMS, through typed tools rather than raw REST calls the model has to construct.

The Strapi MCP server docs describe a built-in Model Context Protocol server whose operations are all gated by Admin token permissions. Strapi's community call recap frames MCP as an open protocol that standardizes how AI agents discover and invoke tools across a stack.

Two implementation details shape how you wire n8n to it. The MCP server is a route on Strapi's existing HTTP server rather than a sidecar process, so it is live whenever Strapi is. And each POST to /mcp creates a fresh, ephemeral MCP server instance scoped to the token's permissions, with no session persistence between requests.

Strapi handles these MCP requests statelessly, so you do not need to pass a session identifier between n8n nodes. This implementation behavior is distinct from the protocol-level session removal introduced in the 2026-07-28 MCP specification updates. A permission change on the token therefore takes effect on the very next request.

The orchestrator handles retries and backoff so the agents only handle the task: node-level Retry On Fail, an Error Trigger workflow for the failures that get through, and Remove Duplicates ahead of the agent so it never sees a topic twice.

Prerequisites

The MCP configuration section and Strapi's installation prerequisites set the baseline:

• Strapi 5.47.0 or later. The MCP server shipped as beta in 5.47.0 and reached general availability (GA) in 5.49.0. The current release is 5.52.2. The feature is free and opt-in on self-hosted instances.
• Node.js v22, v24, or v26. Active and Maintenance LTS only. Odd-numbered current releases aren't supported.
• An Admin token, not a Content API token. The MCP server rejects Content API tokens with a 401. Create the Admin token under Settings, then Administration Panel, then Admin Tokens in the Admin Panel, which requires the Super Admin role or an explicit Admin Tokens permission. The plaintext key appears once, so copy it into your n8n credential store immediately.
• An n8n instance with the MCP Client Tool node.
• A chat model credential for the agent nodes.

With these dependencies in place, you can enable the MCP endpoint.

Enabling the server is code-only; there is no documented environment variable toggle. Add the mcp block to config/server.js (or config/server.ts) and restart:

// config/server.js
module.exports = ({ env }) => ({
  // ...existing host, port, app.keys
  mcp: {
    enabled: true,
  },
});

After the restart, the endpoint is available at /mcp, POST only. If your team needs an audit trail of agent writes, note the gate now: MCP actions appear in Audit Logs with origin: "mcp" from Strapi 5.52.0, and Audit Logs require the Enterprise plan.

Connecting n8n to the Strapi MCP Endpoint

The Strapi MCP server docs state the contract: "Any MCP-compatible client can connect by pointing to the /mcp endpoint with a Bearer token in the Authorization header." The generic settings the docs give for any client are:

In n8n, those three values land in the MCP Client Tool node, which you attach to an AI Agent node as a tool. Don't confuse it with the plain MCP Client node, which runs as a regular workflow step. n8n's docs point AI Agent users to the MCP Client Tool node rather than the plain one.

Configure the sub-node like this:

1. Set Server Transport to HTTP Streamable and paste your Strapi URL plus /mcp into the endpoint field. n8n labels the spec's Streamable HTTP transport as HTTP Streamable. Depending on your n8n version, that field may still be labeled SSE Endpoint even when the transport is set to HTTP Streamable, and the SSE option is deprecated in line with the MCP transport changelog, which records the deprecation of HTTP+SSE since 2025-03-26.
2. Choose Bearer Auth for Authentication and create a standard n8n httpBearerAuth credential holding the Admin token. The n8n credential docs confirm that n8n sends it as Authorization: Bearer <token>.
3. Under Tools to Include, pick Selected and list only the tools this agent needs. n8n uses automatic tool discovery, so you pick from names like create, update, and publish for your Article type rather than typing them.

That leaves the agent connected through one credential and limited to an explicit tool set.

For hosted Strapi instances, swap in your production URL over HTTPS. Because the MCP route lives on the main Strapi server, staging and production connect the same way as localhost.

Designing the Pipeline

Before drawing nodes, look at what the agents in this AI agent workflow will be allowed to do. The available tools section lists up to eight tools per Collection Type:

Single Types get up to six: no list, and create and update merge into one write tool. The three Draft and Publish tools only exist when Draft and Publish is enabled on the Content-Type. When Strapi Internationalization is on, every tool accepts an optional locale parameter, and the schema tells the agent which locales exist.

A research-to-publish flow needs list, create, update, and publish. It does not need delete, and the token you create later shouldn't grant it.

Trigger and Input

n8n gives you three natural entry points. A Schedule Trigger suits an editorial calendar, though its variables are evaluated only when the workflow is published, so changing the interval means unpublishing and republishing. A Webhook Trigger fits a generate-this-brief-now button in an internal tool. A Form Trigger gives non-technical editors a way to submit topics.

Whatever fires the pipeline, normalize the input into one object early. A Set node that produces { topic, slug, sourceUrl, locale } gives every downstream node a stable shape to reference with $json.slug or $('Normalize Input').item.json.topic, using n8n's previous-node expressions. Derive the slug deterministically from the input (a slugified title plus a date works) because that slug becomes both the dedup key and the field the draft agent searches Strapi for.

Agent and Enrichment Steps

Each AI Agent node gets a chat model, a System Message, and, for everything except the draft agent, no MCP tools at all. The AI Agent node docs describe the node simply: "Connect a chat model and one or more tools, and the agent decides which tools to call to complete a task." A research agent needs only a model and perhaps a web search tool.

A writing agent needs the research output and a Structured Output Parser so its draft arrives as { title, slug, excerpt, body } rather than free text. Set the prompt mode to Define below with an expression, as shown in the agent prompt docs, since the input isn't coming from a Chat Trigger. The Auto-fixing Output Parser retries on malformed output, which saves a failed run when the model wraps JSON in prose.

The docs' prompt management examples show how the draft agent's instructions translate into tool calls: "Create a new article titled 'Hello World' with body 'First post'." creates a draft, "Update article abc123, change the title to 'Hello Strapi'." updates only the title, and "Publish article abc123." flips the status. Your System Message is a stricter version of those sentences, with the decision logic spelled out: search by slug first, update if found, create if not.

You can chain agents sequentially with regular n8n connections, or hand the whole job to a root agent that delegates to AI Agent Tool sub-nodes. The trade-off is that prompt chaining fixes the sequence at design time, while AI Agent delegation lets the sequence emerge at runtime from the agent's reasoning.

For a pipeline you want to rerun identically every week, the fixed sequence wins. Reach for delegation when the brief is open-ended and you genuinely can't predict which enrichment steps are needed.

One n8n caveat matters here: sub-node expressions inside output parsers and tools always resolve to the first item. Process one topic per execution, or split items into separate sub-workflow runs with the Execute Workflow node.

Content Actions via MCP

The content management tools behave the way Draft and Publish does in the Admin Panel. create produces a draft, so nothing goes live until an explicit publish call, which is exactly the property an approval gate depends on. update, publish, and get all key on documentId, the 24-character identifier Strapi 5 uses for a document across its draft and published versions (see the Document Service docs).

Strapi's What Is MCP post describes the sequence an agent runs: the server validates input against the schema, calls Strapi's REST API, and returns the created content's documentId for the agent to reuse.

Know the limits before the agent hits them. Media upload isn't supported over MCP, so add image integrations through the Media Library first and have the agent reference them. And as of Strapi 5.52.2, a relation write that combines set with connect or disconnect is rejected, so a draft agent prompt that sets categories should use one or the other.

A Worked Example: Research-to-Publish Pipeline

The flow below turns a weekly topic list into published articles with a human sign-off in the middle.

1. Schedule Trigger fires every Monday at 09:00 UTC and reads a topic list from a Google Sheet or Airtable node.
2. Set node normalizes each row into { topic, slug, sourceUrl, locale: "en" }.
3. Remove Duplicates (mode: Remove Items Processed in Previous Executions, Value to Dedupe On: slug, Scope: Workflow) drops anything already handled in a prior run.
4. Research agent (chat model plus a search tool, no MCP) produces a bulleted fact list with source URLs, parsed by a Structured Output Parser.
5. Writer agent takes $('Research agent').item.json.output and returns { title, slug, excerpt, body }.
6. Draft agent (MCP Client Tool limited to list, create, update, using the n8n-editorial-writer token) searches Strapi by slug, then creates or updates the draft and returns the documentId.
7. Slack Send and Wait posts the title, excerpt, and Admin Panel link with Approval buttons. n8n pauses the execution until someone clicks.
8. IF node on the approval result. On approve, a second MCP Client Tool call, the publish node, uses the n8n-editorial-publisher token and exposes only publish, publishing by documentId. On reject, the draft stays a draft and a note goes back to Slack.

This separation keeps drafting repeatable and reserves publishing for an explicitly approved execution path.

The draft agent's System Message carries the idempotency rule in plain language, a stricter version of the prompt management examples in the docs:

You manage Article entries in Strapi. You receive a draft with title, slug,
excerpt, and body. First call `list` with filters { slug: { $eq: "<slug>" } }.
If an entry exists, call `update` with its documentId and the new fields.
If none exists, call `create`. Return the documentId and whether you created
or updated. Never call any other tool.

The Send and Wait operation posts the message and pauses the execution until a person confirms or sends information back. In Discord, inline approval buttons provide approve and disapprove options; Free Text and Custom Form types exist when the reviewer needs to send edits back.

Since n8n 2.30, every Send and Wait node includes a respondedAt ISO-8601 timestamp in its output (per the n8n changelog), which is useful to record on the Strapi entry or in your own log. The same pattern works through supported messaging nodes for Microsoft Teams, Discord, Telegram, Gmail, and Email/SMTP if your team doesn't live in Slack.

Splitting publish into its own node with its own token is deliberate. The MCP permission boundaries mean the research and draft agents' token never holds publish, so content injected into a scraped source page cannot trigger a publish. n8n also supports human tool approval, which you can layer on the publish call as a second safeguard if someone later decides the Slack gate is unnecessary.

Error Handling and Idempotency in Pipelines

Turn on Retry On Fail for every node that talks to a network: the chat model, the search tool, and the MCP Client Tool. n8n exposes per-node retry settings for Max Tries and Wait Between Tries (ms). For the publish step, Continue (using error output) routed to a Slack alert is usually the right call, since a failed publish shouldn't stop the rest of the batch; see n8n's error output docs.

Retries are safe only because the pipeline is idempotent. Three layers give you that guarantee:

• Deterministic slugs derived from the input, not from the model's output, so the same topic always maps to the same key.
• Remove Duplicates ahead of the agents, scoped to previous executions so a topic that fires twice only gets processed once. The deduplication history can be reset with the Clear Deduplication History operation when you intentionally want a rerun.
• List-before-create inside the draft agent, using the list tool's filters parameter with $eq on the slug. The list tool supports Strapi filter operators including $eq, $in, $contains, and $startsWith, with pageSize defaulting to 25 and capped at 100.

These layers protect both scheduled reruns and retries after ambiguous network failures.

The list-before-create check matters more than it looks because of a transport rule in the current MCP spec. The MCP specification's retry guidance says that a broken response stream loses the in-flight request and that "clients MUST re-issue it as a new request with a new request ID." If a create call's response is lost mid-stream and n8n retries, the entry may already exist. A retry that searches first finds it and updates instead of duplicating.

Execution timeouts operate independently, and the shorter one governs. On the Strapi side, the advanced options expose connectTimeoutMs (default 5000) and requestTimeoutMs (default 60000), so a single MCP request that runs past 60 seconds is aborted by Strapi regardless of n8n's settings. Both keys go in the same mcp object you enabled earlier:

// config/server.js
module.exports = ({ env }) => ({
  // ...existing host, port, app.keys
  mcp: {
    enabled: true,
    connectTimeoutMs: 10000,  // 10 seconds
    requestTimeoutMs: 120000, // 2 minutes for long agent steps
  },
});

The MCP advanced options docs call the five-second and 60-second defaults reasonable starting points and advise raising them only if legitimate agent workloads hit them. On the n8n side, the execution timeout settings use -1 (no timeout) for EXECUTIONS_TIMEOUT by default, with EXECUTIONS_TIMEOUT_MAX at 3600 seconds, and you can set a per-workflow limit under Workflow Settings, then Timeout Workflow. A soft workflow timeout takes effect after the current node finishes. Set the workflow timeout above the sum of your slowest realistic run.

For everything that still fails, create an error workflow starting with the Error Trigger node and select it under the main workflow's Settings, then Error workflow. The Error Trigger output includes execution.lastNodeExecuted, execution.error.message, and the workflow name, which is enough to post a useful alert. Error Trigger only fires on automatic runs, so manual test failures won't reach it, as documented under the Error Trigger's automatic-run behavior.

Securing an Automated Pipeline

Create a dedicated Admin token for the pipeline, and a second one for the publish step, rather than reusing a developer's Cursor token. The MCP permission boundaries section describes what scoping buys you at two levels.

Tool visibility: "If the token does not grant delete on Article, the AI client will not see a delete tool for articles at all." Field filtering: "If the token grants read on Article but excludes the body field, the AI client will not see or receive body content." An agent can't be tricked into calling a tool that was never in its list.

The docs recommend a dedicated Admin token per AI client or use case, scoped to the least permission that still lets the agent finish its job. For the pipeline above, following the Admin tokens docs:

1. Go to Settings, then Administration Panel, then Admin Tokens and click Create new Admin Token.
2. Name it for the pipeline (n8n-editorial-writer), and set a finite duration. The options are seven days, 30 days, 90 days, or Unlimited. Strapi's security post recommends finite durations because they shrink the window a leaked token stays useful.
3. Grant read, create, and update on Article only. Leave delete and publish unchecked, and leave every other Content-Type untouched.
4. Repeat for n8n-editorial-publisher with read and publish on Article.

The result is a writer token that cannot publish and a publisher token with no broader editorial access.

Strapi's role-based access control (RBAC docs) lets you go further: untick individual fields, and when Internationalization is installed, set permissions per locale. The MCP server documentation gives the example of a token that reads en and fr but only creates in en. A token also can't exceed its owner's permissions, so create pipeline tokens from an account that itself has only editorial rights.

The community call recap frames the per-client split you should end up with: a content automation agent gets only the content management tools it needs, while a separate deployment agent might have access to settings. n8n's Tools to Include: Selected setting is a second, cheaper layer on top of the token, but treat it as convenience rather than security. The Strapi token is the boundary that holds if someone edits the workflow.

Run production over HTTPS and rotate tokens on a calendar according to MCP security practices, and store them in n8n credentials rather than in node parameters. On Enterprise with Strapi 5.52.0 or later, every MCP write appears in Audit Logs tagged origin: "mcp", retained for 120 days by default; read-only actions aren't logged.

Start With One Content-Type and One Scoped Token

n8n MCP orchestration turns recurring content work into a pipeline you can schedule, rerun, and scope. The trigger, dedup, and approval logic live in n8n nodes where they are visible and testable.

The agents hold nothing but a chat model and a narrow job. Every write to your headless CMS goes through a Strapi MCP tool that an Admin token explicitly allowed. When a run fails, the Error Trigger tells you which node broke, and the slug check keeps a retry from creating a second copy.

Start with a single Content-Type and a single writer agent, connect the MCP Client Tool with a token that can only create drafts, and watch a run end to end in the n8n Executions tab before adding the Slack gate and publish step. If you're not on Strapi 5.49.0 or later yet, start at the Strapi website, and the MCP server feature page is where the tool schemas you'll be prompting against are defined.