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

The description adds critical nuance beyond the destructiveHint=true annotation: it clarifies that cancellation does not delete artifacts and preserves successful results. It also discloses asynchronous cleanup ('poll openvsp.batch_status'), signals active native work, and notes ownership restrictions. No contradiction with annotations; in fact, it refines the meaning of destructive behavior.

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

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

The description is three sentences, front-loads the primary action, and covers essential operational details (state updates, polling, ownership, retry) without excessive verbosity. Slight redundancy with the schema (e.g., empty case_ids meaning) but it does not bloat the text and the unique ownership/retry info 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 cancellation tool with asynchronous behavior, the description covers the key actions, parameters, state updates, cleanup polling, artifact preservation, ownership constraints, and retry path. Since an output schema exists, return format is handled. The only minor gap is not specifying the exact effect on in-progress work (only 'signals active native work'), but this is acceptable given the schema and annotations.

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 100% for both case_ids and batch_directory, and the tool description largely echoes the schema's semantics (empty case_ids means whole batch, unknown IDs fail, successful results preserved). The description does not introduce new parameter-specific details, so a baseline of 3 is appropriate since the schema carries the parameter burden.

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 action ('Request cancellation of selected case IDs, or the whole batch') and clearly identifies the resource (cases/batch). It also distinguishes its default behavior (empty case_ids cancels whole batch) from its sibling batch_resume, which is the opposite operation for retry. This makes the tool's role immediately 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?

Explicitly states when not to use this tool: 'a batch owned by another server must be cancelled through that owner.' It also directs the agent to the alternative batch_resume for retry-non-successful cases, and to poll batch_status for cleanup completion. These clear exclusions and alternative references provide excellent selection 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?

The description goes well beyond the sparse annotations by disclosing key side effects: it creates a new export directory on every call, does not run a solver, does not rewrite batch.json, and leaves existing artifacts untouched. This disambiguates the tool's non-destructive but additive 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?

Three sentences, each earning its place: first defines the output contents, second clarifies side effects, third routes to alternatives. No filler or redundant restatement.

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 one simple parameter, a well-documented input schema, and an output schema, the description provides everything an agent needs: purpose, side effects, output artifacts, and sibling alternatives. There are no significant gaps.

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 100%, and the schema already thoroughly documents batch_directory, including that it must be an existing directory at its original absolute location and that a fresh export directory is added there. The description adds output filenames and manifest contents, but no additional parameter-level meaning beyond the 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 names a specific action ('Export a saved batch manifest snapshot'), the exact resource (batch directory), and the output files (results.csv and results.json). It clearly differentiates itself from sibling tools batch_status and read_results by naming what those tools do instead.

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 routes the agent to alternatives: batch_status for a paginated progress summary and read_results for one operation manifest. This tells the agent when this export tool is and is not the right choice.

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?

Annotations include destructiveHint=true, and the description adds substantial context: it verifies identities and artifacts before updating state, reuses successful cases, rejects metadata-only updates, and launches background work. This goes beyond the annotation's simple destructive flag, clarifying the preconditions and side effects. A slight deduction for not detailing the exact state changes or output format, but the behavioral details are strong.

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 dense but information-rich, with each sentence earning its place. It front-loads the core purpose and then details conditions and exclusions. Slightly long for a single paragraph, but structured with semicolons to separate ideas. No redundancy.

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

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

Given the tool's moderate complexity (state changes, identity checks, background launch), the description covers the necessary preconditions and behaviors. An output schema exists (though not shown here), so return values are covered. Minor gap: it doesn't mention the exact failure behavior for batch_directory not found, but the schema hints at it. Overall, sufficient 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 schema already provides thorough descriptions for both parameters (case_ids and batch_directory), covering coverage 100%. The description adds context by explaining empty case_ids behavior (all non-successful cases) and emphasizing the idle requirement, which is not fully in the schema. This elevates from baseline 3 to 4.

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: retry selected non-successful cases in an idle batch, with explicit mention of reusing successful cases and rejecting identity changes. It distinguishes itself from batch_submit and batch_cancel by referencing those as alternatives, and the sibling list confirms these exist.

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 explicit when-to-use guidance: for retrying non-successful cases in an idle batch, with conditions (idle batch, source/package/binary identities unchanged). It also states when not to use it (for new batches use batch_submit, or use original runtime for identity changes), clearly routing to alternatives.

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 that it opens or creates .batch.lock to check runner ownership, and that it reports interrupted when a saved running batch has no owner. This adds context beyond the annotations (idempotentHint, destructiveHint) about side effects on the lock file, though it does not detail the lock file's exact behavior or permissions.

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 concise and front-loaded, starting with the core purpose, then side effects, then the explicit instruction to use batch_resume. Every sentence serves a purpose, though it could be slightly more concise by merging the lock file and owner check details.

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

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

