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

No annotations are provided, so the description must carry the full burden. It discloses the primary behavior (parsing and reporting) and lists specific outputs, which is informative. However, it does not mention possible side effects (e.g., whether it modifies files), error handling for missing/invalid logs, or limitations such as large file sizes. It is adequate but not exhaustive.

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 concise sentence that front-loads the main action (parse) and lists the specific reports. No filler or repetition. It efficiently communicates the tool's purpose in a compact form.

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

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

With one parameter, no output schema, and no annotations, the description gives the essential information an agent needs to call the tool: pass a log file and receive an analysis. It does not describe the return format (e.g., JSON structure), but that might be inferred. It lacks info on edge cases (e.g., invalid file) but is mostly complete for a straightforward read/analysis tool.

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

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

Schema description coverage is 0%, so the description must compensate for the single parameter 'log_path'. It implies the parameter is a path to an OpenFOAM solver log file, but does not specify any format constraints (e.g., file extension, absolute vs relative path) or additional context like typical log file naming. It adds some meaning beyond the bare parameter name, but not deeply.

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

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

The description states a specific verb ('Parse') and resource ('OpenFOAM solver log file'), and enumerates the exact outputs (residual drop, Courant number, bounded fields, convergence verdict). It clearly distinguishes from siblings like run_openfoam_command or check_case, since no other tool claims to analyze residuals.

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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., that a solver log must exist) or when not to use it. The phrase 'parse an OpenFOAM solver log file' implies usage when a log file is available, but this is not stated as a recommendation or compared to sibling tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it delivers: it discloses the input format (ASCII or binary), the full set of computations performed, the watertight/closed-manifold check, and the advisory output (cell size + snappyHexMesh advice). The only untold behaviors are error handling for malformed files and performance on large STLs, which are minor for a local analysis tool.

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

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

Two sentences with zero filler. The output list is densely packed, and the placement is smart — the advisory output and the workflow guidance ('Use before snappyHexMesh') are deferred to the second sentence. 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 single-parameter tool with no output schema and no annotations, the description gives a nearly complete picture of what the agent gets back and what it needs as input. The only gap is the return format (how results are structured), which matters slightly given the absence of an output schema, but it's a modest omission at this complexity level.

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

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

Schema coverage is 0% — the schema labels the sole parameter only as 'Path' with no description, so the description must compensate. It partially does: 'Analyze an STL surface (ASCII or binary)' implies path points to an STL file. However, it never explicitly states that the 'path' parameter is the file path to the STL that gets analyzed; the connection is inferred rather than stated.

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 ('Analyze') and resource ('STL surface') and enumerates concrete outputs: triangle count, bounding box, surface area, enclosed volume, watertight check, unpaired edges, and mesh advice. It clearly distinguishes itself from the sibling set, which are all OpenFOAM solver/mesh tools (analyze_residuals, generate_blockmesh, mesh_quality_report, etc.) — this is the only STL-analysis tool among them.

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?

'Use before snappyHexMesh' gives explicit placement in the workflow, and 'No OpenFOAM needed' sets an important precondition. There are no truly overlapping siblings performing STL analysis, so explicit alternative-routing isn't necessary, but the description could be stronger about when NOT to use it (e.g., for non-STL or use with mesh_quality_report vs. pre-mesh checks).

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

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

With no annotations at all, the description carries the full behavioral burden and largely meets it: it discloses the return shape (errors, warnings, pass flag) and explicitly notes it does not require OpenFOAM installed, signaling this is a non-mutating logical check rather than a code-executing operation. It does not explicitly state 'does not modify the case,' but 'logically validate' and the no-OpenFOAM note make the harmless read-only nature clear.

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, zero waste, and correctly front-loaded with the verb and resource. The colon-enumerated validation checks are compact and specific, and the return behavior plus the no-OpenFOAM caveat each earn their place. Nothing extraneous.

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 and no annotations, the description covers the essentials: what it validates, what it returns (errors/warnings/pass flag), and the no-OpenFOAM prerequisite. The only minor gap is not defining the threshold between 'error' and 'warning,' but this is unlikely to block correct invocation for an OpenFOAM-literate agent.

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

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

