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

Annotations already mark idempotentHint=true and destructiveHint=false, and the description aligns with them, adding that completed cases and logs remain. It also discloses the cooperative/asynchronous nature by instructing the agent to poll status until acknowledgement. No contradiction with 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 short sentences each add distinct value: the action, the preserved artifacts, and the follow-up. It is front-loaded with the main verb and target, and has no fluff.

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 mutation tool with annotations, the description covers the action, side effects, and the need to poll status. It does not specify the response shape or error cases, but the absence of an output schema is partially mitigated by the status-polling instruction.

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?

With 0% schema description coverage, the schema only lists job_id as required. The description clarifies that the parameter identifies the job whose worker and AVL process are cancelled ('this job's worker'), but it does not elaborate on format, validation, or accepted values. It partially compensates for the schema gap.

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 clear action ('Request cooperative cancellation') and the target ('this job's worker and its owned AVL process'). It is distinct from read-only siblings like avl.health or avl.status, but it does not explicitly contrast with avl.resume or avl.sweep, so sibling differentiation is missing.

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 the tool is for cancelling a job but never states when to choose it over avl.resume or avl.sweep, nor when cancellation is appropriate. It does provide a follow-up instruction ('Query status until cancellation is acknowledged'), which is a mild usage hint, but the when-vs-alternatives guidance is absent.

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 burden. It discloses that the tool diagnoses and 'saves evidence,' implying a stateful side effect, and explicitly states what remains separate. However, it doesn't clarify whether saving evidence is destructive, where it is saved, or whether the tool modifies anything.

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 main diagnostic areas. The second sentence adds useful boundary information. It could be slightly more structured, but 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 diagnostic tool, the description covers the main scope and notes exclusions. However, it doesn't describe what 'saving evidence' means, what the output looks like, or how this relates to the sibling tools (e.g., avl.inspect, avl.validate). Given the tool's complexity is low, this is adequate but not 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?

The tool has zero parameters, so the schema provides no parameter semantics. The description compensates by explaining what the tool operates on (dependencies, architecture, permissions, startup), giving the agent enough context to understand the tool's scope without needing parameters.

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 ('Diagnose') and a clear resource scope: Python/native dependencies, architecture, directory permissions, and AVL startup. It distinguishes itself from siblings by listing concrete diagnostic areas, though it doesn't explicitly name a sibling to contrast with.

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 this is the diagnostic/health-check tool among siblings like avl.inspect, avl.validate, and avl.run, but it doesn't explicitly state when to use it versus those alternatives. The phrase 'Numerical validation and desktop registry refresh remain separate' hints at exclusions but doesn't name the alternative 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 readOnlyHint, idempotentHint, and destructiveHint, so the bar is lower. The description adds plain-language confirmation that 'original files are unchanged' and specifies what data is accessed, which reinforces the safety profile beyond the boolean hints.

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 entire description is one tight sentence that front-loads the verb and resource scope, then adds the key non-destructive guarantee. Every word earns its place and there is no filler.

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

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

For a single-parameter read-only tool with strong safety annotations, the description is largely adequate: it states what is read, confirms no modification, and implies the purpose. The main gap is that it does not describe what the tool returns or expand on model_path semantics, but complexity is low and annotations cover the safety 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 carries the burden for explaining model_path. It does not do so directly; the only hint is the property title 'Model Path'. The description never clarifies what kind of path is expected, whether local, remote, or file-format-specific.

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 verb, 'Read', and names the exact resources it operates on: 'geometry, references, controls and dependencies'. This clearly distinguishes avl.inspect from execution-oriented siblings like avl.run and avl.sweep.

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

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

The description clearly establishes that this tool is for read-only inspection because it says it reads data and that 'original files are unchanged'. This gives an agent context for when to choose it over mutation or execution tools, though it does not explicitly name alternatives 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 annotations only covering the safety profile (readOnly=false, destructive=false, idempotent=false), the description adds substantial behavior: work happens on staged copies rather than the source model, every mesh is preflighted against the vortex budget, one total timeout bounds the whole run, and artifacts (JSON, CSV, Markdown) are written. It also bounds the interpretation of results — tolerances apply only to the final adjacent pair, and no Richardson extrapolation or geometry suitability proof is produced.

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?

Front-loaded with the core operation in sentence one and zero filler; the trailing caveat sentence is dense but earns its place by preventing a false convergence claim. Slight cost in readability from cramming four distinct facts into the final sentence.

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, file-writing study tool with six parameters, no output schema, and no annotation coverage, the description does well on outputs and runtime semantics (artifact formats, single total timeout, tolerance scope). Gaps remain around required inputs (model_path), where artifacts land, behavior on preflight failure, and the what-happens-next story if a mesh exceeds the vortex budget.

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 carry the load, and it does for the highest-risk parameters: 'factors' gains an implicit starting-at-1/increasing constraint (tighter than the schema's minItems 2/maxItems 8) and 'absolute_tolerances' is characterized as assessing only the final adjacent difference. It says nothing about model_path, references/References, length_unit, case_name, or the metrics selection, leaving a meaningful share of the six parameters unexplained.

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 (compare a fixed flight condition across 2-8 increasing mesh factors) and states the scope constraint (starting at 1). The following sentences sharpen the mechanism — chord/span refinement on staged copies with fixed body discretization — so the agent knows exactly what operation this is, well beyond the bare tool name.

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

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

Usage context is implied by the study framing (mesh sensitivity/convergence work) and by the explicit disclaimer that no convergence claim is made, but there is no statement of when to prefer this over siblings like avl.sweep or avl.run, nor prerequisites such as the vortex budget configuration being mandatory.

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 substantial behavioral context beyond the read-only/idempotent annotations: it does not run AVL, returns a TrimRequest and References with provenance, assumes unbanked steady level flight with lift=weight, zero beta/rates and target Cm=0, and explicitly excludes inferred atmosphere, thrust balance and inertia modeling.

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 action and purpose, followed by requirements, return values, assumptions and exclusions. Each sentence carries useful information without redundancy.

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

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

For a complex nested request with no output schema, the description adequately states what is returned (TrimRequest, References, provenance) and the key physical assumptions. Some details, such as the role of model_path and optional references, are left to the schema, but the core completeness is strong.

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 description adds useful meaning for key inputs: SI mass/weight, density and speed, geometry length units, CG units, and Mach as a separate explicit input. However, it does not explain several nested request fields such as alpha_bounds_deg, control_bounds, control, fixed_controls, or tolerances, and the reported schema description coverage is low at the top level.

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: convert explicit SI mass/weight, density and speed to target CL. It distinguishes this preparation step from the actual AVL execution by saying 'without running AVL' and notes the outputs are usable in trim/sweep/submit.

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 clearly establishes the usage context: prepare trim inputs without running AVL, with the result usable by downstream trim/sweep/submit tools. It does not explicitly name alternatives such as avl.trim_physical or state when not to use this tool, but the intended workflow is clear.

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

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

Even though annotations already declare readOnly, idempotent, and non-destructive behavior, the description adds valuable runtime semantics: limit range, zero-based index filtering, dotted-field syntax, FIELD_NOT_AVAILABLE for missing tables, and artifact path availability by default. There is no contradiction with 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?

Two dense sentences front-load the core purpose, then add concrete examples and edge-case behavior. There is no wasted wording, and the filter examples are useful rather than decorative.

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 no output schema and five parameters, the description covers a lot: saved-result access, pagination limits, filter syntax, missing-table behavior, and artifact availability. It is slightly incomplete on offset semantics and explicit job_id guidance, but it is still strong enough for an agent to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description carries the parameter documentation burden. It explains limit (1-100), fields (dotted paths with examples), and indices (zero-based). job_id is only implied as the result selector and offset is implied by 'Page', but not explicitly documented.

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 ('Page') and resource ('saved background or run/sweep results'), then explicitly contrasts with 'without running AVL'. This makes the tool's purpose unmistakable and differentiates it from siblings like avl.run and avl.sweep.

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 clearly states the context: use this tool to page saved results rather than running AVL. It stops short of naming explicit alternatives like avl.status or avl.inspect, so it provides clear context but not full when/when-not routing.

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 behavior beyond the annotations: it says the operation occurs only after hash verification and that recomputation is limited to failed, missing, or damaged cases. It does not contradict the annotations. Minor ambiguity remains about whether the tool performs the verification or the caller must do it beforehand.

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: the core action appears first, followed by conditions and constraints. Every sentence contributes information, and there is no filler 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?

For a single-parameter tool with no output schema, the description covers the core context: when resume applies, what gets recomputed, and what is disallowed. It does not describe return values or error behavior, but those are secondary given the simple interface and absence of an output schema.

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?

With schema description coverage at 0% and only one parameter, job_id, the description needed to compensate by explaining how to identify the job or where the id comes from. It only refers to 'an inactive job' without addressing id format, provenance, or required relationship to prior submissions, so the parameter remains underspecified.

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: 'Resume an inactive job'. It further narrows scope by stating 'Active jobs cannot be resumed' and specifies the action 'Recompute only failed, missing or damaged cases', making it readily distinguishable from siblings like run, submit, status, and cancel.

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 states when to use the tool: for inactive jobs, and only after verifying hashes. It also gives an explicit exclusion: active jobs cannot be resumed. However, it does not name alternative sibling tools or explain what to use for active jobs, so it stops short of full 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 all annotations false, the description carries full behavioral burden. It discloses units (angles in degrees, rates in nondimensional body axes), defaults (controls/rates zero), override semantics (changes only the staged copy), and file interactions (ignores nearby .run/.mass). The only notable gap is whether execution is synchronous or queued, but the provided context is still 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 four dense sentences with no filler. It front-loads the core purpose and outputs, then adds critical conventions, defaults, override semantics, and file-ignoring behavior. 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 7-parameter tool with no output schema and no annotation support, the description covers outputs, units, defaults, override side effects, and file handling. It does not explicitly state what model_path should point to or whether the run is asynchronous, but these are largely inferable from the sibling tool set and the schema requirements.

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. It adds meaning for condition parameters: angle/rate units, nondimensional body axes, control gains from geometry, and zero defaults. It also clarifies reference override scope. Parameters like outputs, case_name, length_unit, and timeout_seconds are left to schema/enum, but they are less ambiguous.

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 'Run one prescribed flight condition', a specific verb and resource, and enumerates concrete outputs (forces, ST/SB derivatives, surface loads, strip CSV/JSON links). This clearly differentiates it from sibling tools like avl.sweep (multiple conditions) and avl.submit (submission rather than direct run).

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 does not explicitly name alternatives or state when to use this tool vs avl.sweep or avl.submit, but 'one prescribed flight condition' implies a single-point analysis rather than a sweep. This is an implied usage signal rather than explicit guidance, so it earns a middle score.

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, idempotentHint, and destructiveHint=false. The description adds valuable context beyond those annotations by explaining that success=true merely means the status was read, and that state/error should be inspected for the actual solver outcome. It also lists the possible lifecycle states.

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 concise sentences with no filler. The core action is stated first, and the important caveat about success semantics is 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?

For a simple single-parameter status tool with strong annotations and no output schema, the description provides the state enumeration and clarifies how to interpret success/error. It is slightly incomplete in not mentioning the origin or format of job_id, but overall it gives enough context for correct invocation.

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

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

Schema description coverage is 0%, and the description does not elaborate on job_id, such as where it comes from or what format it expects. The parameter name 'Job Id' is self-explanatory to some degree, but the description fails to compensate for the missing schema documentation.

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 uses a clear verb ('Read') with a specific resource (job state and case counts) and enumerates the relevant state values. It does not explicitly differentiate from siblings like avl.results or avl.health, but the focus on status and solver outcome is sufficiently distinct.

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

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

No guidance is provided on when to use this tool versus alternatives such as avl.results or avl.health. The description implies it is for status polling, but it does not state exclusions or direct the agent toward sibling tools when 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?

The annotations already establish a non-read-only, non-destructive, non-idempotent job submission. The description adds valuable context beyond that: jobs are detached, workers survive MCP client disconnection, concurrency is limited to two workers per work root, and timeout excludes queue time. It is rich but does not cover failure behavior or auth needs.

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 action and return value, then adds operational constraints. It is dense but every sentence contributes useful information; no obvious 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 9-parameter job submission with no output schema, the description covers the key behavioral and lifecycle details, including return of job_id. It is not fully complete because several parameters, especially references, are left unexplained, but the core call semantics 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 must carry parameter meaning. It explains the conditions/trim_requests exclusivity, outputs behavior, and timeout semantics, but it omits model_path, references, length_unit, stop_on_error, and case_name; references in particular is complex and undocumented.

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 and resource: 'Snapshot inputs and start a detached local AVL job; return job_id immediately.' This distinguishes it from a synchronous analysis tool, but it does not explicitly differentiate from siblings such as avl.run, avl.trim, or avl.sweep.

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 a concrete usage constraint: 'Supply exactly one of conditions or trim_requests,' and mentions cancel/resume behavior. However, it does not say when to choose avl.submit over avl.run, avl.trim, or avl.sweep, so the routing guidance is only implied.

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 substantial behavioral detail beyond annotations: a shared total timeout budget, sequential trim replays in fresh processes, output selection semantics, preservation of successful and failed cases, summary.csv writing, and partial-result/isError behavior. These details materially help an agent understand execution and failure semantics.

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 front-loaded and structured around execution rules, outputs, and failure behavior. Every sentence contributes useful information for a complex tool.

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 9-parameter tool with no output schema, it covers the core execution model, result ordering, output selection, and error behavior well. It is not fully complete because several invocation parameters and their effects remain undocumented, but the agent has enough to use the tool correctly in most cases.

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?

Top-level schema description coverage is reported at 0%, so the description carries much of the parameter burden. It explains the conditions vs trim_requests exclusivity, the 1-10000 case limit, output selection, and shared timeout, but leaves several top-level parameters such as model_path, references, length_unit, stop_on_error, and case_name unexplained.

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

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

The description clearly identifies this as a sweep tool that runs either prescribed flight conditions or trim requests through AVL processes, including sequential trim solves for alpha/CONTROL and CL/Cm. It is specific about the operation but does not broadly differentiate itself from nearby siblings such as avl.trim or avl.run beyond pointing long jobs to avl.submit.

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 to supply exactly one of conditions or trim_requests and that long jobs should use submit. That gives clear routing context, though it does not fully explain when to choose this over other trim-related siblings.

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

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

Goes well beyond annotations by disclosing that CONTROL values are section gains, that bounds accept/reject rather than constrain iterations, success requires residual/bounds checks and a fresh fixed-condition solve, and moments use the explicit reference point. No contradiction with 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?

Dense and front-loaded: purpose first, then caveats. Every sentence carries operational or domain meaning; no filler.

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

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

For a complex trim solver with no output schema and 0% parameter-description coverage, the description covers purpose, scope, and success checks but omits return values and several parameter semantics, leaving gaps an agent would need to fill elsewhere.

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 property description coverage is 0%, so the description must compensate. It clarifies the core scientific parameters (control semantics, bounds behavior, reference point) but leaves model_path, case_name, outputs, fixed_controls, tolerances, length_unit, and timeout_seconds unexplained.

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

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

States a specific verb (Solve) and the exact unknowns/targets: alpha and one existing CONTROL for CL/Cm at zero beta/body rates. It is clear but does not explicitly differentiate itself from siblings such as avl.sweep or avl.run.

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?

Gives clear applicability constraints (zero beta/body rates, no mass/thrust balance) but does not name an alternative tool or explicitly say when to choose avl.trim over avl.sweep/avl.run.

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 declare non-readonly, non-destructive, non-idempotent; the description adds substance beyond that: bounded alpha/control solve with residual checks and an independent replay, and reporting of numerical failures rather than silent failure. Provenance/dimensional-input persistence on the native results is disclosed too. It stops short of saying what a converged-vs-failed response looks like.

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?

Five short sentences, goal front-loaded, no filler. The telegraphic style ('Mach remains explicit') is dense but each clause carries information; a slightly more explicit subject in the middle sentences would help.

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 no output schema, the description still says results are saved with dimensional inputs and conversion provenance and that numerical failures are surfaced, which is the key return-value behavior for a solver. Combined with the annotations covering the safety profile, an agent has enough to call this 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?

Reported schema description coverage is 0%, so the description carries the burden and does cover the important physical inputs (SI mass/weight, density, speed, declared geometry and CG length units, explicit Mach). But it says nothing about model_path, references, outputs, case_name or timeout_seconds, so several parameters remain undocumented by either channel.

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

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

States a specific verb and resource: 'Prepare lift=weight and zero pitching moment about explicit CG, then verify trim', plus that it solves alpha and one control. The physical-loading framing (mass/weight, density, speed) separates it from the plain avl.trim family, though it never names the sibling it supersedes, leaving the agent to infer which trim variant to pick.

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

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

'No thrust balance, mass file or eigenmodes' and 'Mach remains explicit' give real cues about what this tool is not for, which helps routing. There is still no explicit 'use avl.trim instead when X' statement, so alternatives must be inferred from the other tools' 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the key behavioral constraint 'No solver execution,' which confirms the tool is a safe, non-executing check and goes beyond the annotations. It does not contradict the annotations, so no conflict is present.

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 12-word sentence plus a short clarifying clause. It is front-loaded with the essential action and resource, and every word earns its place. There is no filler or repetition of structured fields.

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 validation tool, the description covers purpose and safety well, but it does not disclose return value semantics, such as whether validation failures return errors, a report, or exit codes. Since there is no output schema, this absence leaves an agent uncertain about how to interpret the tool's result.

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 one required string 'model_path' with 0% description coverage. The description does not explicitly explain this parameter, though 'text grammar' hints that model_path points to a text-format model file. The parameter name is self-explanatory, but the description still leaves format, path conventions, and required file type to inference.

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 and subject: 'Validate supported text grammar, dependencies and mesh limits.' This makes the tool's purpose explicit. It also adds 'No solver execution,' which helps distinguish it from solver-running siblings, though it does not name those alternatives or clarify what 'text grammar' means in context.

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

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

Usage is implied rather than explicit. Saying 'No solver execution' suggests this tool is a pre-flight check before running the solver, but it does not provide specific when-to-use guidance or name alternatives like avl.run or avl.inspect. An agent must infer the appropriate context from the sibling list and the word 'Validate.'

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