Given that there is an output schema and the schema covers all parameters, the description provides sufficient context for an agent to call this tool correctly. It explains the key behavior around .batch.lock and the interrupted state, and directs to batch_resume for recovery. Minor gap: it doesn't explicitly state that the tool is safe to call repeatedly (though idempotentHint is true).

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 already covers all parameters with descriptions (100% coverage), including pagination bounds and the requirement for the batch directory to exist. The description adds the note about the lock file, but the parameter semantics are adequately covered by the schema, so a baseline 3 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 that the tool reads batch status, counts, and a paginated case summary, and explicitly notes that it does not rewrite batch.json or run a solver. It distinguishes itself from batch_resume, a sibling tool, by mentioning the 'running batch has no owner' scenario.

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 states when to use this tool (to read status) and when not to run a solver, and it directs users to use openvsp.batch_resume explicitly to retry interrupted batches. This provides clear guidance on alternatives.

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 highly relevant runtime behavior beyond the sparse annotations: it 'creates a durable batch directory and private model snapshots,' runs 'OpenVSP/VSPAERO in background workers while preserving the source,' and 'returns an initial status without waiting for completion.' It also explicitly states 'No automatic retry,' which is important side-effect information for an agent.

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 three dense sentences with no filler. The most important decision-relevant facts are front-loaded: the batch scope, independence, resource bounding, persistence, background execution, source preservation, and non-blocking return. 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?

For a complex batch-submission tool, the description covers the essential operational context: durable artifacts, private snapshots, source preservation, non-blocking behavior, no retries, and routing to lifecycle and blocking-alternative siblings. Since an output schema exists, omitting return-value details 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?

Schema description coverage is 100%, so the schema already documents the single request parameter and all nested fields thoroughly. The description adds conceptual framing like 'per-case settings/parameter edits' and 'bounded parallel jobs/CPU use,' but it does not add substantial parameter-level semantics beyond what the schema provides. Baseline 3 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 opens with a specific verb and resource: 'Submit 1-1000 independent steady cases with per-case settings/parameter edits and bounded parallel jobs/CPU use.' It clearly distinguishes batch_submit from the batch lifecycle siblings and from openvsp.sweep by contrasting background/non-blocking submission with a 'blocking sequential conditions list.'

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 tells the agent exactly which sibling tools to use for lifecycle control: 'use openvsp.batch_status, openvsp.batch_cancel, openvsp.batch_resume and openvsp.batch_export for lifecycle control, or openvsp.sweep for a blocking sequential conditions list.' It also states that there is no automatic retry, which helps set expectations for when this tool is and is not 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?

Annotations already declare destructiveHint=true and openWorldHint=true, and the description adds meaningful context: it retains model/script/log/manifest in a unique directory under output_dir, runs OpenVSP natively, and does not solve VSPAERO. It also warns that AngelScript may perform arbitrary file/external I/O with server privileges, which is critical behavioral disclosure beyond the annotations. Minor gap: it doesn't explicitly state that the unique directory is newly created or that existing files are not overwritten, but the 'unique directory' phrasing covers that.

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?

Three sentences, each earning its place: the first states the core function and scope, the second describes the run artifacts and the no-solve behavior, the third routes to the sibling for editing. Front-loaded and efficient.

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

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

The description is complete for a create tool with a rich schema and output schema present. It covers the key behavioral aspects (unique directory, no solve, arbitrary I/O risk) and sibling routing. It doesn't detail the output schema's contents, but the output schema itself carries that burden. A small gap is not mentioning that the tool is destructive (overwrites/creates new dirs) explicitly, but annotations cover that.

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 100%, so the schema already documents all parameters thoroughly. The description adds the high-level context that template and set_commands are the two ways to build the model, but it doesn't add meaning beyond the schema's own parameter descriptions. Baseline 3 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 creates a new .vsp3 model from a template or custom AngelScript, without an input model, and explicitly distinguishes it from openvsp.modify for editing existing models. The verb 'create' plus resource '.vsp3 model' and the no-input-model condition 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 description explicitly says when to use this tool (create new model without input) and when not to (use openvsp.modify to edit an existing source model). It also notes that no VSPAERO solve is performed, which helps route to run_vspaero or batch_submit for that need. This is strong usage 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?

Annotations are all false, so the description carries the full burden. It discloses it launches a temporary API probe and solver version command, explicitly says no solve or user model is involved, and notes status=error behavior when unavailable. This is meaningful behavioral context beyond annotations.

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?

