Skip to main content
Glama

submit_job

Submits a batch job after runbook checks and records it in the local ledger, requiring a script path, purpose, and human approval for expensive jobs.

Instructions

Submit a batch job after the runbook checks (see check_job) and record it in the local ledger. script: the path of the job script on the cluster, relative to cwd (default: the configured workdir); script text is refused (check a draft with check_job(script_text=...), then save it in the project, push_files, submit). The job is submitted on hold, checked against Slurm's own reading of it, and released (or cancelled if Slurm reads it differently and it then breaks the rules). purpose: one line on what the job is for. approval: the human's explicit approval in their words (who, what, limit); required above the approval limits ([limits] in the config; by default ≥ 4 nodes at once, > 20 tokens including your other jobs), for B200 and long/priority QoS; a job of 16 or more nodes (headsup_nodes) needs an approval that names its node count, even inside an approved budget. Refused when a model, container, env or input the script reads does not exist on the cluster (unless the job has a --dependency, or allow_missing=True for a job that fetches or creates them itself before use: then a warning). Pass each sbatch option and its value as separate items. expected_minutes: your runtime estimate (a --time far above it is flagged).

Input Schema

NameRequiredDescriptionDefault
cwdNo
scriptYes
purposeYes
approvalNo
sbatch_argsNo
script_argsNo
allow_missingNo
expected_minutesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Goes well past the annotations by disclosing the submit-on-hold → validate-against-Slurm → release-or-cancel sequence, the refusal conditions (missing model/container/env/input), the --dependency and allow_missing=True warning paths, and how the approval gate is enforced. These are operational behaviors an agent could not infer from readOnlyHint/destructiveHint/openWorldHint.

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?

Front-loads the core action and secondary effect in the first sentence, then documents parameters in order. Every clause is substantive, but the heavy parenthetical nesting and run-on enforcement clauses (approval thresholds, dependency/allow_missing carve-outs) make it denser than needed.

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

Completeness4/5

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

For an 8-parameter mutation tool with no output schema and 0% schema coverage, the description covers submission flow, validation, refusal conditions and the approval gate thoroughly. Gaps are minor: `script_args` is undocumented and it does not say what comes back (job ID, ledger entry) on success.

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?

Schema coverage is 0%, so the description must carry the load and it mostly does: `script` (path semantics, relative to `cwd`, default workdir, text refused), `purpose`, `approval` (detailed thresholds), `sbatch_args` ('pass each sbatch option and its value as separate items'), `expected_minutes`, and `allow_missing` are all explained. `script_args` is never mentioned and `cwd` is only referenced obliquely, so it falls short of full coverage.

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 ('Submit a batch job') and adds the two secondary effects: runbook validation and recording in the local ledger. It also names the related sibling ('see check_job'), so an agent can distinguish this from check_job and draft_job without inspecting either schema.

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

Usage Guidelines5/5

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

Explicitly routes away from wrong usage: 'script text is refused (check a draft with check_job(script_text=...), then save it in the project, push_files, submit)' names the alternative tools and the ordering. It also gives concrete when-required conditions for `approval` (node count, token threshold, B200/long/priority QoS, headsup_nodes).

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