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

With no annotations, the description carries the full burden of behavioral disclosure. It discloses that edits are literal find/replace, reviewable, and recorded in the fix log, and it explicitly enumerates refusal conditions (removing output requests or deleting most of the deck). This goes beyond a basic description and gives the agent concrete behavioral expectations. It does not mention error outcomes or asynchronous behavior, but the core behavior is 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-organized: a summary sentence, a behavioral note on edit semantics and refusals, and a parameter list. It is somewhat verbose but appropriately detailed for a complex tool. There is minor redundancy (e.g., 're-run it' and 'on the re-run' in max_iters), but overall structure supports clarity.

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 covers the tool's purpose, parameters, constraints, and logging, and an output schema exists so return details are not needed. It adequately states the context ('parked design') and the refusal rules. Missing are potential adherence to before calling (e.g., whether the design must be parked) and whether the operation is synchronous, but these are likely implied by the absence of references to job creation. Overall, the essentials are present.

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's 'Args' section is the only source of parameter semantics. It explains all six arguments, including the format of edits_json (JSON list of find/replace pairs), the role of rationale (recorded), max_iters (deterministic fix iterations), and cpus (solver CPUs). This fully compensates for the absent 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 description clearly states the action ('apply a reasoned deck edit') and the target ('a parked design'), and distinguishes it from siblings by emphasizing the 'reasoned' nature and the re-run behavior. It also explains the literal find/replace mechanism and the fix log, which separates it from automated correction tools like autocorrect_simulation.

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 clear context: it is for repairing parked designs with reasoned edits, and it explicitly states what edits are refused. However, it does not explicitly mention when to prefer this tool over siblings, particularly autocorrect_simulation, nor does it offer exclusions or named alternatives. The 'reasoned' qualifier implies a contrast but is not made explicit.

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 it does disclose the critical traits: it mutates the input deck ('editing the deck'), runs an external solver, retries up to max_iters, and returns a narrative. The main gap is that it does not say whether the original deck is backed up, modified in place only, or left in its fixed state afterward — notable for a file-mutating tool.

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, adds the return behavior in one sentence, and then presents a clean Args block. Every sentence earns its place — the parameter documentation is necessary precisely because the schema has 0% coverage. There is no redundant or filler text.

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 5-parameter mutation tool with no annotations and 0% schema coverage, the description covers purpose, all parameter semantics, the return narrative, and the key side effect. An output schema exists, so return details need not be spelled out. The remaining gaps are modest: no rollback/backup behavior, no guidance on what happens when max_iters is exhausted, and no explicit routing against sibling tools.

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 fully does: the Args block adds real meaning to all five parameters — inp_path gets its file format, job_name gets its defaulting behavior, max_iters gets its scope, cpus gets its purpose, and timeout_s gets its unit and per-run scope. Every parameter is documented beyond what the bare schema provides.

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 uses a specific verb-resource pairing ('Run a job and autonomously fix failures... by editing the deck') and names concrete failure types (convergence, singularity, deck errors) plus the diagnostics sources (.sta/.msg/.dat). This clearly distinguishes it from siblings like run_simulation (plain run), apply_reasoned_fix (single fix), and get_fix_log (read-only log), so an agent can tell them apart without opening schemas.

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 intended use is implied — call this when you want an autonomous run/fix loop with retries — but the description never explicitly says when to prefer it over run_simulation or apply_reasoned_fix, nor does it state exclusions (e.g., 'use run_simulation if you do not want the deck modified'). Guidance is inferable from the purpose statement but not made explicit.

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 burden. It discloses that the tool autonomously runs and error-corrects, supports multiple iterations, and returns stats plus a narrative. However, it omits side effects such as job creation, persistence, or whether it can modify the original spec/model, which matters for an autonomous 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 summary sentence is front-loaded and informative, and the Args block is compact. Minor redundancy exists between 'full pipeline' and the detailed pipeline steps, but overall every element earns its place.

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 pipeline tool with no annotations, the description covers core inputs, outputs, and the autonomous fix behavior, and an output schema exists. Still, it does not clarify job lifecycle behavior, failure handling, or which circumstances call for this versus the separate build/simulate/fix siblings, so completeness is only partial.

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%, but the description fully compensates by explaining all three parameters: spec_json is a simulation spec JSON referencing get_spec_template, job_name defaults to the spec's model_name, and max_iters controls run/fix iterations. This is precisely the semantic guidance the schema lacks.

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 what the tool does: it builds a model from a spec (CAD import, mesh, physics), then runs and error-corrects it, returning build stats and a run narrative. This distinguishes it from siblings like build_model or run_simulation by positioning it as the full end-to-end pipeline.

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?

