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_cancelA | 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 has a clearly targeted purpose: submit, list, status, logs, events, cancel, preempt, worker list, and worker delete are all distinct. The only mild ambiguity is between cancel and preempt for running jobs, but descriptions clarify the preemptible requirement and final state.
All tools share a consistent 'jobd_' prefix, but verb placement varies: some are imperative verbs (jobd_submit, jobd_cancel), some are nouns (jobd_events, jobd_status), and one is noun-verb (jobd_worker_delete). This is mostly readable but not perfectly uniform.
Nine tools is a well-scoped set for a job broker: job lifecycle, monitoring, debugging, and worker management are each covered without unnecessary redundancy. The count feels appropriate for the domain.
The core job lifecycle is covered: submit, list, status, cancel, preempt, logs, events, and worker fleet management. Minor gaps like job deletion/purging or retry/resubmit are absent, but agents can work around those with existing tools.