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

The description discloses that the tool reports whether binaries were found, their versions, and feature flags, and gives a concrete example of a build without WaveGen. It also mentions install hints for missing tools. While no annotations are provided, the description carries the behavioral burden well, though it could mention whether it modifies anything (it appears read-only).

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 compact and front-loaded with the core purpose, then details the specific checks and a concrete example. Every sentence adds value, and the install-hint note is useful without being verbose.

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 zero-parameter environment probe with an output schema present, the description fully covers what the tool does, what it reports, and when to use it. The output schema presumably details the return structure, so the description doesn't need to explain return values. Nothing critical is missing.

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 tool has zero parameters, so the schema provides no parameter semantics. The description compensates by explaining what the tool checks and reports, which is sufficient for a no-argument probe tool. Baseline 4 for zero params is appropriate.

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 states the tool's purpose: probing the DualSPHysics toolchain for paths, versions, and solver features. It names specific binaries (GenCase, CPU solver, PartVTK, MeasureTool) and distinguishes it from sibling tools that perform actual simulation tasks.

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 explicitly instructs to call this tool first, and notes that missing tools come with install hints. This provides clear when-to-use guidance and implies it should precede other tools like run_case or validate_dambreak.

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?

The description discloses the primary behavior: it runs an external tool and writes multiple output files, and it explains defaults for output_dir, out_name, and save_modes. However, with no annotations, it omits side-effect details such as overwriting behavior, directory creation, environment requirements, and failure modes.

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 a one-line summary followed by a compact bullet list of five parameters with defaults. There is no filler; every line adds operational detail.

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 five parameters, zero annotation coverage, and no schema-level parameter descriptions, the description covers all invocation essentials, and the output schema covers return values. It is slightly incomplete on selecting this tool relative to siblings and on prerequisites/environment, but it is sufficient to invoke 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?

Schema description coverage is 0%, so the description must supply parameter meaning. It does so fully: xml_path accepts *_Def.xml with or without extension; output_dir and out_name have explicit defaults; save_modes is tied to GenCase -save and 'all' is expanded; extra_args is illustrated with an example.

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 opening line names a specific action ('Run GenCase') and defines the resource transformation (case XML → Case.xml + Case.bi4 + optional VTKs). This makes the tool's scope clear and separates it from simulation/post-processing siblings, though it never names those alternatives explicitly.

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 explicit when-to-use or when-not-to-use statements; the presence of sibling tools such as run_case and validate_dambreak is not leveraged. The intended use is only implied by the XML-to-case-file conversion description, so an agent must infer when this step is needed.

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, the description carries the full burden. It does a strong job by disclosing the exact return contents, including pid/returncode, simulated time vs tmax, percent, step counters, throughput, projected finish time, particle counts, and the Run.out tail. It does not explicitly state that polling is side-effect-free, but "poll" and the data returned convey a read-only status operation.

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 provides a dense, useful list of return values. Every sentence earns its place, and there is no redundant or promotional language.

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 the tool's low complexity, one parameter, and an existing output schema, the description is mostly complete. It over-delivers on return-value detail and clearly explains the polling behavior. The main gap is not explaining job_id provenance or when exactly to call this relative to run_case, but these are minor for a status-polling tool.

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 for the single required job_id parameter. It does not mention job_id by name, its format, or how to obtain it (e.g., from run_case). The tool's overall purpose implies job_id identifies a background job, but that is only indirect and does not add meaningful parameter-level guidance.

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: "Poll a background solver job". It enumerates exactly what the status digest contains (state, pid/returncode, progress counters, throughput, etc.), which makes it distinct from siblings like run_case and validate_dambreak.

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 polling use case and implicitly distinguishes it from launching (run_case) or validating (validate_dambreak). It does not explicitly name alternatives or state that job_id should come from a previous run_case call, but the context is clear enough for this simple status tool.

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, the description carries the behavioral disclosure burden. It reveals meaningful behaviors: interpolation produces CSV time series, points beyond the surge front read 0, defaults are fluid-only density, and extra_args can override output settings. It does not cover failure modes or side effects beyond file outputs, but it is still substantially 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 well structured: a one-line purpose, a focused use-case paragraph, then a compact args list. Every sentence contributes useful information, and the most important usage guidance is front-loaded.

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 complex tool with 9 optional parameters and no annotations, the description covers all parameters, a realistic validation workflow, defaults, and file outputs. The only notable gap is that neither job_id nor dirdata is marked required in the schema, and the description does not explicitly state that at least one of them must be supplied.

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%, yet every parameter is explained in plain language. The description clarifies the job_id/dirdata alternative, gives a concrete pointsdef example, and notes the default variable and particle filters. This fully compensates for the empty schema descriptions.

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 opening sentence 'MeasureTool: interpolate SPH values at points -> CSV time series' names a specific verb, resource, and output format. It also ties the tool into the dam-break validation workflow, distinguishing it from siblings like validate_dambreak and partvtk.

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 a concrete when-to-use scenario: for dam-break validation, use a horizontal line of points just above the bottom, with density as the default variable. It explains the resulting surge front behavior and how validate_dambreak consumes it, but it never explicitly states when not to use this tool or how it compares to siblings.

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 of behavioral disclosure. It does reveal the output destination (savevtk default), the filtering behavior (onlytype default fluid only), and the write intent (produces VTK). But it does not disclose whether input .bi4 files are preserved, how filters interact, or error/edge-case 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 purpose sentence is front-loaded and the parameter list gives each argument a single efficient line. Compact enough that every line earns its place, though a dense arg-list format is slightly less scannable than prose for an agent.

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?