Three compact sentences with the main purpose front-loaded. No filler or redundant phrasing; every sentence adds either scope, behavior, or routing to an alternative.

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?

Covers what is checked, how it is checked (probe + version command), what it returns on failure, and which sibling to use for model-specific checks. With an output schema present and zero parameters, nothing an agent needs to call it correctly 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 parametersches, so the schema fully covers parameter documentation. The description need not elaborate on parameters; baseline 4 is appropriate for a no-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 states a specific verb ('Check') and resource ('OpenVSP/VSPAERO readiness, versions, paths and package identity'). It also distinguishes itself from openvsp.preflight by explicitly narrowing scope to installed environment, not model geometry.

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?

Names the alternative openvsp.preflight and specifies that it is for checking a particular model's geometry sets. The statement 'no aerodynamic solve or user model is involved' clarifies what this tool is not for, though it does not provide an explicit 'when to use' rule beyond exclusion.

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 adds meaningful behavioral detail beyond the readOnlyHint annotation: it does not launch OpenVSP, write files, or modify source, and it fails on unreadable or invalid XML. This clarifies side effects and error behavior in a way annotations alone do not, and it is consistent with the readOnlyHint=true annotation.

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 three sentences, front-loaded with the primary purpose, and every sentence earns its place: what it reads, what it avoids doing, how it fails, and when to use an alternative. There is 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?

For a simple one-parameter read tool with an output schema, the description covers the input file handling, the non-mutating behavior, error conditions, and the appropriate alternative tool. The presence of an output schema removes the need to enumerate return fields in the description. Nothing essential is missing for correct invocation.

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

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

Schema description coverage is 100%, and the single parameter 'geometry_file' is already well-described in the schema with path semantics and tilde expansion. The tool description adds context about reading the file as XML and the kind of data extracted, but does not significantly enhance parameter-level meaning beyond what the schema already 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 identifies a specific verb ('Read'), a specific resource ('.vsp3 XML'), and the exact data returned (component IDs, wing names, component summary). It also explicitly distinguishes itself from openvsp.query by noting that query provides native parameter values or analysis defaults, making sibling differentiation clear.

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

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

The description explains when to use this tool: to read component and wing data directly from XML without launching OpenVSP. It also provides an explicit when-not by directing users to openvsp.query for native parameter values or analysis defaults, giving clear guidance on choosing between these 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation risk is known. The description adds valuable behavioral context: it runs on a snapshot, retains run artifacts, replaces the source only after validation, and refuses replacement if the source changed during the run. This goes beyond the annotations and gives the agent a clear safety model. It doesn't detail every side effect, but the snapshot/validation behavior is the key disclosure.

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

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

Three sentences with no filler. The core action, the safety behavior, and the alternative tool are all front-loaded. 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?

The description covers the essential operational context: snapshot execution, validation before replacement, artifact retention, and the no-solve constraint. The output schema exists, so return values don't need to be described. A small gap is that it doesn't explicitly say what happens to the run artifacts or how the agent learns whether replacement was refused, but the validation behavior is stated clearly enough for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents the request object and its nested fields thoroughly. The description adds the key semantic that this tool 'always modifies without solving' and that set_commands are 'trusted' with server privileges, but most parameter meaning is already in the schema. Baseline 3 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 opens with a specific verb and resource: 'Edit an existing model' via AngelScript and/or parameter ID/value edits. It clearly distinguishes itself from siblings by stating 'No VSPAERO solve' and pointing to openvsp.set_parameters for a focused typed-edit request. The title is null, but the description fully compensates.

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 states when to use this tool (editing an existing model with trusted scripts or parameter edits) and when not to ('No VSPAERO solve; use openvsp.set_parameters for a focused typed-edit request'). It also names the alternative tool, giving an agent clear routing 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 readOnlyHint=false and destructiveHint=true, the description carries meaningful safety burden and does so by disclosing that it runs on a private copy, retains artifacts, does not replace the source, and does not execute VSPAERO. It also states what it refuses to validate. It doesn't mention that set_commands can still perform arbitrary I/O, but that caveat exists in the schema, so the description is not contradictory.

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?

Three compact sentences front-load the core purpose, follow with behavioral safety guarantees, and end with exclusions and an alternative. No redundant wording; every sentence contributes decision-relevant 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?