There is clear contextual signal that this is the 'full pipeline' tool, implying use it when you want building, simulation, and error-correction in one call. However, it does not explicitly name alternatives or state when not to use it, so the agent must infer the selection from sibling tool names.

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 discloses the core behavior (build, export deck, return path/stats/errors) and explicitly says it does not run the simulation. However, it omits side effects such as file creation location, overwrite behavior, prerequisites (e.g., existence of CAD files), or any environmental requirements. It also doesn't mention whether the operation is reversible or if it validates the spec before building.

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 main purpose and the critical 'WITHOUT running it' distinction. The subsequent details and an Args section are structured and to the point. Each sentence contributes meaning; there is no filler. It's slightly verbose but appropriately so for a tool with two parameters.

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 tool is complex (imports CAD, meshes, applies BCs/loads) and has an output schema, but the description doesn't fully cover prerequisites, failure modes, or detailed spec structure beyond pointing to a template. It also doesn't mention whether validation is expected prior to calling. The pointer to get_spec_template helps, but for a build operation with no annotations, more explicit guidance on input requirements and side effects would be needed for full completeness.

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 value. It explains spec_json as a JSON string and points to get_spec_template for format, and specifies job_name is optional with a default to the spec's model_name. This goes beyond the bare schema and gives an agent enough to construct correct arguments.

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 uses a specific verb ('Build') with a clear resource (simulation spec) and output (.inp deck), and explicitly states 'WITHOUT running it' to distinguish from run_simulation and build_and_simulate. It also enumerates the sub-steps (CAD import, meshing, materials/BCs/loads) and return values, making the tool's purpose unmistakable.

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 implies usage context by stating it builds without running, which suggests using this when only a mesh/deck is needed. It also references get_spec_template for spec creation, providing a pointer to a companion tool. However, it does not explicitly name alternatives like build_and_simulate or validate_simulation_spec, nor state when NOT to use it. Still, the 'WITHOUT running it' is a clear differentiator.

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 provided, so the description carries full responsibility for behavioral disclosure. 'Report' implies a non-mutating read-only operation, but it does not explicitly state that there are no side effects, no permissions needed, or other behavioral details. It adequately conveys the primary behavior but leaves some safety aspects to inference.

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?

A single sentence that is front-loaded and free of filler. Every word adds information, and it does not repeat schema or annotation content.

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 tool with an output schema, the description is nearly complete. It clearly states the tool's purpose, and the output schema covers return structure. It could be slightly richer by noting it is safe to call (no side effects) or when to use it, but such gaps are already partially covered by other dimensions.

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?

There are zero parameters, so the baseline is 4. The description adds no parameter-specific meaning (none needed), and the empty schema fully covers parameter expectations.

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 uses a specific verb ('Report') and states exactly what is reported ('whether Abaqus is available' and 'where jobs will run'). It clearly distinguishes this from siblings like run_simulation or list_jobs, none of which cover environment checking.

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 implies usage as a preliminary environment check, but provides no explicit when-to-use guidance or mention of alternatives. An agent can infer its role from the name and purpose, but there is no direct guidance on when to invoke it relative to other tools.

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 and meets it by stating the tool reads the energy balance and reports whether the answer can be trusted, listing three concrete failure conditions. The verbs 'reads' and 'reports' also imply a read-only analysis with no side effects.

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 tightly structured: a one-sentence purpose, a short context statement, the key failure modes, then clean Args. Every sentence adds information and no filler 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 two-parameter analysis tool with an output schema present and no annotations, the description covers the input precondition (completed job), what the tool inspects, the criteria it uses, and the meaning of the optional flag. Nothing essential for correct invocation 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?