With an output schema present, return values need no further explanation. The description covers purpose and all parameters. Minor gap: it doesn't clarify that job_id and dirdata are mutually exclusive alternatives with neither strictly required, nor whether at least one must be supplied for successful 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 fully compensates by documenting all 8 parameters with meaningful detail: relationships (dirdata as alternative to job_id), defaults (savevtk, onlytype), example values (variables '+idp,+vel,+rhop,+press'), and semantics (first/last as index range, onlytype as filter). Every parameter gains meaning beyond the bare schema.

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?

States a specific verb (convert), a concrete input resource (Part_*.bi4 particle files), and an output format (VTK for visualisation). The purpose is unambiguous and clearly distinguishes it from siblings like gencase, run_case, and job_status, none of which perform file conversion.

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 'for visualisation' clause gives context for when the tool applies, and the sibling set makes the conversion role obvious. However, there is no explicit when-to-use guidance, no exclusions, and no mention of dependencies such as requiring a completed run_case/job_status before conversion is possible.

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 does so well. It discloses that execution is backgrounded, that a job_id is returned, where outputs land, that restart/cancel are unsupported, and how solver flags can be passed via extra_args.

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, then gives concise behavioral context and a structured Args list. Every sentence earns its place, and the parameter list is easy to scan.

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 6-parameter tool with no annotations and an output schema present, the description covers the important workflow context: prerequisites, output locations, defaults, and limitations. An agent can call this tool correctly with the information provided.

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. Every parameter is explained with its meaning, defaults, and an example for extra_args. This adds substantial value beyond the raw JSON schema.

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: 'Start the CPU solver in the BACKGROUND and return a job_id.' It clearly distinguishes run_case from siblings like gencase (preprocessing) and job_status (tracking progress).

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 explicitly states the prerequisite of running gencase first and points to job_status for progress tracking. It also notes that restart/cancel are not implemented, giving useful exclusions. It does not explicitly name alternatives or say 'use this when X', but the context is 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?

With no annotations available, the description carries the full burden and discloses the algorithm: it reconstructs front position per output time as the furthest point above the wetness threshold, then reports per-time errors, MAE, RMSE, and max error in metres and as % of column length. It also reveals the column-order mapping and the max_time filtering behavior, giving an agent a concrete model of what happens when invoked.

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 purpose, then a terse method sentence, then a compact Args block. Each line carries distinct information, and no filler or repetition of schema defaults is present.

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 seven-parameter validation tool with no annotations and no schema descriptions, the description explains how the CSV, points, points_file, threshold, column_length, experiment, and max_time all interact. The presence of an output schema covers return structure, so the missing output details do not create a practical gap.

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 0% description coverage, but the Args list fully compensates: csv_path is identified as the MeasureTool history CSV, points are given an exact shape and ordering, threshold gets concrete reference values (500 kg/m^3 for rhop; ~0.05 for vel), and column_length is explained as normalisation. This is above and beyond the raw JSON schema.

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 names a specific verb ('Validate'), a specific resource ('a 2D dam-break run'), and the comparison benchmark ('dam-tip front vs Koshizuka & Oka (1996)'). This clearly separates it from sibling tools like measure_tool, which produces the input CSV rather than validating it.

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 says the tool 'Reads the CSV produced by measure_tool with the SAME points definition', which makes the prerequisite workflow and relation to a sibling explicit. It does not state explicit exclusions or alternative conditions, but the intended post-measurement use is clear enough.

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