/run-workflow

name: run-workflow
description: >-
  Use the run-workflow MCP to discover, compose, execute, publish, and save
  Adobe Firefly workflows. TRIGGER when: user asks what the MCP can do; wants
  to process images/video/3D via workflow; wants to build/run/save/publish a
  workflow; wants to list/view saved or recent workflows, presets/interfaces,
  or golden demos (e.g. 'run banners at scale'); pastes any
  workflow/batch/execution ID; names a featured workflow (retargeting, product
  banners, localization, packaging, banner advertising) — call
  get_featured_workflow first. NOTE: 'banners at scale' = GOLDEN DEMO
  (list_golden_workflows), NOT the featured workflow 'Product Banners At
  Scale'. BARE ID = INSPECT ONLY — call inspect_run, never
  run_workflow_submit. ALWAYS call list_actions first for action/node
  discovery; a "what tools" question is answered directly from your visible
  tool list, no call. DO NOT TRIGGER for direct Firefly API calls without
  MCP (use firefly-api-specs).
compatibility: Requires an enterprise Adobe account with a Firefly Services or Firefly Creative Production entitlement, assigned via the Adobe Admin Console. Not available to individual/personal Adobe accounts.
license: Apache-2.0
metadata:
  version: 1.0.0
  visibility: public

run-workflow MCP

<!-- SYNC: This skill is maintained in three locations that must be kept identical: `.claude/skills/run-workflow/` (source), `.cursor/skills/run-workflow/` (Cursor), and `packages/mcp-server/references/` (reference files only, bundled with the MCP server). Change one, change all three. See docs/CODE_PATTERNS.md → "run-workflow skill twins". -->

Discover, compose, run, publish, and save Adobe Firefly workflows through the run-workflow MCP server. Never answer capability questions from training knowledge — always ground answers in live tool calls. `list_actions` is ALWAYS the first call for any **action/node catalog** discovery question (e.g. "what actions are available"). A **tools** question (e.g. "show me the tools", "what MCP tools do you have") is a different vocabulary — answer directly from your own visible tool definitions (name + one-line description each); do not call `list_actions` for it.

This file is the always-loaded core. Deeper procedures live in `references/` and should be read **only when the current turn needs them**:

| Read this reference when… | File | | --- | --- | | User uploads/pastes a document that reads like a creative/marketing brief (not a bare ID, not a named workflow) | [`references/intake.md`](references/intake.md) | | User names a featured workflow, or supplies a custom `.indd`/`.psd` template to rewire | [`references/featured-and-templates.md`](references/featured-and-templates.md) | | Composing a non-trivial graph, wants multi-variant outputs, or a required input is missing | [`references/compose.md`](references/compose.md) | | Inspecting a run, listing history, or a workflow failed (error tables, `inspect_run` routing) | [`references/diagnostics.md`](references/diagnostics.md) | | Uploading files, resolving inline pastes, macOS permission error, saving outputs | [`references/asset-input.md`](references/asset-input.md) | | User asks for alert triage / RCA (dev-only: `login --dev`, Splunk + Slack) | [`references/alert-rca.md`](references/alert-rca.md) |

BARE ID RULE — read this before anything else

**When the skill argument is just an ID (UUID, workflowId, batchId, executionId) with no other context, the intent is ALWAYS to inspect — NEVER to execute.**

1. Call `inspect_run(id)` immediately. 2. Present the results (executions, outputs, diagnostics). 3. **STOP.** Do not call `run_workflow_submit` as a follow-up.

**"run-workflow" is the product name, NOT an instruction to execute anything.** Required keywords to justify `run_workflow_submit`: **"run", "execute", "process", "generate", "rerun", "redo"**. If NONE appear in the user's message, call `inspect_run`.

**FORBIDDEN:** calling `run_workflow_submit` on a bare pasted ID; trying `run_workflow_submit` first and falling back to `inspect_run` after a 404. For rerun-after-inspect handling (route on the `rerun` object, never `canRerun`), see [`references/diagnostics.md`](references/diagnostics.md).

**"What assets/inputs does this golden workflow or interface need (and are they still available)?"** is also an `inspect_run(workflowId)` question — it resolves the interface's authoritative baked definition and reports each asset's `rerunAssets[].resolvedVia` (warm-url / durable-storage / unavailable). NEVER answer it with `get_featured_workflow` (a different catalog). See [`references/diagnostics.md`](references/diagnostics.md) → "What assets does this golden/interface need".

Workflow types (user-facing vocabulary)

Every workflow the user sees falls into one of these types. Use these plain labels when talking to the user; **never** show the raw internal field values.

• **Published** — a workflow the user published as a reusable API endpoint (stable `workflowId` + curl).
• **Preset** — a published workflow run from a Firefly UI. **"Preset" and "interface" are the SAME

thing** — if the user asks about "interfaces" or "presets", they mean this. (Not a separate saved definition; it's a *published workflow that was launched from an interface.*)

• **Inline** — a workflow composed and run ad-hoc through the MCP with no saved/published definition.
• **Draft** — saved to Workflow Builder but not yet published. A draft **stays a draft after it is

run** (source `draft` whether or not it has ever executed), matching the builder UI. Use `firstExecutionAt` to tell run from un-run: set = a **run draft**, null/absent = an **un-run draft**.

• **Preview** — a one-off preview execution; ephemeral.
• **Shared** — a workflow shared into this org from a different org (author-initiated); read-only.

A **workflows-listing** request ("give me my workflows", "what have I built") surfaces the caller's own **Draft** and