Schema coverage is 0%, so the description compensates by explaining both parameters: job_name identifies the job to judge, and quasi_static gives a meaning-based condition with a concrete example and clarifies when kinetic energy matters. The job_name description is thin, but the quasi_static semantics are detailed and actionable.

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: 'Judge whether a COMPLETED job is physically believable.' It further differentiates from status-only tools by stating that a green solver status only means the analysis reached the end, so this tool is the one to use for physical and energy-based trustworthiness.

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 clear context: use after a completed job when you need to know whether the result can be trusted, with explicit examples of failure signals. It does not name sibling alternatives or state when not to use the tool, so it stops short of full exclusion guidance.

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 burden of behavioral disclosure. It clearly states the tool is read-only, as it retrieves a record without any mutating language (no 'create', 'update', 'delete'). It also reveals that it includes both successful and unsuccessful fixes, which is useful context. However, it doesn't disclose potential performance implications (e.g., large logs) or whether it might be expensive to call. The behavioral disclosure is adequate but could be more thorough.

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 moderately concise, with an initial one-sentence summary followed by an 'Args' section. However, the initial summary repeats the tool name 'fix log' and could be tightened. The Args section is redundant given the schema, adding little value. There is no excessive fluff, but the structure could be improved by front-loading the exact purpose and why the sweep argument matters.

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 has an output schema, the description needn't explain return values, which is fine. The tool is simple with a single parameter, and the description covers its purpose and key attributes. However, there is no mention of what kind of data the log contains in terms of structure (though output schema covers that) or any potential performance considerations. It lacks guidance on what to do with the returned log, such as referencing it for further actions. Overall, it's sufficient but not complete for an agent that might need to decide whether to call it.

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 schema has zero description coverage for the 'sweep' parameter, and the description merely says 'The sweep name.' This adds minimal context beyond the schema—it clarifies it's a name but doesn't explain what a sweep is or how to find valid sweep names. However, the description is inherently tied to the parameter, and the overall description's first sentence indirectly explains the parameter's context. For a single simple string parameter, the description provides some semantic value, but it's not extensive.

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 a specific verb+resource ('get fix log') and defines scope ('every reasoned fix attempted in a sweep'), which is somewhat clear. However, it relies heavily on the tool name, and could be more distinctively differentiated from siblings like 'get_parked_failure' and 'apply_reasoned_fix'. The description does mention 'successful or not' and lists key aspects, but doesn't explicitly contrast with related tools.

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 mentions the argument 'sweep' but provides no context on when to use this tool versus alternatives. It does not state any exclusion criteria or suggest sibling tools. The usage guidelines are essentially absent, only implying it's for retrieving fix logs for a named sweep.

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 provided, so the description carries the full burden. It says 'parse' which implies a read-only operation, but does not explicitly state that it does not modify anything. It also does not disclose behavior when files are missing or the job does not exist. This is adequate but not rich.

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?

