Session-bound Docker workflow server through Codex. State is discarded with the container.
Copy the AI prompt to install this server into Claude Code, Cursor, or another agent — or use 1-click editor setup below.
One-click editor setup isn’t available for this listing yet — we don’t have a confirmed install command, and we’d rather show nothing than point your editor at the wrong package or host. Follow the project’s own setup instructions, linked above.
Run Claude Code dynamic-workflow files through any agent provider — as a durable, resumable Model Context Protocol server.
workflow-mcp is a standalone runtime and MCP server that executes Claude Code
dynamic workflow files — the JavaScript orchestration programs that fan out
dozens or hundreds of agent calls and return a single result — without requiring
Claude to run them.
The whole project hangs on one promise:
A workflow authored for
workflow-mcpcan be copied into.claude/workflows/<name>.jsand run by a compatible Claude Code release without changing the file — and a real Claude workflow file runs through this runtime without any importer or translation step.
Everything that isn't portable — which provider executes the agents, its
credentials, the durable run cache, MCP run IDs, and UI state — lives in the
runtime, never inside the .js file.
Claude Code workflows are a strong primitive: the JavaScript owns the loops,
branches, fan-out, and aggregation, while each agent() call owns the model
reasoning and side effects — keeping hundreds of intermediate results out of the
parent conversation. But out of the box they come with three constraints:
workflow-mcp keeps the exact same workflow file and lifts those constraints:
the same .js runs through a provider-neutral engine (Codex today), every run
is a durable object that survives restarts, and any MCP-capable host can drive
it over a stable set of tools.
Two kinds of portability are kept deliberately separate — MCP solves the first, the provider interface solves the second:
agent, parallel, pipeline,
phase, log, workflow, args, budget, top-level await/return) with
the same discovery rules, metadata grammar, and cache identity. The behaviour
is pinned to an observed Claude Code profile so future Claude releases add a
new profile instead of silently breaking old runs.WorkflowService — not any single MCP connection —
owns runs. Every event is appended and fsynced before any subscriber sees
it, so a run can be reconstructed after a renderer reload, a provider
reconnect, or a process restart by replaying a strict event cursor.AgentProvider
interface. The first real adapter drives the official Codex SDK; a
deterministic fake provider runs the conformance suite. Model aliases
(haiku/sonnet/opus) are host policy, never guessed..js runs here and in Claude Code.workflow_list,
workflow_author_guide, workflow_describe, workflow_validate, workflow_run,
workflow_run_status, workflow_run_events, workflow_result_read, workflow_run_cancel,
workflow_resume, workflow_agent_list, workflow_agent_result_read,
workflow_agent_results_read, workflow_agent_transcript_read) over stdio or an authenticated
loopback HTTP transport.workflow_run returns a run ID at once; clients
follow progress by polling a durable cursor, not a transport-specific push.__workflowAgentFailure coverage gap, while independent siblings
and final synthesis continue. Such runs finish as completed_with_errors;
only persistence or supervisor faults fail the complete run.run_* ID or Claude's native wf_* ID; Claude's own files are never
rewritten. For exact-source Claude imports, bounded hashes of the original
subagent prompts preserve completed dynamic-pipeline siblings even when cached
parents settle in a different order; raw prompt text is not copied into the
workflow-mcp sidecar.WorkflowService and tool registrar that
the CLI uses can be mounted inside another host (this is how
Agent Code renders each run as
a live feed card) instead of starting a second server.workflow-mcp/state exposes the event union
and pure reducer with no filesystem, MCP, or Codex code, so a renderer can
project run state without pulling server code into its bundle.The Docker-first standalone product needs no host Node or Codex installation. It ships one
project-scoped daemon, a Codex MCP proxy, terminal UI, optional local web UI, isolated credentials,
and durable named-volume state. Start with the verified release and operator guide in
standalone/README.md; the full decisions and support boundaries are in
standalone/docs/adr.
For core-library development, Node ≥ 20.19 is required. A source checkout can build and test both the provider-neutral runtime and isolated standalone package:
Then drive a workflow from the CLI:
Once served, both workflow_resume({ runId: "wf_..." }) and
workflow_run({ resumeFromRunId: "wf_..." }) discover that Claude run inside
the scoped project's Claude state. Use claudeRunPath only when duplicate
historical metadata requires explicit selection.
Every newly completed service run stores one immutable UTF-8 result artifact. The compact
workflow_run_status.run.result reference and the run.completed event both include its
artifactId, media type, total UTF-8 byte count, line count, and SHA-256 checksum. When
truncated is true, inline content is only a display prefix; it is not the complete result.
workflow_result_read accepts only a scoped runId plus that opaque artifactId—never a
filesystem path. Pages default to 16 KiB and may request 4 through 65,536 bytes. Page ends are
moved backward when necessary so concatenating content never splits a UTF-8 code point:
Factual signals from GitHub, npm, and our automated checks — not a rating.
No reviews yet — be the first to share how this listing worked for you.
Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.
[](https://allmcps.com/mcp/workflow-mcp)<a href="https://allmcps.com/mcp/workflow-mcp"><img src="https://allmcps.com/api/badge/workflow-mcp?style=directory" alt="Workflow MCP on AllMCPs" /></a>