Windmill for workflow orchestration
Windmill turns scripts and multi-step flows into runnable units, and its official MCP server hands an agent the ability to execute and inspect them. For workflow orchestration it ranks fourth of four, not because it cannot orchestrate, but because the task here centers on long-lived, reliable processes with retries and durable state, and the three engines ahead of it treat that as their primary design goal.
Where Windmill earns its place is code-first internal automation: the operational glue, the cron-style maintenance flow, the script that stitches two internal systems together. If that work already lives in a Windmill workspace you run, this server lets the agent kick it off and read it back rather than guess at its state.
How Windmill fits
An agent orchestrating with this server uses runScriptByPath to start a step and get back its job, runScriptPreviewAndWaitResult when it needs the result before moving on, and the flow tools to handle the multi-step pieces: listFlows and getFlowByPath to find and read a flow's definition, createFlow and updateFlow to build or change one, deleteFlowByPath to remove it. listScripts, getScriptByPath, and createScript cover the individual scripts a flow is built from.
The limit worth stating plainly: these tools define and launch flows, but they do not expose durable orchestration controls, no signaling a waiting step, no querying a long-running execution's history, no replay after a crash. Temporal is the stronger pick when a workflow must run for hours or days and survive failures with exactly-once guarantees. Inngest fits event-driven, serverless orchestration with retries you do not have to host. Trigger.dev targets developer workflows triggered from your own code. Choose Windmill when the workflows are your own scripts on your own instance and you want an agent to run and inspect them directly.
Tools you would use
| Tool | What it does |
|---|---|
| listScripts | List the scripts in the workspace. |
| createScript | Create a new script. |
| getScriptByPath | Get a script's metadata and content by its path. |
| deleteScriptByHash | Delete a specific version of a script by its hash. |
| deleteScriptByPath | Delete a script by its path. |
| runScriptByPath | Run a script by its path with the given arguments and return the resulting job. |
| runScriptPreviewAndWaitResult | Run a script preview synchronously and wait for the result. |
| listFlows | List the flows in the workspace. |
| getFlowByPath | Get a flow's definition by its path. |
| createFlow | Create a new flow. |
FAQ
- Can the Windmill MCP server monitor a long-running workflow's progress?
- It starts flows and returns the resulting job (runScriptByPath, runScriptPreviewAndWaitResult) and reads flow definitions (getFlowByPath), but the exposed tools do not include rich execution-history or signaling controls. For durable, long-lived monitoring, Temporal is the stronger fit.
- What kind of orchestration is Windmill actually best at here?
- Code-first internal automation: operational scripts and flows your team maintains in a Windmill workspace. The agent can run them with runScriptByPath and assemble flows with createFlow and updateFlow, which suits internal tooling more than durable, long-lived workflows.
- How does it differ from Temporal and Inngest for this job?
- Temporal is built for durable execution that survives crashes; Inngest for event-driven serverless functions with retries you do not host. Windmill's exposed tools run and manage your existing scripts and flows, so it wins when the workflow code is already yours.