A single sentence with no fluff. The primary action ('Parse') is front-loaded, and the description is concise and to the point.

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 one parameter and an output schema present, the description does not need to detail return values. It adequately explains what the tool does for a simple read operation. It could mention error handling or what 'current' means, but for this simplicity, it is nearly complete.

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. The description mentions 'a job' which clearly maps to the job_name parameter, giving it meaning beyond a bare string. However, it does not specify any constraints or format details, leaving the parameter semantics thin.

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 a specific verb ('Parse') and a clear resource ('current output files of a job') and the outcome ('return a status summary'). It is not a tautology and clearly distinguishes from siblings like read_job_file (which reads a specific file) and list_jobs (which lists 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 implies usage: when you have a job name and need a status summary, this is the tool. However, it does not explicitly mention alternatives or when not to use it. The guidance is implicit through the verb and resource, but lacks explicit routing or exclusions.

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 of behavioral disclosure. It clearly signals a read-only retrieval action ('Return an example spec') and clarifies that it does not consume a CAD file, but it does not explicitly state side-effects, safety, or that nothing is built or modified. For a simple getter this is adequate but not richly 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?

Two tight sentences with no filler. The primary action is front-loaded, and the second sentence adds the secondary output without repeating anything from the schema.

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 no-parameter retrieval tool, the description covers the key context: what is returned, the parametric/no-CAD distinction, and the supporting list of shapes and params. Since an output schema exists, the exact return structure is already captured externally, so nothing essential 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 there is no parameter meaning for the description to add beyond the schema. Per the baseline for zero-parameter tools, this is handled well since no parameter documentation is needed.

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?

Description states a specific verb ('Return') and resource ('an example spec'), and clarifies the distinguishing trait: the spec builds geometry parametrically with no CAD file. It also mentions the second deliverable (supported shapes and required params), making the tool's function unambiguous and distinguishable from the sibling get_spec_template.

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 implies when to use the tool: when the user needs a parametric spec example rather than a CAD-based one. However, it does not explicitly name alternatives or state when not to use it, so the agent is left to infer the boundary against sibling tools like get_spec_template.

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 burden and does well by listing exactly what is returned: solver status, error-level diagnostics, tails of .sta/.msg, input-processor errors, validity verdict, attempted fixes, and the deck itself. It also clarifies how deck_chars truncates the .inp. It does not explicitly state that the operation is side-effect-free or mention auth/rate limits, but the 'Returns...' framing strongly implies a read-only diagnostic.

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 tool's purpose, followed by a compact list of return contents and an Args block. Each sentence adds information and there is no 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?

Given the tool's moderate complexity, the description covers why to call it, what it returns, and what each parameter means. The presence of an output schema relieves the description of needing to detail return types. The only gap is the absence of when-to-prefer-it over close siblings.

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 Args section must compensate; it gives a meaningful one-line explanation for each parameter. 'sweep: The sweep name' and 'deck_chars: How much of the .inp to include' add semantics beyond the bare schema. It could be stronger with format or constraints, but it is adequate for a 3-parameter tool.

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: 'Full diagnostics for one parked design' and then lists exactly what is returned. It clearly differentiates from list_parked_failures by being scoped to a single parked design and by focusing on diagnostics. It does not explicitly name sibling alternatives, but the scope and return list make the purpose 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?

The phrase 'to reason about before fixing' gives an explicit usage context: use this when you need to understand a parked failure prior to applying a fix. It does not mention alternatives or when not to use it, so an agent is left to infer the boundary against list_parked_failures, inspect_deck, or check_validity.

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 provided, so the description carries the burden of behavior disclosure. It communicates a prerequisite (finished job) and implies a read-only reporting operation, but it does not explicitly state side effects, permissions, or behavior on unfinished or missing jobs.

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?

A single well-structured sentence that front-loads the action and resource while enumerating the exact outputs. There is no filler, and every clause earns its place.

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 supplies the source (.odb), the precondition (finished job), and the set of returned headline results. The output schema presumably covers the return shape, so the main remaining gap is behavioral detail like error handling, which is modest for a simple extraction 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?

The schema has 0% description coverage and the description never mentions job_name beyond the general 'job' context. The parameter is self-explanatory as a string identifier, but the description adds no format, validation, or usage detail beyond the schema's bare 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 uses a specific verb ('Extract and report') and names a concrete resource ('a finished job's .odb'), followed by an explicit list of the headline metrics. This clearly distinguishes it from sibling tools like run_simulation, get_job_status, and read_job_file.

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 phrase 'from a finished job's .odb' gives a clear condition for when to call this tool: the job must already be complete. It does not explicitly name alternatives or exclusion cases, but the context is strong enough for an agent to determine when this tool is appropriate.

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 provided, so the description carries the behavioral burden. It explicitly states the tool returns a JSON template and implies a read-only, non-mutating action through 'Return an example...'. It does not claim side effects or hidden behaviors, making it transparent for a zero-parameter getter.

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?

Two short sentences with no wasted words. The first sentence front-loads the action and output, and the second provides immediate usage guidance. Every sentence earns its place.

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, read-only getter with an output schema available, the description is fully sufficient. It states what is returned, that it is a fill-in template, and why an agent would use it. No additional context is needed 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?