The description covers purpose, scope, exclusions, safety model, and routing to the sibling solver tool. An output schema is present, so return-value description isn't needed; the description is sufficient for an agent to decide when to call preflight and what to expect.

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 100% and the request object already documents model and analysis settings in detail. The description adds only the context 'before a VSPAERO run' and 'without solving,' which clarifies intent but no new parameter syntax or constraints beyond the 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 opening sentence names the exact operation: 'Check selected thick/thin geometry sets before a VSPAERO run,' and lists concrete validation outcomes (rejects missing, empty, or overlapping sets; reports reference/unit warnings). It also distinguishes itself from run_vspaero by stating it does not execute VSPAERO or assess aerodynamic accuracy.

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 says this is a pre-run check and provides exclusions: it does not assess intersections, mesh quality, or aerodynamic accuracy. It names the alternative, openvsp.run_vspaero, for coefficients and verified solver-file settings, so an agent knows when to use each 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?

The description discloses useful runtime behavior beyond annotations: it runs OpenVSP, retains exports/model/script/log/manifest in a unique run directory, uses a private copy, preserves the source, and does not run VSPAERO. It does not mention that set_commands may perform arbitrary server-privileged I/O, but the schema covers that and destructiveHint already signals risk.

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 tight sentences. The first sentence states the core action, and the second packs retention behavior and alternative routing without redundancy. 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?

For a complex tool with a rich input schema and output schema, the description covers the key operational facts an agent needs: what files are produced, where artifacts are retained, that the source is not replaced, that VSPAERO is not run, and which sibling handles adjacent concerns.

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 100%, so the detailed request schema already documents all parameters, including parameter_edits, output_dir, and set_commands. The tool description adds only high-level context about private-copy edits and output file names, which is useful but does not meaningfully extend parameter semantics.

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: 'Export preview.svg and preview.stl for a model'. It also separates this tool from siblings by noting it does not replace the source or run VSPAERO, and briefly names openvsp.inspect and openvsp.preflight for different 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?

It gives clear context for when preview is appropriate: private-copy edits, exporting preview artifacts, no source replacement, and no VSPAERO. It explicitly routes file-only metadata to openvsp.inspect and geometry-set checks to openvsp.preflight, which is strong alternative 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 all annotations false, the description carries the behavioral disclosure burden, and it does so thoroughly: it states that OpenVSP is launched via temporary files, the source model is preserved, model-free capability lists may use a five-minute cache, and temporary files are removed afterward. It also surfaces the caveat that native defaults may depend on the model and may not be executable by the wrapper. This is strong, non-contradictory transparency.

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 three sentences with no filler, front-loads the primary purpose, and packs caveats and sibling routing into the remaining sentences. Every sentence earns its place, and the structure is easy for an agent 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?

Despite the tool's multi-mode complexity, the description covers all three query kinds, launch behavior, caching, source preservation, parameter applicability, and routing to relevant sibling tools. The output schema exists, so return-value details do not need to be restated in the description. Nothing critical is missing for correct selection and 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 100%, and every parameter already has a detailed description, so the baseline is 3. The description adds useful behavioral context such as the five-minute cache and model-dependent defaults, but it does not materially redefine or enrich individual parameter semantics beyond what the schema already 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 opens with a specific verb and resource: 'List installed analyses, read analysis input types/defaults, or read paginated geometry parameter IDs, values and limits.' It clearly enumerates three distinct modes and names the sibling alternatives (openvsp.inspect, openvsp.set_parameters), so an agent can distinguish this tool from its siblings without opening the schema.

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 explicit routing guidance: 'use openvsp.inspect for XML-only inspection and openvsp.set_parameters to apply returned IDs.' It also cautions that native defaults 'do not imply wrapper execution support.' However, it does not give when-not-to-use guidance against the broader sibling family (e.g., sweeps, batch jobs), leaving some inference required.

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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is known. The description adds specifics: it does not launch OpenVSP/VSPAERO, does not write files, and fails on missing coefficient names or invalid manifests. It also explains log tail behavior. This enriches the annotation without contradiction.

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 sentences that are dense and front-loaded: the core purpose and mode of operation come first, followed by a crucial usage caveat. Every clause earns its place, with no fluff or repetition.

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 readOnlyHint and openWorldHint annotations, the thorough input schema, and the presence of an output schema (implied), the description covers everything an agent needs to call it correctly: what it reads, what fails, and how to route non-manifest files. No critical 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?

