Default tool for starting one non-interactive command of uncertain duration.

Every command is a durable Job from launch. Commands that finish within the inline timeout return their ordinary bounded result. Longer or queued work returns a detached Job handle without cancelling the workload. Omit queue to use an operator-configured default queue for the selected target.

Do not use this tool for explicit fire-and-forget or batch fan-out; use submit_job. Do not use it when an MCP Tasks handle is explicitly required; use run_job. Do not use it to resume an existing job_id; wait for or inspect that job instead. If a detached handle is returned, keep its job_id and call wait_for_job once when the result is needed rather than polling status.

Explicitly submit one asynchronous or fan-out job without waiting.

Omitted backend and host values use the Awaitless configuration defaults. Reuse client_request_id only when retrying the same logical submission; an identical retry returns the original job and a conflicting retry is rejected. A named queue provides FIFO, non-preemptive admission for local or SSH work. Slurm options may contain account, constraint, cpus_per_task, gres, mem, nodes, ntasks, partition, qos, or time. Cluster config supplies defaults.

Do not use this as the default for a single command with uncertain duration; use run. Do not use it for MCP Tasks creation; use run_job. Do not resubmit merely because a client disconnected or a wait timed out: keep the original job_id, or retry the identical logical submission with the same client_request_id if the creation response was lost.

MCP Tasks compatibility entry point for explicitly creating a Task handle.

A client declaring io.modelcontextprotocol/tasks receives a Task handle immediately. Older clients block and receive the ordinary final tool result. The stable client_request_id makes a lost creation response safe to retry.

Do not choose this for ordinary command execution: use run. Do not choose it for generic asynchronous submission or fan-out: use submit_job. Only retry a lost Task creation with the same client_request_id and identical arguments.

Wait once for a known job_id and consume its durable terminal result.

Returns state, exit code, bounded logs, and declared Artifacts. A client-side timeout or disconnect does not cancel the Job; call this tool again later with the same job_id. Do not use it to start work, do not poll it repeatedly, and use wait_for_completions instead when collecting several independent Jobs.

Collect durable terminal results across multiple known jobs after a cursor.

Existing completions return immediately. Otherwise the call waits until at least one selected job completes or the optional call-level timeout expires. Reusing the same cursor replays results; advancing to next_cursor consumes the returned batch. A timeout never cancels a managed job.

Submit all independent jobs before calling this tool. Treat delivery as at-least-once: process and deduplicate by completion_id before advancing the cursor. Do not use this for one job, do not poll get_job_status between continuation calls, and never resubmit active jobs after a waiter disconnects.

Get one immediate, non-waiting state snapshot for a known job_id.

Use only when the caller needs current status now. Do not use this to wait for completion or build a polling loop; use wait_for_job for one Job or wait_for_completions for several. This tool never starts or retries work.

Inspect bounded stdout and stderr tails for a known failed or stalled job.

Use after a terminal wait reports failure, timeout, stall, or loss and its bounded result needs focused diagnostics. Do not use as a progress stream, do not repeatedly tail a running healthy Job, and do not use it instead of wait_for_job to learn that work completed.

Cancel a durable job without relying on a client-side process handle.

List recent durable jobs, optionally filtered by state or host.

Create an immutable named FIFO queue with a fixed concurrency limit.

List named queues and their current queued/active job counts.