The tool has zero parameters, so parameter semantics is not a source of difficulty. The schema documents the empty parameter set, and the description correctly avoids inventing parameters. A baseline of 4 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 uses a specific verb ('Return') and a precise resource ('an example simulation spec (JSON)') and clarifies that it shows every field the model authoring pipeline accepts. It is clearly distinct from validation, building, and running tools, and the second sentence reinforces its role as a starting template.

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 clear context for when to use the tool: 'Fill this in to describe a new simulation.' It does not explicitly name alternatives or exclusions, so it falls short of a 5, but the intended usage is unambiguous.

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 provided, so the description carries the burden. It discloses the tool's output type (a friendly greeting) and its non-destructive nature implicitly. However, it doesn't specify the exact format or content of the greeting, which is a minor gap for such a simple tool.

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?

A single sentence that is perfectly sized for the tool's simplicity. No wasted words, and the action 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 zero-parameter, no-side-effect utility, the description is complete enough. An output schema exists, so return values are presumably structured there. The only minor gap is not specifying the greeting's exact wording, but that is unlikely to impede 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?

The tool has zero parameters, so the schema is trivially complete. The description adds no parameter details because none are needed. Baseline 4 for zero-parameter tools 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 states a clear verb ('Return') and resource ('a friendly greeting'), which is sufficient for a zero-parameter utility tool. It doesn't explicitly distinguish from siblings, but none of the listed siblings appear to overlap with greeting functionality, so the 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?

The description implies a simple, unconditional use case: when a friendly greeting is needed. It doesn't explicitly state when not to use it or mention alternatives, but given the tool's trivial nature and lack of overlapping siblings, the implied usage is adequate.

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 transparency burden and meets it: it explicitly says the tool only reads the file, requires no solver, consumes no licence token, and reports dangling references in addition to defined content. This gives an agent a strong safety/behavior profile.

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?

