Skip to main content
Glama
cpietsch

Amadeus

by cpietsch
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

wait_for_job

Read-only

Waits for one or more Slurm jobs and returns at the first relevant event with new log lines since the last call, enabling progress monitoring without sleep or sacct watcher loops.

Instructions

Wait for one job (job_id) or several (job_ids) and return at the first event that matters, with the new log lines since the last call. Returns at the latest after max_wait_s (10 to 3600).

until: 'end' / 'all_end' = all jobs ended (default), 'any_end' = the first job ends, 'any_fail' = the first job ends other than COMPLETED (or all ended), 'start' = a job starts (or ends). Alarms always return at once:

  • milestones: [{pattern, within_s, file}]: a regex (Perl/Python style) grepped in the job's 'out' (default), 'err' or a path relative to its working directory (%j %x %a allowed). A match returns MILESTONE; no match within_s seconds after the job's start returns LATE (e.g. vLLM 'ready after \d+s' within 600).

  • quiet_alarm_s: QUIET when a RUNNING job's logs have not grown for that long (0 = off). vLLM compile and graph capture can be silent for about 3 min: use 300 for big runs, 120-180 while testing.

  • expect: output paths relative to the working directory (%j %x %a, globs): OUTPUTS_MISSING when a job ended without files written since its start (a COMPLETED state can hide a failed run). Events: STARTED, ENDED, FAILED, MILESTONE, LATE, QUIET, OUTPUTS_MISSING; failed jobs come with a diagnosis. finished: True = all ended, False = still running (an event or max_wait_s), None = cluster or job not found. Pass next_cursor back as log_cursor: you then get only new log lines and events you have not seen yet. State lives in Slurm: after a restart, a dropped connection or a compaction just call again with the same ids; alarms this server already returned for these jobs then come back as info and do not end the call at once. Never build sleep/sacct watcher loops or background monitors. Each poll is one SSH command for all jobs.

Input Schema

NameRequiredDescriptionDefault
untilNoend
expectNo
job_idNo
poll_sNo
job_idsNo
log_cursorNo
max_wait_sNo
milestonesNo
quiet_alarm_sNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/openWorld hints it discloses durable, non-obvious behavior: state lives in Slurm, so after a restart or dropped connection you just call again with the same ids, and alarms already returned come back as info without ending the call. It also bounds the call (max_wait_s 10–3600) and explains that 'a COMPLETED state can hide a failed run,' which is exactly the kind of nuance an agent cannot infer.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core behavior is front-loaded in the first two sentences before the option-by-option detail, and every clause carries real meaning (event names, tuning thresholds, failure diagnosis). It is dense to the point of reading as a wall of text, but there is no filler to cut.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a nine-parameter blocking tool with no output schema, the description covers what an agent needs: the returned event vocabulary (STARTED, ENDED, FAILED, MILESTONE, LATE, QUIET, OUTPUTS_MISSING), the tri-state 'finished' return including the not-found case, and cursor reuse. Only the poll_s interval is left unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage the description must carry all nine parameters, and it does: 'until' modes, the milestone object shape {pattern, within_s, file}, quiet_alarm_s values with tuning advice (300 for big runs, 120–180 for testing), expect globs with %j/%x/%a, and log_cursor round-tripping. The only undocumented parameter is poll_s, leaving a small tuning gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — 'Wait for one job (job_id) or several (job_ids) and return at the first event that matters' — plus what comes back (new log lines since the last call). This clearly distinguishes it from passive siblings like job_log, job_details, check_job and list_jobs by establishing that it blocks until a condition is met.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Never build sleep/sacct watcher loops or background monitors. Each poll is one SSH command for all jobs' gives explicit negative guidance that routes the agent away from manual polling. The 'until' mode list clarifies which condition to select for which outcome, though it never names a sibling tool as an alternative for non-blocking queries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools