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

With no annotations, the description carries the full burden, but it does not state whether the operation is read-only or requires authentication. More importantly, it claims 'Every known job' while the schema shows a default limit of 20, suggesting the list is limited and not actually every job. This creates a transparency gap about the tool's real behavior.

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

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

The description is a single, compact sentence with no wasted words. It front-loads the core subject ('Every known job') and delivers the key dimensions (order and state) efficiently. For a simple list tool, this is an ideal length and structure.

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

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

The description is incomplete for a tool with no annotations and an underspecified schema. It does not explain the limit parameter's effect, the read-only nature, or when to use it relative to siblings. Although an output schema exists, key operational context is missing, leaving an agent uncertain about how to invoke it correctly.

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

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

The only parameter, 'limit', has zero schema description coverage, and the description does not mention it at all. The description's phrase 'Every known job' actively obscures the fact that the limit parameter controls how many jobs are returned. The description provides no semantic help for the parameter.

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

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

The description clearly indicates that the tool lists all known jobs with their current state, newest first. It implies a listing operation and distinguishes itself from siblings like casino_status or casino_results by covering all jobs rather than a specific one. It lacks a direct verb like 'list', but the intended purpose is unambiguous.

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

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

No guidance is provided about when to use this tool versus the sibling tools. There is no mention of use cases, exclusions, or alternatives such as casino_status for a single job's status. The description only states what the tool does, not when to choose it.

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

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

With no annotations provided, the description fully carries the behavioral burden: which files are copied, which are excluded, symlink handling, default filling, validation checks, refusal behavior, warnings, and precedence rules. This is exceptionally transparent.

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

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

The description is long, but every paragraph earns its place given the domain complexity. It is front-loaded with purpose, then systematically covers file selection, parameters, and validation behavior without redundancy.

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

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

For a 7-parameter tool with no annotations, this description is complete: all parameters are explained, valid runtypes are enumerated, defaulting and overrides are specified, and refusal/warning behavior is disclosed. The presence of an output schema covers return-value specifics.

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

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

Schema description coverage is 0%, so the description must compensate and does so thoroughly: runtype values and defaults, overrides precedence and %block behavior, jastrow/backflow semantics, and jastrow_settings defaults. Even the required source/dest parameters are clear from context.

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

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

The first sentence states the exact action: copy a calculation into a new directory and write the input for the next run. The workflow explanation and examples make it clearly distinct from sibling tools like casino_run or casino_status.

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

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

The description gives strong workflow context ('This is how a calculation becomes the next one') and concrete examples, and it explains why copying rather than editing is required because casino_run refuses a directory that already holds a run. It stops short of explicitly naming when-not-to-use alternatives such as 'use casino_run to execute instead'.

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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It explains that values come from CASINO-printed data, that missing values return null with a reason, that running DMC results are read from dmc.status, that dmc.status is deleted on completion, and that casino_stop preserves the last estimate. This is rich, non-obvious behavioral context.

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

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

The description is long but information-dense, with each paragraph covering a distinct behavioral area: output contents, phase semantics, running jobs, and equilibration. The structure is front-loaded with purpose and then deepens into edge cases. The awkward opening phrase 'Physics out of a job's files' slightly reduces clarity but does not waste space.

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

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

Given that an output schema exists and the tool has only one parameter, the description is unusually complete. It covers completed runs, running DMC runs, stopped runs, equilibration, value provenance, and the meaning of `result`. An agent has enough context to invoke the tool correctly and interpret its results in most scenarios.

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

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

The input schema has one required parameter, job_id, with 0% schema description coverage, and the tool description never mentions job_id explicitly. It refers to 'a job's files' and 'this run,' but it does not explain how job_id selects the job, where to obtain valid job IDs, or any constraints. Because schema coverage is low, the description was expected to compensate and did not.

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

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

The description states that the tool reads a job's `out` file and returns energies, error bars, variance, per-block numbers, and phases, which clearly identifies it as a results-reading tool. It also explains the `result` field as the run's answer, giving concrete purpose. It does not explicitly name sibling distinctions, but the resource and operations are clear.

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

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

The description provides useful conditions for when this tool is appropriate, especially for running DMC runs, saying it is 'the only way to read one.' It also covers stopped runs and equilibration states. However, it never explicitly contrasts the tool with casino_status or casino_list_jobs, so alternative routing is only implied rather than stated.

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

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