Every sentence adds information: summary, detailed contents, safety behavior, and parameter semantics. The description is front-loaded with the core purpose and stays compact despite the tool's complexity.

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 single-parameter read-only inspection tool, the description covers purpose, input semantics, behavioral constraints, and scope of report. An output schema exists, so not detailing the return structure is acceptable.

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 schema provides only a bare string property, so the description's Args section is essential and sufficient: 'Path to the .inp deck, or a job name under the runs directory.' It fully defines the single parameter's accepted forms.

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-resource pair: 'Summarise what is actually in an Abaqus input deck.' It then enumerates the exact content categories (mesh, materials, sections, sets, steps, loads, BCs, dangling references), which clearly differentiates it from sibling tools like check_validity or read_job_file.

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 makes the intended use clear: inspect a deck's real contents without running it. The phrase 'Reads the file only: no solver, no licence token' tells an agent when this tool is appropriate versus simulation tools, though it does not explicitly name alternatives or state when not to use 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 carries the full burden of behavioral disclosure. It communicates an enumeration operation with the word 'List' and scopes it to what the engine knows, which implies this is a read-only listing of run directories. However, it does not explicitly state side-effect-free behavior, ordering, pagination, or any engine-specific constraints, leaving some transparency gaps.

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 front-loaded sentence with no filler: 'List all jobs (run directories) known to the engine.' Every word contributes meaning, and the parenthetical clarification is placed directly after the noun it explains. It is appropriately sized for the tool's simplicity.

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 parameterless listing tool with an output schema available, the description covers the essential scope: all jobs, defined as run directories, known to the engine. It does not need to explain return values because an output schema exists. The main missing element is guidance about how this relates to sibling tools, but that is captured under usage guidelines rather than completeness.

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 parameter documentation is not a burden. The description adds useful context by explaining that 'jobs' are 'run directories,' which helps an agent interpret the resource being listed even though no inputs are required. This matches the baseline for a parameterless tool.

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 a specific verb and resource: 'List all jobs (run directories) known to the engine.' It clarifies that jobs are run directories and that the tool enumerates all of them. It does not explicitly call out a sibling alternative, so it lacks a deliberate differentiation statement, but 'all jobs' versus siblings like get_job_status implies a broad enumeration rather than a targeted lookup.

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 no guidance on when to choose this tool over siblings such as get_job_status, read_job_file, or sweep_status. There is no mention of prerequisites, exclusions, or a 'when not to use' condition. The only implied context is that listing all jobs is the tool's purpose, which is not enough to support a naming decision among related tools.

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 burden and does provide useful behavioral context: these designs are 'waiting for judgement' and are included only if they failed to converge or were rejected by the physical-validity gate. It does not explicitly state read-only behavior or ordering, but 'List' plus the inclusion criteria covers the core 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 core purpose is front-loaded in the first sentence, the definition of 'parked' is compact but informative, and the sibling pointer plus Args section add no redundant content. Every sentence earns its place.

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 one-parameter list tool, the description covers what is listed, why the items are parked, how to retrieve details for one item, and the required argument. The output schema handles return shape, so no essential calling information 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 only parameter is documented as 'The sweep name', which adds a minimal semantic role beyond the bare string type in the schema. However, it does not explain where valid sweep names come from, naming conventions, or behavior for a nonexistent sweep, so it is adequate but not rich.

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 ('List') and resource ('designs a sweep could not resolve on its own'), and the second sentence defines precisely what 'parked' means. It is also clearly distinguished from get_parked_failure, which is for reading one failure's diagnostics.

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 frames this as the overview tool for unresolved sweep results and explicitly directs the agent to get_parked_failure when per-design diagnostics are needed. It does not list exclusion conditions, but the intended use is evident from the context.

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 burden of behavioral disclosure. It conveys a read-only operation ('Return the tail') and enumerates the allowed file extensions, but it does not mention failure behavior for missing files, invalid extensions, or oversized max_lines. Some useful detail is present, but notable edge-case behavior is omitted.

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 behavior in the first sentence. The Args section covers all parameters with no redundant prose, and every line adds useful information.

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 simple parameterized read operation, the description covers the purpose, behavior, and parameter semantics. The presence of an output schema reduces the need to document return values. It is slightly incomplete only in not addressing error scenarios or emphasizing when this tool is preferable to sibling result-retrieval tools.

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 fully compensate. It does so: job_name is explained as 'The job to inspect', extension lists the exact allowed values and the important detail 'without the dot', and max_lines defines 'trailing lines'. This adds meaning beyond the bare schema titles and defaults.

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 a specific action ('Return the tail'), a clear resource ('a job's output file'), and a precise scope ('tail', 'for inspection'). This makes it clearly distinct from siblings like get_results, list_jobs, or get_job_status, which target different resources or operations.

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 explains what the tool does but gives no guidance on when to use it instead of alternatives such as get_results or list_jobs. There are no explicit 'use this when' statements or exclusion criteria, so an agent must infer the appropriate context.

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 mentions timeout and returning a status report, but it does not disclose side effects such as writing solver files, modifying the workspace, requiring an Abaqus environment, or whether the run is safe to repeat. For an execution tool, this is a significant transparency gap.

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 clear purpose sentence, followed by compact parameter documentation. Every line earns its place, with no redundant or filler content.

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 covers all parameters and points to a status report output, and an output schema exists to define return values. However, it lacks workflow context such as prerequisites, side effects, relationship to build_model or check_environment, and when an agent should choose this over start_sweep. It is adequate for invocation but not fully complete.

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%, but the description's Args section documents all four parameters clearly: inp_path's format, job_name's default behavior, cpus' purpose, and timeout_s as a wall-clock ceiling. This fully compensates for the schema's lack of 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 description states a specific verb and resource: 'Run a single Abaqus job from an .inp deck' and explicitly says it returns a status report. 'Single' also distinguishes it from sweep-oriented siblings, so an agent can tell this apart from start_sweep or build_and_simulate.

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 word 'single' implies this tool is for one-off jobs rather than sweeps, giving some contextual clue. However, there is no explicit statement of when to use this tool versus siblings like start_sweep, build_model, or build_and_simulate, and no exclusions are provided.

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 to lean on, the description fully carries the behavioral burden. It discloses that the tool blocks, is resumable, runs each design through autocorrect and a validity gate, parks failed/unbelievable results rather than dropping them, and creates a results directory named after the sweep. This goes well beyond a basic summary.

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, followed by behavioral details, a practical blocking warning, and a compact parameter list. Every sentence adds useful information with no filler or repetition of the schema.

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 tool with five parametersative, no annotations, and an output schema available, this description is complete: it explains side effects, resumability, failure handling, blocking semantics, and parameter meanings. An agent can safely invoke and interpret this tool without seeking additional context.

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: sweep_name doubles as the results directory, designs_json has a concrete JSON shape, max_iters and cpus are scoped per design/solver run, and quasi_static is defined as controlling the judgment of the event.

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: 'Run a parametric sweep.' It then clarifies the distinguishing behavior — parking failures and unbelievable results with diagnostics instead of dropping them — which clearly separates it from sibling tools like run_simulation or sweep_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 explicit usage context: it blocks until completion and advises keeping design count small from an interactive client. It also names the alternative approach for long unattended sweeps — running the sweep module as a detached process — which is clear when-to-use and when-not-to-use guidance.

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 for behavioral disclosure. It clearly states the tool summarizes counts and points to the results table, but it does not mention side effects, read-only nature, error behavior for nonexistent sweeps, or whether any state is modified. This is adequate for a simple status query but not rich.

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 a single high-signal summary sentence followed by a short parameter definition. No words are wasted, and the structure makes the main behavior immediately clear.

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 has only one parameter, an output schema, and a relatively simple behavior, the description is nearly complete. It specifies the output content (counts and table location) and the parameter meaning. It lacks only usage-context guidance, but that is adequately covered by other dimensions.

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 only declares a string property with no description, so the description's 'Args' section is essential. It compensates well by explaining that 'sweep' means the name given when the sweep was launched, which clarifies exactly what value the agent should pass.

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 names a specific verb ('Summarise') and a concrete resource ('a parametric sweep'), and further specifies the scope by listing status categories and the results table location. It is clearly distinguishable from sibling tools like 'start_sweep' or 'get_results', though it does not explicitly name an alternative.

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?

There is no guidance on when to use this tool versus alternatives such as 'get_results', 'list_parked_failures', or 'get_job_status'. The phrasing implies it is for checking sweep status after a launch, but no explicit when-to-use or when-not-to-use conditions are provided.

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 of behavioral disclosure. It explicitly states the tool does not run anything, implying read-only behavior, and describes the return format ('valid' or a list of problems). It does not mention potential errors or side effects, but these are minimal for a validation tool.

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 two short sentences with no filler. It front-loads the primary purpose and immediately conveys the key behavioral constraint (no execution) and output format. Every word earns its place.

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 simple single-parameter validation tool, the description covers the purpose, input format, output, and the key behavioral trait (non-execution). The existence of an output schema is hinted at by the description, and the agent has enough to call it correctly without further context.

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 schema only defines spec_json as a string with no description. The description compensates by specifying it is a 'simulation spec (JSON string)', which clarifies the expected format and semantic meaning. This adds substantial value 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?

The description clearly states the verb 'Check', the resource 'a simulation spec (JSON string)', and the specific action 'against the schema'. It also distinguishes itself by noting 'without running anything', which separates it from simulation execution tools like run_simulation and build_and_simulate.

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 clear context that this is a validation step performed before running a simulation. However, it does not explicitly name alternative tools like check_validity or specify when not to use this tool, so it stops short of full exclusion guidance.

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 conveys a read-only lookup of release history and explains the special version behaviors (current vs. all), but it does not mention side effects, error cases, prerequisites, or response behavior beyond what the output schema would cover.

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 economical: the core purpose is front-loaded in a single sentence, followed by a focused Args section. There is no filler or redundant restatement of the schema, so every sentence earns its place.

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 single-optional-parameter release-notes tool, the description covers the overall purpose, version format, and current/all behavior; the output schema handles return-value details. It could add error behavior for unknown versions, but the basic invocation path is fully specified.

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 only declares version as a string with a default (0% description coverage), while the description fully compensates: it provides a concrete format example ('0.3.0'), explains that omitting the parameter selects the current release, and defines the special value 'all'. This gives the agent exactly the semantic detail needed to call the tool correctly.

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 reports release changes ('What changed in this release, and in earlier ones'), clearly identifying the resource as the release history. It lacks an explicit imperative verb like 'List' or 'Get', and does not differentiate it from siblings such as get_fix_log or sweep_status, so it is clear but not fully distinguished.

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 explicit invocation guidance for the version argument: omit it for the current release or pass 'all' for the whole history. However, it does not state when to prefer this tool over alternatives or mention any exclusion conditions, leaving tool-selection context 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.