Schema description coverage is 0%, so the description must compensate, and it only partially does. The single parameter case_dir is self-evident from the schema, and the description confirms it operates on 'a case directory.' For a trivial single string parameter this is adequate, but the description adds no specifics about path format, absolute vs relative paths, or required structure beyond the bare directory concept.

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 ('Logically validate') and resource ('a case directory'), then enumerates exactly what is checked: required system files, solver read, turbulence field consistency, and 0/ boundary patches matching the mesh. This clearly distinguishes it from siblings like run_openfoam_command, mesh_quality_report, and scaffold_case — none of which perform whole-case logical validation.

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 purpose strongly implies the use case — validate a case before running a solver — and the return of a pass flag is obvious value. However, the description never explicitly states when to use it versus alternatives (e.g., mesh_quality_report for mesh concerns, read_dict for inspecting settings), nor does it state when not to use it. Guidance is only implied, not stated.

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

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

With no annotations provided, the description carries the full burden. It discloses that the calculation is an estimate based on a correlation and that defaults are for air at sea level, which is useful context. However, it does not mention the output format or units, nor any limitations of the correlation, leaving some behavioral ambiguity.

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: the first states the purpose and method, the second gives usage context and default information. No irrelevant words, and the essential facts are 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?

The tool has 5 parameters, no output schema, and no annotations, so the description should be comprehensive. It lacks details on the specific formula, units, assumptions (e.g., flat plate behavior), and what the output represents. An agent might not know how to choose length or interpret the 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?

Schema description coverage is 0%, so the description must compensate. It provides only a hint about defaults (air at sea level) but does not explain the role of velocity, length, or the fluid properties. The parameter names are somewhat self-explanatory, but an agent cannot determine what length refers to (e.g., characteristic length) or how the inputs relate.

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 estimates the first-cell height to achieve a target y+ on a turbulent boundary layer using a flat-plate correlation. It explicitly says 'Use before meshing to set the near-wall cell size,' which distinguishes it from sibling tools like y_plus_from_height.

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 a clear usage context: before meshing to set near-wall cell size. It does not explicitly name alternative tools or exclusions, but the purpose is specific enough that an agent can infer when to use it. Missing explicit 'when not to use' guidance.

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

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

Without any annotations, the description carries the full burden of behavioral disclosure. It transparently states what the tool returns (Reynolds number, classification, and a turbulence-model recommendation) and implies it is a pure calculation with no side effects. While it does not explicitly mention read-only behavior or error handling, the output-focused description is sufficient for a straightforward computational tool.

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

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

The description is two sentences, with the primary output front-loaded in the first sentence and the geometry clarification in the second. There is no fluff, and every word adds value. It is concise and well-structured for quick scanning.

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 is simple but has no output schema and 0% schema coverage, the description needs to explain all inputs and return values. It covers the output but leaves three of four parameters (velocity, length, kinematic_viscosity) without meaningful description. Units or typical values are absent, and the exact output format is not specified. The description is incomplete for a novice agent, though adequate for an expert.

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

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

Schema coverage is 0%, so the description must compensate for parameter documentation. It only explains the 'geometry' parameter (internal vs. external), leaving 'velocity', 'length', and 'kinematic_viscosity' unexplained. Although the parameter names are self-explanatory to an informed user, the description adds no detail about units, characteristic length, or typical values, which is a significant gap given the absence of 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?

The description clearly states the tool's output: Reynolds number, laminar/transitional/turbulent classification, and a turbulence-model recommendation. It also distinguishes geometry types (internal/external), which is specific and useful. None of the sibling tools appear to compute a flow-regime classification, so it is well differentiated.

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

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

