Amazon's official SP-API MCP package ships with two servers. The dev assistant gets all the press — it's the one that searches docs, generates code, and runs API calls. The other one, the Workflow MCP, is the sleeper. It's the one that quietly compiles to AWS Step Functions and lets you stand up production-grade automations in a few sentences.

Most teams don't yet realize what's possible with it. So here are seven workflows you can actually build today, with the patterns and traps for each.

Every workflow in this guide assumes you have the SP-API Workflow MCP loaded in your AI client (Claude Code, Cursor, Codex, or Kiro). If you haven't set it up, the Amazon SP-API MCP setup guide covers the full install in under five minutes.

A 60-second refresher on the Workflow MCP

The Workflow MCP exposes around 30 tools that group into three layers: a Builder that assembles state machines from natural-language descriptions, an Interpreter that runs and monitors them, and Callback tools that pause for human approval mid-run.

Under the hood, everything compiles to Amazon States Language — the same language AWS Step Functions speak. You get retries, durable timers, branching, parallelism, and observable execution traces for free. The MCP just gives you a far gentler on-ramp to it than the AWS console.

That foundation matters because every workflow below leans on the same five primitives:

• Wait — pause until a clock time, or for a duration.
• Task — do one thing (typically sp_api_execute against an endpoint).
• Choice — branch on a value or condition.
• Parallel — run multiple branches at once, join the results.
• Callback — pause for an external signal (human, webhook, queue).

Mix those five and the workflows below all fall out as natural compositions.

1. Daily Sales + Ads Pull to S3

Why build it: Every analytics stack on Amazon starts here. Pull yesterday's orders, line items, and ad performance into your warehouse so downstream dashboards have something to read from.

The prompt to give the MCP:

Build a workflow that runs every day at 02:00 ET, pulls yesterday's orders, order line items, and Amazon Ads campaign reports for marketplace ATVPDKIKX0DER, and writes each as a CSV to s3://my-analytics-raw/YYYY-MM-DD/.

What the Workflow MCP assembles:

1. Wait until 02:00 ET.
2. Parallel — three branches running at once:
   — Branch A: Create + poll + download the Orders report.
   — Branch B: Create + poll + download the Order Line Items report.
   — Branch C: Pull Sponsored Products + Sponsored Brands + Sponsored Display campaign reports from the Ads API.
3. Task — upload each result to S3 under the dated prefix.
4. Choice — if any branch failed, send a Slack alert; otherwise exit silently.

Production traps:

• Reports endpoints are asynchronous — the MCP knows the create → poll → download pattern, but if you specify a sync endpoint by accident, your workflow will spin. Be explicit about which report type you want.
• Ads API uses a separate auth flow from SP-API. Make sure both sets of credentials are in your MCP config.
• The S3 step needs IAM permissions — the MCP can't grant them for you. Pre-create the bucket and a role.

Reusable variant: swap S3 for Snowflake, BigQuery, or any HTTP endpoint with a single sentence.

2. Real-Time Low-Stock Slack Alert

Why build it: Stockouts cost money twice — lost sales today, and Buy Box loss tomorrow when Amazon decides you're unreliable.

The prompt to give the MCP:

Every 30 minutes during business hours, check FBA inventory for our top 50 SKUs. If any SKU has fewer than 14 days of cover at its trailing 30-day sell-through rate, post to #ops-restock with the SKU, current units on hand, daily run-rate, and days remaining.

What the Workflow MCP assembles:

1. Wait for the next 30-minute mark within business hours.
2. Task — pull GET /fba/inventory/v1/summaries filtered to the top 50 SKUs.
3. Task — pull the trailing 30-day Order Line Items report (or read it from cache if recent).
4. Map — for each SKU, compute days-of-cover = on-hand ÷ daily run-rate.
5. Choice — for each SKU where days-of-cover < 14, queue a Slack message.
6. Task — POST formatted messages to Slack webhook.

Production traps:

• Polling every 30 minutes will eat through your SP-API rate limit fast on detail-heavy endpoints. The inventory summary endpoint is generous; sale-rate calculation should come from cached reports, not live calls.
• "Top 50 SKUs" needs a source of truth — either hard-coded, pulled from a CMS list, or computed at start of workflow.
• Slack rate limits are real too. Batch alerts into a single message if more than five SKUs are low.

3. Monthly Settlement Reconciliation

Why build it: Amazon's settlement reports are the source of truth for your bank deposits, but they're a mess to reconcile against your internal sales totals. Differences are usually fees, returns, reserves, or chargebacks. Catching them monthly saves quarter-end pain.

The prompt to give the MCP:

On the 3rd of every month, pull the latest settlement report for the prior month, sum the disbursement amount, sum the orders revenue from Order Line Items for that period, compute the delta and the per-category breakdown (fees, refunds, reserves, chargebacks), and email a summary to finance@.

What the Workflow MCP assembles:

1. Wait until the 3rd of the month at 09:00 ET.
2. Task — create + poll + download the settlement report (async; can take 5–30 minutes).
3. Task — pull Order Line Items for the same period.
4. Task — compute totals, deltas, and category breakdown (small Lambda or inline script).
5. Task — render HTML/markdown summary and send via SES or your email provider.

Production traps:

• Settlement reports can be huge — partition by week or paginate the download.
• Use the callback primitive if you want finance to approve any delta over $X before the email goes out (good for fraud detection).
• The MCP won't write the comparison logic for you; that's a Lambda or an inline script. The workflow orchestrates the moving parts.

4. Buy Box Change Detection Agent

Why build it: Buy Box ownership changes are the canary in your competitive position. Knowing within minutes is a huge advantage over knowing the next day.

The prompt to give the MCP:

Every 15 minutes, check Buy Box winner for our 200 most important ASINs via the Product Pricing API. If we lost the Buy Box on any ASIN, log to a Postgres table with timestamp, ASIN, new winner, and offer price. Alert Slack if the same ASIN lost Buy Box more than 3 times in 24 hours.

What the Workflow MCP assembles:

1. Wait 15 minutes.
2. Task — pull GET /products/pricing/v0/itemOffers/{ASIN} for each ASIN. Batch via Catalog Items where possible.
3. Map — for each ASIN, compare current Buy Box winner against last-known winner from the DB.
4. Choice — if changed, write a row to the BuyBoxChanges table.
5. Task — query the DB for ASINs with > 3 changes in 24h.
6. Choice — if any, send Slack alert grouped by ASIN.

Production traps:

• Product Pricing endpoints have strict rate limits. Batching via Catalog Items is essential at this volume.
• The "last-known winner" requires durable state — a DB table or a Step Functions execution input. Don't try to hold it in memory.
• "200 most important ASINs" is again a configuration concern. Externalize the list.

5. Returns Analysis + Categorization Pipeline

Why build it: Returns data is gold for product quality, listing accuracy, and ops decisions — but the data lives in the FBA Customer Returns report and nobody reads it.

The prompt to give the MCP:

Once a week, pull the FBA Customer Returns report for the prior 7 days, classify each return by reason (defective, wrong item, doesn't match listing, customer changed mind, other), and email a CSV grouped by SKU with counts per reason category.

What the Workflow MCP assembles:

1. Wait until Monday 06:00 ET.
2. Task — create + poll + download the FBA Customer Returns report.
3. Task — for each row, run the reason field through a simple classifier (regex or LLM call).
4. Task — group by SKU and reason category, write CSV.
5. Task — send email with attachment.

Production traps:

• Return reason text varies widely. A regex classifier covers 80%; the rest needs LLM classification — that's an additional MCP/API call and costs add up at scale.
• Email attachments have size limits. Compress and chunk by week if needed.
• This workflow is great for AI-assisted ops — the LLM classification step is the same MCP context, so a single conversation can build the whole pipeline.

6. Auto-Restock with Human Approval (Callback Pattern)

Why build it: Auto-restock is the holy grail of Amazon ops. It's also where automation goes catastrophically wrong without guardrails. The callback pattern lets you have both — automation for the easy decisions, human review for the expensive ones.

The prompt to give the MCP:

Every Monday at 10:00 ET, compute restock recommendations for SKUs with less than 21 days of cover. For recommendations under $5,000 total, send the PO to our supplier API automatically. For recommendations over $5,000, send a Slack message to @kris with an Approve/Reject button. Only send the PO if approved within 48 hours; otherwise log a skipped event.

What the Workflow MCP assembles:

1. Wait until Monday 10:00 ET.
2. Task — pull current inventory, sell-through, and lead times (from internal config or API).
3. Map — compute restock recommendations per SKU.
4. Choice — for each recommendation, branch on $ amount:
   — Under threshold: call supplier API to create PO.
   — Over threshold: enter Callback state.
5. Callback — emit a Slack message with approve/reject buttons that include a callback token.
6. Wait for callback for up to 48 hours.
7. Choice — on receiving approval, call supplier API. On reject or timeout, log skipped.

Production traps:

• The callback token must be unique and tied to the execution. Step Functions handles this if you wire it correctly — don't try to roll your own.
• 48-hour wait windows mean the workflow execution stays alive for two days. Make sure your AWS account is fine with long-running Step Functions executions (it is — they last up to a year).
• Supplier API failures need their own retry/alert logic. The MCP gives you the building blocks; you wire them in.

This pattern alone — automation gated by callbacks — is probably the most under-utilized capability of the Workflow MCP. Use it everywhere money or inventory moves.

7. Multi-Marketplace Performance Roll-Up

Why build it: If you sell across NA, EU, and FE, you don't have one Amazon business — you have three. A daily roll-up that normalizes currency, fees, and timezone gives you the unified view.

The prompt to give the MCP:

Every day at 04:00 UTC, pull yesterday's orders and ads spend from each of our three regions: ATVPDKIKX0DER (US), A1F83G8C2ARO7P (UK), and A1VC38T7YXB528 (JP). Convert all amounts to USD using daily FX rates. Aggregate into a normalized JSON document and write to s3://my-analytics-curated/daily-rollup/YYYY-MM-DD.json.

What the Workflow MCP assembles:

Production traps:

• Three regions, three credential sets. The MCP needs separate config blocks per region (NA / EU / FE), each with its own client ID, secret, and refresh token. Don't try to share creds across regions; you'll get auth errors.
• FX rate sources vary in lag. Use the rate at end-of-day for the regional close, not realtime.
• Currency rounding can introduce drift over time. Round once at the aggregation step, never in intermediate calculations.

Patterns that show up in every production workflow

Look at the seven workflows above and the same shapes keep recurring. If you're building anything non-trivial, these patterns are worth internalizing:

Fan-out → fan-in. The Parallel state running three regional branches in workflow 7, or three report pulls in workflow 1. Lets your wall-clock time stay constant as you add data sources.

Async report polling. The create → poll → download dance for any non-trivial SP-API data. The MCP knows this pattern, but you must explicitly say "report" so it picks the async path.

Cached intermediate state. Workflows that re-pull the same data multiple times per day will exhaust rate limits. Cache reports in S3 or DynamoDB for the freshness window your business actually needs.

Choice-gated alerts. Don't send a Slack ping every run. Send one only when the choice condition matches (low stock, lost Buy Box, etc.). Spammy alerts get muted.

Callbacks for anything destructive. Any write action — placing orders, updating prices, changing listings — should pause for human or webhook approval. The Workflow MCP has first-class support for this.

Common production traps to know upfront

Five things that bite teams in week two:

Rate limits. SP-API and Ads API both throttle aggressively on detail-heavy operations. Detail-per-ASIN loops will 429 within minutes. Batch through Catalog Items, use reports for bulk, and respect Retry-After.

Region boundaries. Workflow execution state, credentials, and S3 buckets all need to live in the same AWS region as your Step Functions. Cross-region adds latency and IAM complexity.

Long-running executions. A workflow with a 48-hour callback wait stays in Running state for the full window. That's fine — Step Functions supports it — but your monitoring needs to distinguish "stuck" from "waiting on callback."

Credential rotation. SP-API refresh tokens don't expire by default, but they can be revoked. Build a notification path for auth failures so your workflows don't silently stop running.

Costs. AWS Step Functions Standard pricing is per state transition. A workflow with 50 states firing every 15 minutes adds up. Stick to fewer, smarter states; consolidate logic into Tasks where it makes sense.

Where workflows hit their ceiling

The Workflow MCP is excellent for orchestrating SP-API calls into shaped, durable, observable processes. It's not, by itself, a data layer. It calls Amazon's APIs and moves data around; it doesn't unify, normalize, or enrich that data the way an analytics pipeline does.

For most teams, the natural pairing is: Workflow MCP for the durable plumbing, a data layer for the unified queryable view on top. If you don't want to build the data layer yourself, that's the gap DataDoe fills — it carries SP-API plus Amazon Ads plus your COGS in one queryable surface (MCP, REST API, BigQuery). The workflows you build above can drop straight into it.

But that's a small part of the picture. The bigger story is that the Workflow MCP, on its own, takes weeks of bespoke automation work and collapses it into prompts. That's the headline.

FAQ

Can the Amazon SP-API MCP run workflows unattended?

Yes. The Workflow MCP compiles to AWS Step Functions, which executes durably and observably without an interactive AI client open. You only need the MCP at build/edit time.

Do I need an AWS account to use the Workflow MCP?

You don't strictly need one to prototype — the MCP runs the workflows in its embedded interpreter. To deploy to production with full Step Functions guarantees, yes, you need AWS.

What happens if a workflow execution fails mid-run?

Step Functions retries failed states based on the retry policy you specify, then fails the execution with a full stack trace. The Workflow MCP's interpreter can replay failed executions for debugging.

How long can a workflow run?

Step Functions Standard executions can run for up to one year. Express executions up to five minutes (cheaper, no callbacks).

Can I edit a workflow once it's deployed?

Yes — through the MCP or in the AWS Step Functions console. New executions use the new definition; in-flight executions finish with the old one.

Can I version workflows?

Yes. Step Functions has built-in versioning and aliasing. The Workflow MCP can interact with both.

Where do I see what's happening in a running workflow?

Through the Workflow MCP's interpreter tools (event tail, status check) or directly in the AWS Step Functions console's visual execution view.

Can the Workflow MCP call non-Amazon APIs?

Yes. Tasks can hit any HTTP endpoint, AWS Lambda, SNS, SQS, DynamoDB, S3 — anything Step Functions supports natively. Slack, supplier APIs, internal services are all fair game.

Is there a cost cap on workflows?

Step Functions charges per state transition, not per workflow. You're effectively charged per the smallest unit of work. Most well-designed workflows cost dollars per month, not hundreds. Run-away patterns (polling tight loops) are where costs balloon — and that's a design problem, not a tooling problem.

Wrapping up

The seven workflows above are the bread-and-butter automations every Amazon team eventually needs. The Workflow MCP makes them buildable in days, not weeks. The patterns — parallel branches, async reports, callbacks for safety, cached intermediates — show up everywhere once you start thinking in workflows instead of scripts.

If you're going to spend any time with Amazon's official MCP package, the Workflow MCP deserves at least half of that time. It's the half that actually runs in production.

Sources & further reading

• Amazon SP-API Dev MCP — GitHub
• AWS Step Functions documentation — docs
• Amazon States Language specification — reference
• Selling Partner API documentation — developer-docs.amazon.com/sp-api
• Amazon SP-API usage plans and rate limits — official guide
• Amazon SP-API MCP: The Ultimate Guide — DataDoe blog