jobd
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JOBD_URL | No | http://127.0.0.1:8765 | |
| JOBD_API_TOKEN | No |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| jobd_submitA | Submit a job to the jobd broker. Default async; pass wait=true to block up to wait_timeout_s (server clamps to 270). |
| jobd_statusA | The full JobInfo record for one job_id: state, exit_code, timings, host, and the scheduling internals — depends_on + cascade policy (depends_on_any_exit), pending cancel/preempt signal, resolved profile, requires (gpu/tags/idempotent), host pin, fast_path, timeouts, termination_reason. Use for a quick state check AND for debugging why a job routed/failed/stalled. Pass wait=true to block until terminal or wait_timeout_s. |
| jobd_logsA | Tail the captured stdout/stderr of a job (workers stream output to the broker's per-job log as it runs). Returns log_tail (last tail_bytes, default 8 KiB, max 1 MiB) plus size_bytes/returned_bytes/truncated — works for running AND finished jobs. Use to check progress mid-run, diagnose a failure's traceback, or grab a job's final output. |
| jobd_cancelB | Cancel a job (queued → cancelled; running → SIGTERM via worker signal poll, ~2s). |
| jobd_preemptA | Preempt a running/assigned preemptible job (worker SIGTERMs with grace; final state 'preempted'). Refused if not preemptible or not running. |
| jobd_listA | List jobs on the broker with per-state counts. Defaults to the active set (queued/assigned/running); filter by state (e.g. ['failed']) or project to find past runs. Each row is a compact summary: job_id, project, state, host, exit_code, queued_at, started_at — call jobd_status for a job's full record. Use to answer 'what is running / queued right now?' or to locate a job id you've lost. |
| jobd_eventsA | The broker's event stream — the surface that explains WHY, not just what. /jobs says a job is queued; only this says it has been skipped 400 times because no worker advertises cuda-32gb, or that its dependency was cancelled, or that a watchdog killed it. Filter by since (2h/3d/1w), event type, job_id, project, or source (broker|worker). Use when a job is not doing what you expect and jobd_status alone does not explain it. |
| jobd_workersA | Fleet snapshot: every registered worker with state (online/stale/offline), live capacity ad (free_vram_gb, unregistered_vram_gb, free_ram_gb, idle_cpus), capability tags (cuda tiers, arch/os), slot usage (running/max_concurrent), and last_heartbeat — plus an overall health rollup (healthy|degraded|empty). Use before submitting GPU work to see what's free, or to diagnose why a job isn't being dispatched. |
| jobd_worker_deleteA | Remove a worker from the broker registry. The broker refuses (409) if the worker is still online — caller stops the worker process or waits for the heartbeat sweeper first. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool targets a distinct operation: status/logs/cancel/preempt/list/events/workers/worker_delete/submit. There is no overlap between them; even status vs events are clearly differentiated (state snapshot vs why-events).
All tools follow a consistent jobd_<verb> or jobd_<noun>_<verb> pattern (jobd_status, jobd_logs, jobd_cancel, jobd_preempt, jobd_list, jobd_events, jobd_workers, jobd_worker_delete, jobd_submit). The pattern is uniform and predictable.
9 tools is well-scoped for a job scheduling/broker domain: submit, inspect (status/logs/list/events), control (cancel/preempt), and fleet management (workers/worker_delete). Each tool earns its place.
The surface covers the full job lifecycle: submit, status, logs, cancel, preempt, list, events, and worker management. Minor gaps like resubmit or job deletion are absent, but the core scheduling workflow is complete.