With no annotations provided, the description carries the full burden, and it delivers: it discloses that the calculation outlives the call and server restart, that `out` is appended to and can corrupt results, that restart is destructive to `config.in` and optimization output, and how resume behaves under different halting conditions. This is deep, honest behavioral disclosure.

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

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

The description is long but every sentence earns its place. It is front-loaded with the core purpose, then organizes the non-obvious behavioral details and parameter semantics in a structured, scannable way. The density is justified by the tool's complexity and destructive options.

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

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

Given a 6-parameter tool with no annotations, the description is exceptionally complete: it covers prerequisites, launch semantics, background persistence, destructive behavior, failure conditions, and parameter interactions. The presence of an output schema relieves it from detailing return values, so nothing critical is missing for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate, and it does thoroughly. Every parameter — workdir, nproc, version, restart, resume, unlock — gets meaningful explanation beyond its name, including relationships like nproc counting total vmc_nstep, version being a binary flavour, and the precise effects of restart versus resume.

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

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

The description opens with a precise verb and resource: 'Start a CASINO calculation in workdir and return immediately.' It clarifies that the runtype comes from the input file and that this tool only controls binary launch, making it easy to distinguish from siblings like casino_prepare, casino_status, and casino_stop.

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

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

It gives strong when-to-use and when-not-to-use guidance: directories with existing `out` are refused, restart and resume are opposites, resume is refused for completed runs, and restart is refused when NEWRUN : F is set. It does not explicitly name sibling alternatives for common flows, but the contextual sibling list makes the intended role clear.

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

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

No annotations are present, so the description must carry the behavioral burden. It does disclose the status vocabulary and returned metrics, and 'state of one job' strongly implies a read-only query. However, it does not explicitly state that it has no side effects, how unknown or expired job IDs are handled, or whether it is safe to poll repeatedly.

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

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

The description is a single sentence with no filler. It front-loads the core scoping ('State of one job') and then lists the concrete status and metric fields, so every word adds value.

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

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

For a low-complexity one-parameter status query, the description is largely complete: it defines the job scope and the returned state fields, and the output schema covers the return contract. The main omissions are explicit usage routing and side-effect disclosure, but the tool is simple enough that the given information allows a correct call.

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

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

Schema description coverage is 0%, so the description must add meaning to job_id. It adds minimal context by indicating the parameter refers to the specific job whose state is checked, but it does not mention job_id by name, explain how to obtain a valid value, or provide any format guidance beyond the schema's string type.

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

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

The description clearly identifies the tool as reporting the state of a single job and enumerates the key fields returned (status, pid, runtime, exit code). The phrase 'one job' helps separate it from casino_list_jobs, but it does not explicitly contrast with casino_results or other siblings.

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

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

Usage is implied rather than stated: an agent can infer that this tool is for checking an individual job's status after invoking casino_run. There is no explicit guidance about when to use it instead of casino_results, casino_stop, or casino_list_jobs, and no mention of prerequisites such as having a valid job_id.

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

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

With no annotations provided, the description carries the full burden and succeeds. It details that SIGTERM targets the job's casino processes, that runqmc survives to write output, that the current block is lost, and that haltqmc -f -u tidies the directory for resumption. It also explains the timeout fallback behavior.

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

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

The description is front-loaded with the core purpose and then adds only high-signal behavioral details. Every sentence contributes meaningful operational knowledge without repetition or filler.

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

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

For a side-effect-heavy tool with no annotations, the description is remarkably complete: it covers signal behavior, persistence of completed data, loss of current block, directory cleanup, resumption path, and timeout semantics. An output schema is present, so explaining return values is not necessary.

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

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

Schema coverage is 0%, so the description must compensate. It fully explains timeout as the seconds a job gets before its process group is killed, but job_id is left to its schema title and the contextual phrase 'running calculation.' The main parameter is not explicitly defined or sourced.

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

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

The description opens with a specific verb and resource: 'Stop a running calculation and leave its directory ready to be continued.' This clearly distinguishes casino_stop from the sibling tools casino_run, casino_prepare, casino_status, casino_results, and casino_list_jobs.

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

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

The description clearly establishes the tool's purpose for stopping a running calculation and contrasts it with haltqmc -k's account-wide behavior, implying this tool is job-scoped. It does not explicitly enumerate when to use it over siblings, but the intended use is unambiguous in context.

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