There is no mention of when to use this tool versus alternatives, no prerequisites, and no explicit 'use when' or 'do not use' guidance. The only contextual hint is the geometry parameter, which relates to parameter semantics rather than usage guidance. The agent is left to infer when this is the appropriate 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?

Annotations are absent, so the description carries the full behavioral burden. It discloses the core behavior: generating a valid blockMeshDict, auto-computing grading based on first_cell_height, and writing to output_path. However, it does not mention side effects (e.g., overwriting existing files), error conditions (e.g., invalid preset), or prerequisites (e.g., whether the case directory must exist). These gaps would matter for an agent making a call.

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 efficiently structured: the first sentence defines the primary function and output; the second explains the grading behavior with a link to another tool; the third reinforces value. No wasted words, and critical info is front-loaded.

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

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

For a tool with 9 parameters, no annotations, and no output schema, the description is incomplete. It fails to explain most parameters, does not describe the return value or any output besides the written file, and omits error handling or validation behavior. The absence of sibling differentiation and explicit usage exclusions further reduces completeness.

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

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

With 0% schema description coverage, the description must explain the parameters. It only clarifies output_path, preset, and first_cell_height. The geometric parameters (length, height, depth, cells_x, cells_y, cells_z) are not described at all; an agent cannot infer their meaning or how they interact with the preset. This is a significant underserved area.

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 ('Auto-generate a valid, boundary-layer-graded blockMeshDict and write it to output_path'), names the resource (blockMeshDict), and clarifies the output location. It mentions the preset options and the grading feature, clearly distinguishing it from sibling tools like scaffold_case or list_mesh_presets.

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

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

The description provides clear context on when to use the tool (to generate a boundary-layer-graded mesh) and how to use it in conjunction with the first_cell_height tool to achieve a target y+. It does not explicitly name alternative tools or state when not to use this tool, but the use case is well 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?

No annotations are provided, so the description carries the full burden. It discloses the correlation and that defaults are for water, but omits important behavioral details: the heating boolean parameter's effect (n exponent changes), validity ranges (e.g., Re > 10000), assumptions like fully developed flow, and what happens for non-water fluids. It is not misleading, but leaves gaps.

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

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

The description is compact, two sentences, and front-loads the key formula and return type. It avoids fluff, though the omission of parameter explanations suggests a trade-off between brevity and completeness.

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 7 parameters, no output schema, and no annotations, the description is under-specified. It does not explain how to set parameters correctly (e.g., units, heating flag), nor does it state the correlation's applicability (turbulent vs laminar thresholds). An agent might misapply it or set the heating boolean incorrectly.

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 mentions 'Defaults are for water' which hints at density, Prandtl, conductivity, and kinematic viscosity defaults, but does not explain the meaning of each parameter, units, or the role of the 'heating' boolean. It does not add enough beyond the raw schema to guide correct parameter selection.

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 it computes convective heat-transfer coefficient for internal flow, specifies the exact correlation (Dittus-Boelter) and its laminar counterpart, and lists the return values (Nusselt number and h in W/m^2K). It uses specific verbs and resource, and is clearly distinct from sibling tools like pipe_pressure_drop or flow_regime.

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 context (internal flow, water defaults) but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or when not to use it. Siblings like pipe_pressure_drop are obviously different, but no routing guidance is given.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the quantities produced (k, epsilon, omega, nut) and the purpose context. However, it leaves ambiguous whether the tool writes to the case files or merely returns values, and it doesn't disclose the return/output format or any side effects. Partial disclosure, adequate but with gaps.

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

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

Two efficient sentences with no filler. The primary compute function and its inputs are front-loaded, and the usage context follows immediately. 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?

Given 4 parameters, no output schema, no annotations, and 0% schema coverage, the description is reasonably complete on purpose and use-case but falls short on parameter rigor: it omits units for velocity and kinematic_viscosity and does not disclose the return format or the optional nature of kinematic_viscosity (which has a default in the schema). Adequate for a niche physics tool but with clear documentation 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 0%, so the description must compensate for undocumented parameters. It adds real meaning to two of four parameters: turbulence_intensity is a fraction (e.g., 0.05) and length_scale is in meters. However, it does not specify units for velocity or kinematic_viscosity, nor explain kinematic_viscosity's role in the computation. Only partial compensation for the schema's lack of descriptions.

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

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

The description uses a specific verb (compute) tied to specific resources (inlet k, epsilon, omega, nut) and states the exact derivation inputs (turbulence intensity as a fraction, turbulent length scale in meters). It clearly differentiates from all sibling tools, none of which compute turbulence inlet values, so an agent can select it unambiguously.

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 second sentence gives concrete context for when to use the tool: 'Use to fill the 0/ directory inlet/internalField values for a RANS case.' This anchors the tool to the RANS setup workflow. It doesn't name explicit alternatives to exclude, but no sibling offers the same function, so the absence of exclusions is acceptable.

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

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

No annotations are provided, so the description carries the full burden. The verb 'list' clearly implies a read-only operation with no side effects, but the description does not explicitly state that it only returns information or that it has no impact on the case. Still, for a trivial listing tool, this is adequate.

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

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

A single, compact sentence that lists the presets with no filler. It is front-loaded with the purpose and provides all relevant information efficiently.

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 parameters, no output schema, and no annotations, the description fully specifies what the tool returns (the preset names). Nothing else 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 parameters and the schema is empty (coverage 100%). The description adds value by naming the exact preset values, which is helpful even though no parameter arguments are needed. Baseline for 0 params is 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 states the specific action (list) and resource (auto-blockMesh geometry presets), and enumerates the actual presets (channel, flatplate, step, box). This is unambiguous and distinguishes it from sibling tools like generate_blockmesh, which actually create meshes.

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 used to discover available presets before calling generate_blockmesh, but it never explicitly states when to use it or mentions alternatives. Given that it is the only listing tool for presets, the usage context is clear but not explicitly spelled out.

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

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

With no annotations provided, the description carries the burden. It explicitly states the output includes 'a one-line description of each and when to use it,' which fully describes the tool's behavior. As a read-only listing operation, no side effects need disclosure. The description is transparent within the tool's simplicity.

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, well-crafted sentence. It front-loads the core action ('List the OpenFOAM solver templates') and immediately adds the scope and output detail. No wasted words; every element serves a purpose.

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

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

For a zero-parameter, read-only listing tool, the description covers all necessary aspects: what is listed, the scope, and what each entry includes. There is no output schema, but the description itself specifies the return content (name, one-line description, when to use). 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 parameters, and the input schema is empty with 100% coverage. No parameter explanation is needed. The description correctly omits parameter details, and the baseline of 4 applies because there are no parameters to document.

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

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

The description clearly states the verb 'List', the resource 'OpenFOAM solver templates', and the specific scope 'this server can scaffold'. It distinguishes itself from siblings like list_mesh_presets by focusing on solvers rather than mesh presets.

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

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

The description implies when to use the tool: when an agent needs to know available solver templates and their use cases. It doesn't explicitly mention alternatives or conditions to avoid using it, but the purpose is clear enough in a set of qualitatively different siblings. No exclusions are stated, which fits a listing 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?

No annotations are provided, so the description carries the burden. It describes the parsing action and the output (verdict with metrics and advice), but it doesn't explicitly state that the tool is read-only or how it handles malformed logs. Given it's a simple parser, this is adequate but not fully detailed.

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

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

A single, information-dense sentence that front-loads the action and includes the key outputs. No wasted words, and the critical detail about working without OpenFOAM is included.

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 aspects: input (log path), processing (parse), and output (verdict with metrics and advice). It lacks specifics on return format or error handling, but for a one-parameter tool with no annotations, this is largely 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?

