Skip to main content
Glama

draft_job

Read-only

Drafts Slurm job scripts for MUSICA using tested runbook patterns, returning the script and static checks without submitting anything to the cluster.

Instructions

Draft a Slurm job script for MUSICA from the runbook's tested patterns; nothing is sent to the cluster. kind: cpu (part of a CPU node: cores, mem_gb), cpu-node (whole CPU nodes), gpu (1-3 GPUs on a shared node: gpus; shared nodes can take hours to start), gpu-node (whole H100 nodes; with vllm_model: vLLM servers on every node, vllm_servers_per_node 1/2/4 = TP4/TP2/TP1, and command as their client on the first node). command: the work (shell lines); with nodes > 1 it runs once on every node ($NODE_RANK, $NNODES, $HEAD). time: minutes or HH:MM:SS; dev=True uses the dev QoS (at most 10 min, 2 nodes): test there first. array: e.g. 0-9%2 ($TASK in the script). python_env: a venv path (e.g. $DATA/envs/train); container: a .sif (prefix commands with run); modules: Lmod modules to load. runs (gpu-node, 1 node): up to 8 commands in parallel on one whole node, run r on GPU r % 4 ($RUN, own caches, log logs/--r.log; the job fails if any run failed; command runs first as setup); run_minutes: one estimate per run (refused if the slowest exceeds time). array_args: one argument string per array task (sets --array=0-(n-1)%throttle; the task gets $ARGS and $OUT=results/--a); array_throttle: tasks at once (0 = within the approval limits); not together with array. vllm_preset: tested serve settings for some models, 'qwen38-fp8' or 'glm53-fp8' (flags for one TP4 server per node; model and image default to $DATA/models/ and $DATA/containers/, which you must download first, or set vllm_model/vllm_image; vllm_args are appended, later flags win); load_cap_s: drop a vLLM server whose weights are not loaded this many seconds after its node's launch (60-3600). Drafts check at job start that the env, container and model exist (exit 2 otherwise), set HF_HUB_OFFLINE=1 on GPUs and OMP_NUM_THREADS=1 for vLLM. Returns the script, the static check (estimate, approvals needed) and notes; then check_job(script_text=...) for sbatch --test-only and the path checks on the cluster.

Input Schema

NameRequiredDescriptionDefault
devNo
gpusNo
kindYes
nameYes
runsNo
timeNo00:10:00
arrayNo
coresNo
nodesNo
mem_gbNo
commandNo
modulesNo
containerNo
vllm_argsNo
array_argsNo
load_cap_sNo
python_envNo
vllm_imageNo
vllm_modelNo
descriptionNo
run_minutesNo
stage_modelNo
vllm_presetNo
array_throttleNo
vllm_servers_per_nodeNo

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?

Annotations already declare readOnlyHint=true and the description corroborates and enriches it: no cluster contact, job-start existence checks that exit 2, HF_HUB_OFFLINE=1 and OMP_NUM_THREADS=1 side effects, the failure semantics for parallel runs, run_minutes being refused when the slowest exceeds time, and load_cap_s dropping a stalled vLLM server. This is exactly the beyond-annotations context the dimension rewards.

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 purpose and the 'nothing is sent to the cluster' guarantee are front-loaded, and nearly every clause maps to a parameter or behavior, so the extreme density is largely earned by a 25-param tool. Readability suffers somewhat from prose-embedded enumerations and heavy parenthetical nesting, but there is little outright waste.

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?

Given a 25-parameter tool with no schema descriptions and no output schema, the description supplies the return contract ('Returns the script, the static check (estimate, approvals needed) and notes') and hands off to check_job for cluster-side validation. An agent can call this correctly without opening any other field, with only minor param gaps (stage_model) remaining.

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 25 parameters and 0% schema description coverage, the description carries the whole burden and does so for most of them — kind variants and their dependent params, gpus, nodes, command scoping ($NODE_RANK/$NNODES/$HEAD), time formats, array syntax with $TASK, array_args/$OUT convention, vllm_preset flag inheritance. Gaps remain: `name`, `description`, and `stage_model` are never explained, and `array_throttle`'s 'approval limits' is left vague.

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+resource ('Draft a Slurm job script for MUSICA from the runbook's tested patterns') and immediately bounds the scope with 'nothing is sent to the cluster', which cleanly separates it from submit_job. It also names the natural follow-up (check_job) and implies the draft→check→submit pipeline without ambiguity.

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?

Gives concrete usage guidance: 'dev=True uses the dev QoS ... test there first' and an explicit exclusion ('array_args ... not together with `array`'), plus the next step via check_job. It does not state when to prefer this over job_templates or explicitly say 'call this before submit_job', so it stops just short of full routing guidance.

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