Schema coverage is 100% with detailed descriptions for all parameters, including defaults and constraints. The description adds the hint 'Pass an operation's manifest_path as manifest_file', but the schema already states that manifest_file is 'Path to a saved operation manifest.json, as returned in manifest_path'. Thus the description adds little beyond the schema, so the baseline of 3 applies.

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 (read a saved operation manifest's coefficients, settings, diagnostics, and optional log tail) and clearly distinguishes it from batch.json usage by pointing to sibling tools. It names the resource (operation manifest) and the mode (without launching or writing files), making its 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?

It explicitly tells when not to use this tool (for batch.json) and directs to openvsp.batch_status or openvsp.batch_export, which is a clear exclusion. It also implies it is for operation manifests. It does not enumerate all possible alternative tools, but the key one is covered, so this is above average.

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?

Annotations indicate destructiveHint=true and readOnlyHint=false, but the description adds critical context: runs on a private copy without replacing the source, retains artifacts and settings, failures preserve paths, and success does not certify convergence. It fully discloses the mutation behavior and its safety guard. No contradiction; the private-copy detail actually clarifies the destructive hint.

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

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

The description is a single sentence, but packed with essential information: what it does, where it runs, what it retains, timeout semantics, failure behavior, and alternatives. It is front-loaded with the core function and then details, no wasted words.

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 a rich output schema (not shown but indicated as true), a complete nested request schema, and annotations that cover safety, the description covers all operational aspects. It answers the 'what, where, when, and alternatives' questions without redundancy.

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 covers 100% of parameters with detailed descriptions (e.g., request, analysis, case_name). The description adds no parameter-specific semantics beyond what the schema provides, and with full coverage, a baseline of 3 is appropriate. It does mention 'native timeout excludes preparation' which relates to timeout_seconds, but the schema already explains that.

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 runs one steady subsonic VSPAERO condition after geometry-set preflight, on a private copy, retaining artifacts. It distinguishes itself from sweep and batch_submit by name, exactly what the agent needs to differentiate.

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?

Explicitly says use openvsp.sweep for sequential conditions and openvsp.batch_submit for independent jobs, giving at least two alternatives and the condition for each. It also states prerequisites (geometry-set preflight) and timeout semantics, making usage 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?

Although destructiveHint=true already signals mutation, the description gives concrete behavioral detail: it verifies limits and readback, retains run artifacts, replaces the source only after validation, and rejects concurrent source changes. This is valuable context beyond the annotation and clarifies the tool's transactional 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?

Three dense sentences cover function, behavioral guarantees, and sibling routing with no filler. The most important action is front-loaded, and every clause provides 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?

Given the rich schema and presence of an output schema, the description supplies the missing operational context: validation workflow, artifact retention, replacement semantics, concurrency rejection, and alternative tooling. Nothing essential for selecting or invoking the tool is left out.

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 100% description coverage and thoroughly documents parm_id, value, edits, geometry_file, output_dir, and timeout_seconds. The tool description mostly restates the query provenance and native-units expectation rather than adding new parameter-level meaning, so the schema-carries-the-load baseline of 3 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 first sentence names a specific verb and resource: applying typed parameter ID/value edits obtained from openvsp.query in one OpenVSP load/update. It also differentiates from siblings by stating 'No VSPAERO solve' and pointing to openvsp.modify, so an agent can distinguish it from 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 explicitly routes to openvsp.modify when trusted AngelScript commands are needed and explicitly excludes VSPAERO solving. It also establishes the intended data flow by requiring IDs obtained from openvsp.query, making the precondition and alternative 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?

Annotations already signal destructive and open-world behavior, so the lower bar is met. The description adds valuable context: source is snapshotted once, artifacts plus sweep.json are retained, the source is not replaced, failures retain partial results, and timeout_seconds bounds the whole sweep. It does not surface that set_commands are server-privileged and may perform arbitrary I/O, leaving part of the destructiveHint unexplained.

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?

Three sentences deliver the core sequential behavior, artifact/source-safety guarantees, timeout semantics, and the batch_submit alternative with no filler. The most important distinguishing trait, sequential per-condition solving, 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?

Given rich nested schema descriptions, annotations, and an output schema, the description covers the essential operational facts: execution mode, artifact retention, source preservation, partial results, budget semantics, and when to use batch_submit instead. No critical information needed to call the tool correctly 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 description coverage is 100%, so the schema already documents the request object, conditions, timeout, output behavior, and per-field VSPAeroSettings semantics. The description restates the whole-sweep timeout and per-condition independence but adds no parameter-level detail beyond what the schema provides; baseline 3 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 opens with a specific action and resource: 'Solve 1-25 explicit steady conditions sequentially using one source snapshot and shared optional commands.' It also names the sibling alternative openvsp.batch_submit, making the tool's scope and boundary clear without needing to inspect 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 description explicitly routes to an alternative: 'Use openvsp.batch_submit for durable independent cases, per-case parameter edits and bounded parallel execution.' This gives a clear when-to-use vs. when-not-to-use rule and names the specific sibling to prefer instead.

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