With 0% schema description coverage, the description must clarify the parameter. It defines log_path as 'a checkMesh log file' which aligns with the parameter name, but adds no extra detail about format constraints or path handling. The meaning is self-evident from the context, so a baseline score 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 explicitly states it parses a checkMesh log file into a quality verdict with specific metrics (non-orthogonality, skewness, aspect ratio, pass/fail) and advice. This clearly distinguishes it from sibling tools like analyze_residuals and list_solvers, which address different concerns.

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

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

The description provides clear context: use this tool when you have a saved checkMesh log and want a quality report without running OpenFOAM. It doesn't explicitly list exclusions or name alternatives, but the targeted nature of the tool makes its usage obvious.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully reveals the underlying equations (Colebrook-White for turbulent, 64/Re for laminar) and that defaults are for water. However, it does not disclose the output format, whether both friction factor and pressure drop are returned, or any limits or side effects, which are gaps for a computational tool.

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

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

The description is concise—two sentences—with the core computation front-loaded in the first sentence. It avoids fluff and imparts essential context (equations, defaults) efficiently, though it could be more structured with explicit output 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?

For a tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It lacks information about return values, units for all inputs, and any preprocessing or error conditions. The agent would need to infer expected behavior, making this insufficiently complete for confident invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explicitly mentions the roughness parameter (in meters) and indicates density and kinematic viscosity default to water values, which adds meaning beyond the schema. However, it doesn't explain velocity, diameter, or length, or the optional parameters in any depth, leaving the agent partially uninformed.

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 computes Darcy friction factor and Darcy-Weisbach pressure drop/head loss for pipe flow, which specifies a precise verb and resource. It distinguishes itself from siblings like heat_transfer_pipe by explicitly naming the equations, but it doesn't explicitly contrast with other tools, so it's not a full 5.

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

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

The description gives a passing hint about setting roughness for rough pipes and defaults for water, but provides no explicit guidance on when to use this tool versus alternatives (e.g., flow_regime, heat_transfer_pipe). No exclusions or conditions are stated, leaving the agent to infer usage.

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?

Since no annotations are provided, the description carries the full burden. It discloses a key conditional behavior (if `entry` is supplied and OpenFOAM is installed, return only that value; otherwise full contents), which is valuable. However, it does not describe the output format, error handling, or what 'full contents' means in practice, leaving gaps for the 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 a single, well-structured sentence that front-loads the main purpose and immediately covers the conditional behavior. Every word contributes; there is no fluff or 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 simple two-parameter read tool with no output schema, the description covers the essential behavior and the conditional logic. It could mention output format or error cases, but the core decision path is explained. It is reasonably complete for the tool's complexity.

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

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

The schema has 0% description coverage, so the description must compensate. It clarifies the `entry` parameter with foamDictionary syntax examples, which adds meaning. The `path` parameter is only implicitly understood from the tool's purpose, not explicitly described. The description partially compensates but not fully.

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 reads an OpenFOAM dictionary file, specifying the verb and resource. It distinguishes its behavior based on the `entry` parameter, which makes it distinct from sibling tools like `set_dict_entry` that write. The purpose is specific and not a tautology.

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

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

The description implies usage for reading dictionary files but does not explicitly contrast it with alternatives like `set_dict_entry` or `check_case`. The conditional behavior when `entry` is provided is explained, but there is no direct 'use this when' guidance. It is adequate but leaves the selection decision to the agent.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It clearly states the tool returns a plan and, when inputs are missing, returns questions—so it discloses its core non-mutating nature and conditional behavior. It does not, however, describe edge cases (unrecognized goals), the exact output format beyond a list, or how it handles invalid combinations of parameters, leaving moderate gaps.

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

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

The description is a single paragraph that front-loads the main purpose, lists deliverables in a natural flow, then adds the conditional behavior. Every sentence carries value—no filler, and the 'Start here' is a useful directive. It is appropriately sized for the complexity.

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

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

