Can the Windmill MCP server schedule a job to run later?

Yes. listSchedules and getSchedule inspect existing schedules, createSchedule sets a new one, updateSchedule modifies it, and deleteSchedule removes it. Alongside those, runScriptByPath and runScriptPreviewAndWaitResult handle on-demand runs. The full schedule lifecycle is managed directly from the agent.

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.

Windmill for background jobs

Pick 4 of 4 for background jobsOfficialWindmill

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 server also ships full schedule management: listSchedules and getSchedule discover what is already recurring, createSchedule and updateSchedule set up or modify timed runs, and deleteSchedule removes them. That covers the recurring and deferred job surface directly from the agent. The honest gap is durable-execution: the tools do not include signals to a paused step or replaying a crashed run, the things long-lived multi-day 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.

Full Windmill setup and config →

FAQ

Can the Windmill MCP server schedule a job to run later?: Yes. listSchedules and getSchedule inspect existing schedules, createSchedule sets a new one, updateSchedule modifies it, and deleteSchedule removes it. Alongside those, runScriptByPath and runScriptPreviewAndWaitResult handle on-demand runs. The full schedule lifecycle is managed directly from the agent.
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.