Windmill for background jobs
Windmill is a code-first job and workflow platform you run yourself, and its official MCP server lets an agent drive the same scripts and flows your team already maintains. Among the four picks for background jobs it lands fourth, because the platforms ahead of it are built around durability and event-driven retries as their core promise, while Windmill's strength is that it executes your existing code.
That ranking is about emphasis, not capability. If you already operate a self-hosted Windmill instance, this server is the most direct path: the agent runs a script you wrote, watches the resulting job, and manages the flows behind it without you wiring up a separate queue client.
How Windmill fits
The tools that do the background-job work are runScriptByPath, which runs a script and returns the job it produced, and runScriptPreviewAndWaitResult, which runs synchronously when the agent needs the answer in-line. Around those, listScripts and getScriptByPath let the agent find and inspect what is available, createScript adds new work, and the flow tools (listFlows, getFlowByPath, createFlow, updateFlow) handle multi-step jobs. deleteScriptByPath and deleteScriptByHash clean up versions.
The honest gap is the durable-execution surface. The exposed tools run scripts and flows and hand back a job, but they do not include direct controls for schedules, signals to a paused step, or replaying a crashed run, the things long-lived jobs lean on. Temporal is the stronger pick when a job must survive a process crash and resume exactly where it stopped, and Inngest fits event-triggered functions that need built-in retries and concurrency limits without you running the infrastructure. Trigger.dev sits between them as a developer-friendly runner. Reach for Windmill when the job is a script you already own and the platform is already yours.
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 schedule a job to run later?
- The server's exposed tools run scripts and flows on demand (runScriptByPath, runScriptPreviewAndWaitResult) and manage their definitions. They do not include schedule-management tools, so for recurring or deferred runs you configure schedules in Windmill itself or reach for a platform like Inngest.
- When does Windmill beat Temporal for background jobs?
- When the job is a script your team already runs on a Windmill instance you operate. Temporal is the better choice when a job must be durable across crashes and resume mid-flow; Windmill's edge is executing your existing code, not durable replay.
- Does the agent need to write new code to use this?
- Not necessarily. listScripts and getScriptByPath let it discover and inspect scripts you already wrote, then runScriptByPath executes them. createScript and createFlow are there if you do want the agent to add new work.