The description is reasonably complete for a planning tool: it tells what it returns, how it handles missing inputs, and positions it as the entry point. However, it lacks details on how other parameters (fluid, transient, heat_transfer) influence the plan, and does not define the expected output schema (e.g., whether it returns a JSON object, text, or a numbered list format). Given no annotations or output schema, these gaps matter.

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 coverage, the description must explain all parameters. It explicitly mentions only 'goal' (plain-language input) and 'velocity/length' (the ones that trigger questions). It gives no insight into 'fluid', 'transient', or 'heat_transfer', leaving the agent to guess their roles. This is a substantial deficiency given the lack of 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?

The description specifies a clear verb ('Turn a plain-language goal into a complete setup plan') and lists concrete outputs (solver, turbulence model, target y+, blockMesh preset, fields, boundary conditions, step list). This distinguishes it from numerical calculators like y_plus_from_height or execution tools like scaffold_case, so an agent can immediately tell its role.

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

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

The phrase 'Start here' signals this is the entry point for a planning workflow. It also explains that if velocity/length are missing it asks follow-up questions, guiding the agent to call it early. However, it does not explicitly name alternative tools (e.g., 'use list_solvers to see options') or state when NOT to use it, so it misses the 'when-not' clarity.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses prerequisites (OpenFOAM installed, environment sourced) and the return format (return code and tail of stdout/stderr). However, it does not disclose potential side effects of utilities like renumberMesh or decomposePar (which may modify files), and it does not mention the timeout parameter's effect. This leaves some behavioral gaps.

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

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

The description is concise, using two sentences to convey the whitelist, the prerequisite, and the output. There is no redundancy, and the key constraints are front-loaded.

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

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

For a simple runner tool with no output schema, the description covers the return format and prerequisites, which is essential. However, it lacks any mention of the timeout parameter and does not specify the command parameter's allowed format beyond the whitelist, which are minor gaps for a tool of this complexity.

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

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

Schema coverage is 0%, so the description must explain the parameters. It does not name them directly, only implies case_dir with 'inside a case directory' and command with 'whitelisted utility,' while omitting timeout entirely. The provided meaning is minimal and insufficient given the lack of schema descriptions.

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

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

The description states the action (run) and the resource (whitelisted OpenFOAM utilities) with a specific list of utilities, making it clear what the tool does and how it differs from other OpenFOAM-related tools. The verb and resource are specific and 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 provides clear context by listing the exact utilities and indicating they must run inside a case directory, which helps an agent decide when to use this tool. However, it does not explicitly mention when not to use it or point to alternatives, so it lacks explicit exclusions.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses that it writes system/, constant/, and 0/ directories, creates a single-block box mesh with specified patches, and sets up consistent turbulence fields. It also explains flavor-specific file differences (transportProperties vs physicalProperties) and version compatibility. However, it does not disclose what happens if case_dir already exists (overwrite vs error), prerequisites (e.g., blockMesh availability), or the return value. These gaps are notable but the core behavior is well described.

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 around 150 words, structured with a leading purpose statement followed by a clear explanation of openfoam_flavor and execution steps. It is information-dense without unnecessary filler. The only minor inefficiency is the repeated mention of 'chosen solver' when the sibling list already includes solver options, but overall it's well-organized and front-loaded with the primary purpose.

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 12 parameters, no output schema, and no annotations, the description is incomplete. It defines the core behavior and flavor options, but leaves many parameters underspecified (e.g., cells, domain, end_time, velocity, kinematic_viscosity). It also doesn't mention what the tool returns or any post-creation checks. While the description can still be used for a basic scaffold, the lack of parameter guidance for most fields makes it insufficient for confident usage without additional lookups.

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

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

Schema coverage is 0%, so the description must explain parameters. It only details openfoam_flavor (with classic and foundation-v12 options). Other parameters like cells_x, cells_y, cells_z, domain_x, domain_y, domain_z, end_time, velocity, kinematic_viscosity are left unexplained beyond being present in the schema. The description mentions 'single-block box mesh' which hints at cells/domain, but there is no explicit mapping of these parameters to their meaning or defaults. This forces the agent to infer from names, which is insufficient for a 12-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 clearly states the tool's function: 'Create a runnable OpenFOAM case skeleton at case_dir' with a specific verb, resource, and output structure (system/, constant/, 0/). It distinguishes itself from siblings like generate_blockmesh (which only creates mesh) and run_openfoam_command by positioning itself as the scaffold creator that creates files and defines the solver and flavor.

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

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

The description provides clear guidance on when to use each openfoam_flavor (classic vs foundation-v12) with version-specific recommendations, and gives execution steps ('Run blockMesh, then <solver> ...'). It does not explicitly name alternative tools like generate_blockmesh for mesh-only needs, but the context of creating a complete case skeleton is evident. Lacks explicit 'use this instead of X' phrasing but provides enough context to select the tool appropriately.

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

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

With no annotations, the description carries the full burden and does disclose its write/mutation nature plus the set-or-insert semantics, which is meaningful. However, it doesn't address side effects such as whether the file is overwritten or modified in place, what happens when the patch doesn't exist, or whether a scaffolded case is required 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?

A single efficient sentence that front-loads the action and embeds a full worked example. There is zero filler and every word earns its place.

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

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

As the sole information source (no annotations, no output schema, no parameter descriptions), it covers the core action and parameter meanings but leaves the return value unspecified and doesn't address edge cases like missing patches or null value handling. Adequate for a simple setter but with noticeable gaps given nothing else exists.

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

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

Schema description coverage is 0%, so the description must compensate—and its example does map concrete values to all four parameters, which is genuinely useful. But it leaves out semantics such as the meaning of value being nullable (many bc types like zeroGradient need no value) and any guidance on valid bc_type choices or vector-versus-scalar value formats.

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 ('Set (or insert)') and a precise resource ('the boundaryField entry for a patch in a 0/ field file'), and reinforces it with a concrete parameter-mapped example (field_file='0/U', patch='inlet', bc_type='fixedValue', value='(10 0 0)'). The 0/ file scoping clearly sets it apart from the generic set_dict_entry sibling.

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

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

The description gives context (targets boundary field files for OpenFOAM patches) but offers no guidance on when to choose this tool over alternatives, notably the sibling set_dict_entry. With 19 siblings including a near-duplicate dictionary setter, the lack of any when/when-not/exclusion guidance is a genuine gap.

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

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

With no annotations, the description carries full behavioral burden. It discloses the key behavioral trait: it uses foamDictionary when available for nested entries, otherwise falls back to editing a top-level single-line entry. This is useful context. However, it does not state whether the operation is create-or-update, what happens if the entry doesn't exist, or the format of the value. The disclosed fallback is a partial behavioral disclosure, but not comprehensive. Score 3.

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 sentences with zero waste. The first sentence states the core purpose; the second explains the two execution modes and gives a concrete example. It is front-loaded with the action and stays focused. This is a model of conciseness.

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 core behavior and the nesting/fallback distinction, which is essential for correct invocation. However, with 3 required parameters and no output schema or annotations, it lacks details on parameter semantics (except entry) and potential return/error behavior. An agent may know the action but not enough about the value format or how to handle a missing dictionary file. It is adequate but not complete; score 3.

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 provides only an example for 'entry' ('solvers/p/tolerance'), clarifying nested path semantics, but gives no meaning for 'path' or 'value'. 'Path' is not described as a file path, and 'value' is not specified in terms of format (e.g., string, number, list). The description adds minimal per-parameter value beyond the entry example, leaving most semantics undocumented. Score 2.

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

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

The description clearly states the action: 'Set a keyword in a dictionary file.' It specifies the resource (dictionary file) and the verb (set). It also adds specificity about mechanism (foamDictionary vs text fallback) and gives an example of nested entry syntax, distinguishing it from read_dict and set_boundary_condition siblings.

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

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

The description implies when to use the tool ('Set a keyword in a dictionary file') but does not explicitly state when to prefer it over siblings like set_boundary_condition or scaffold_case. It mentions the fallback behavior (single-line top-level) but doesn't guide on when to use this vs alternatives. The agent can infer usage from the verb and resource, but there's no explicit exclusionary guidance, so a 3 is appropriate.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It provides the formula, indicating a deterministic computation, but omits essential details such as units, error handling for non-positive velocities or cell sizes, and whether it returns a single scalar. The lack of caveats or assumptions leaves the agent uncertain about edge cases and output format.

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

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

The description is a single, compact sentence that immediately states the purpose and the governing equation. It contains no filler or repetition, and the essential formula is front-loaded, making it efficient for quick comprehension.

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 straightforward calculation with three parameters and no output schema, the description is nearly complete: it gives the formula and implies the return value (the time step). However, it lacks explicit mention of the expected output type or units, and does not provide context on when this calculation is appropriate (e.g., for stability in transient CFD). Given the sibling tools are all CFD-related, some context is implicit, but the boundary could be clearer.

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 maps each schema parameter to a variable in the formula: velocity→U, cell_size→dx, target_courant→Co, thereby clarifying their roles beyond the bare schema names. This adds meaningful semantic value, though it does not specify units, value ranges, or constraints, which would be further helpful.

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 computes a time step from a target Courant number and provides the formula, making the purpose explicit. It is distinct from sibling tools like y_plus_from_height or first_cell_height, which compute different quantities. However, it does not explicitly name the parameters or differentiate itself with a targeted sentence, only implying them via the formula.

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

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

The description gives no guidance on when to use this tool versus alternatives, nor any conditions, prerequisites, or exclusions. The user must infer the usage context from the formula and the sibling tools, which is insufficient for a tool that might be selected among similar CFD calculations.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. The description does disclose the key behavioral output (y+ value and region classification), which is valuable. However, it doesn't disclose the underlying formula/assumptions (e.g., flat-plate boundary layer correlation, whether it uses density and kinematic viscosity as provided), the bounds of validity, or what happens with invalid inputs. For a predictive/tool with no annotations, this is a moderate gap.

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

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

The description is a tight single sentence that front-loads the core operation ('predict the y+ that a given first-cell height will produce') and then appends the classification output. No wasted words. Could arguably add more detail, but the structure is 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 tool has 5 parameters, 0% schema coverage, no output schema, and no annotations, making the description the sole documentation. It covers the core purpose and the classification output but fails to document 2 parameters, the formula/assumptions, and the return format. For a reasonably simple predictive tool, the description is adequate for basic use but incomplete for an agent that needs to know the physical model and parameter roles.

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%, meaning the schema provides no descriptions for any of the 5 parameters. The description mentions only two physical quantities (first-cell height, velocity), and implies length, but does not explain the roles of `density` and `kinematic_viscosity` or which are required vs. optional. With 0% schema coverage, the description must compensate, and it fails to explain 2 of the 5 parameters entirely and doesn't clarify why some have defaults. This is a significant 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?

The description states a specific verb ('predict'), a clear resource (y+ from first-cell height), and the output (y+ value and region classification: viscous sublayer, buffer layer, log-law). It clearly distinguishes itself from its sibling `first_cell_height`, which is the inverse operation. The description is clear but doesn't explicitly name the sibling tool as an alternative.

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

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

The description gives clear context for when to use the tool (when you have a first-cell height and want to know the resulting y+), but provides no explicit guidance on when NOT to use it or which sibling to choose instead. The inverse relationship with `first_cell_height` is implied but not stated. There's no mention of prerequisites or typical CFD workflow context (e.g., 'use this after mesh generation').

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