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

Annotations already mark the tool as read-only (readOnlyHint=true). The description adds value by detailing the outputs (I, deflection, moment, stress, safety factor) and the mathematical model used (Euler-Bernoulli), as well as limitations (no shear, buckling). This provides behavioral context beyond what annotations offer.

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 (three sentences) and front-loaded with core purpose. It packs significant detail but lacks bullet points or clear separation of input/output sections, which marginally reduces readability. Still, it is efficient without 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?

Given the complexity (8 parameters, nested objects, no output schema), the description covers the main inputs, supported cases and sections, units, and outputs. It mentions the return values. However, it does not include an example or explicitly map dims_mm keys for each section type, which would enhance 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 compensates partly by explaining case types, section geometries, units, and the default E value. However, it does not explicitly describe all parameters (e.g., load_n, udl_n_mm) or clarify that dims_mm keys depend on the section type. The explanation is helpful but incomplete.

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 performs Euler-Bernoulli beam bending analysis for first-cut design. It lists supported cases (cantilever_point, etc.) and section types (rect, round, tube), making it distinct from sibling tools like calc_fits or calc_fastener. The explicit mention of what it does not include further differentiates it.

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

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

It provides clear context on when to use this tool for simple beam bending and explicitly excludes shear deflection, buckling, and stress concentration, implying those are not computed. However, it does not explicitly state 'use this for first-cut estimates' or mention alternative tools for advanced cases, which would improve guidance.

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

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

Annotations declare readOnlyHint=true, so no side effects exist. The description adds context about the friction coefficient (K) and torque formula, noting that lubrication changes K dramatically, which is valuable beyond the annotation-only info.

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

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

The description is a single sentence that packs many outputs, making it dense. It lacks front-loading or structure (e.g., bullet points) that would improve readability for an agent.

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

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

No output schema exists, so the description must convey return format. It lists several computed values (pitch, area, clearance holes, etc.), but does not present them as structured keys or explain the exact output object, leaving 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 coverage is 0%, but the description adds meaning to friction_k (default 0.2 dry, lubrication effect) and property_class (proof stress). size_m is implied by the range but not explicitly described, leaving some ambiguity.

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 specific purpose: computing metric coarse-thread fastener numbers for a size range (M1.6–M30). It lists discrete outputs (pitch, tensile stress area, etc.), distinguishing it from sibling calculation tools like calc_fits or calc_beam.

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

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

No explicit guidance on when to use this tool versus alternatives is provided. The domain is implied through the list of outputs, but there is no comparison with siblings or conditions for selection.

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, so the description adds context: it computes from standard formulas, returns specific outputs (deviations in µm, clearance, fit type), and advises verification against ISO 286-2 tables. No contradictions 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?

The description is two sentences, front-loaded with the main purpose and key constraints. Every word serves a purpose with no redundancy.

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

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

Given the tool's engineering complexity, no output schema, and three parameters, the description adequately explains what the tool computes and returns, mentions the standard basis, and includes a verification caution. It covers essential context for an agent to use it correctly.

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

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

Schema has 0% description coverage, so the description must compensate. It explains valid ranges for hole (H5–H11) and shaft letters (d e f g h js k m n p s) but does not detail default values or format. It provides some semantic context beyond the schema but is not comprehensive for all three 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 clearly states the tool computes ISO 286 limits and fits for hole-basis subset, specifying hole grades H5–H11, shaft letters, size range to 500 mm, and outputs deviations, clearance, and fit type. This specific verb-resource combination distinguishes it from sibling tools like calc_beam or calc_fastener.

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 hole-basis fits but does not explicitly state when to use vs. alternatives or provide exclusions. It mentions verifying critical fits against official tables, but no guidance on when not to use this tool or mention of 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?

Annotations already declare readOnlyHint=true. The description adds behavioral context by detailing the envelope verdict, which goes beyond annotations. No contradictions or missing side effects.

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

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

Two sentences efficiently convey purpose and optional usage. No redundancy, front-loaded with main action.

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 no output schema, the description covers input details and behavior well. It lacks return format or error conditions, but is sufficient for a read-only calculation 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?

With 0% schema coverage, the description compensates well by specifying component fields (name, mass_g, x_mm, y_mm, z_mm) and envelope fields. It adds meaning beyond the unannotated schema, but could be more precise about envelope structure.

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 total mass and 3D center of gravity from a component list, with an optional envelope for a CG-within-envelope verdict. It uses specific terms and distinguishes from siblings like calc_fits and calc_fastener.

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

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

The description explains input format and envelope usage, but does not explicitly state when to use this tool vs alternatives. It implies context by focusing on mass properties, but lacks 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?

Behaviors such as separate layers for visible/hidden edges, output format selection by suffix, and refusal of colliding paths are disclosed. The idempotentHint annotation is consistent, and no contradictions exist.

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 paragraph with no redundancy. Each sentence conveys essential 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?

Given the complexity, the description covers input types, output formats, views, layers, and a safety check. It could explicitly state the output is a file or data, but overall it is adequate.

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?

Despite 0% schema description coverage, the description explains the role of path, out_path, view, scale, and include_hidden by implication. For example, it mentions hidden edges are dashed, linking to include_hidden. This adds value beyond the schema titles.

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 the tool projects B-rep models (STEP/BREP/IGES) to 2D SVG/DXF from named views, distinguishing it from sibling tools like model_inspect or model_mesh. It specifies input formats, output formats, and view options.

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 notes this is 'a silhouette for hand-off, NOT a dimensioned drawing,' clarifying when to use. It also mentions the collision refusal behavior, but does not explicitly compare 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?

Beyond annotations that already indicate idempotency and non-destructiveness, the description adds rich behavioral context: it details the subprocess execution, CPU and timeout limits, default export formats, directory constraints ('never a directory containing the script itself'), and the return of a build report. No contradictions 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?

The description is a single dense sentence that packs significant information. It is front-loaded with the primary action. While every part is relevant, the density slightly harms readability. Breaking into multiple sentences would improve structure.

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

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

Given the tool's complexity (executing scripts, exporting, subprocess management), the description covers the core workflow, safety constraints, and return value. It could mention error handling or script failure behavior, but overall it is sufficiently complete for an agent to use 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?

With 0% schema description coverage, the description provides essential meaning for all 5 parameters: it explains script_path is required, params is available inside the script, wall_s defaults to 75, formats default to step+glb, and out_dir defaults to 'derived/' beside the script with discussed constraints. This compensates for the missing schema descriptions, though not with per-parameter detail.

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 executes a parametric CAD script and exports the result. It uses specific verbs ('EXECUTES', 'exports') and identifies the resource (script, result shape). It distinguishes from siblings like model_inspect and model_validate by focusing on generating geometry from scripts.

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

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

The description explains the execution context (subprocess, resource limits) but does not explicitly state when to use this tool versus alternatives like model_inspect or text_to_cad. It implies usage for building models from code, but lacks direct exclusions or recommendations.

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

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

Annotations already declare readOnlyHint=true, and the description adds valuable context: that the tool works on geometry (not feature trees) and that reshaped bodies are reported as removed+added. This extra behavioral detail helps the agent understand limitations beyond the annotation's safety flag.

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

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

The description is three sentences long, front-loaded with the core purpose, and adds only essential clarifications. Every sentence adds value without redundancy or 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?

The description explains the tool's outputs and limitations well, but lacks details on parameter semantics and return format (no output schema). For a tool with two required parameters and no output schema, more completeness would be beneficial, but the description covers the core functionality adequately.

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 two parameters (path_a, path_b) have 0% schema description coverage. The description mentions 'Two B-rep revisions (STEP/BREP/IGES)' but does not explicitly describe the parameters' meaning, format, or constraints (e.g., local vs URL, file extension requirements). More parameter-level guidance is needed to compensate for the missing schema descriptions.

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

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

The description clearly states the tool computes a geometric diff of two B-rep revisions and lists specific outputs (volume, area, bbox deltas, per-body matching). It distinguishes itself from a feature tree diff and implicitly from sibling tools like model_inspect (which inspects a single model) by specifying the diffing functionality.

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 geometric comparison of B-rep files and clarifies it is not for feature tree diffs, but it does not explicitly state when to use this tool over siblings like model_inspect or model_validate. No direct exclusions or alternative tool names are given, leaving some ambiguity.

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

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

Annotations indicate readOnlyHint=true, and the description adds important behavioral details: file types, local processing, and volume reporting conditions (watertight for mesh). No contradictions, and disclosures go beyond annotations.

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

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

Description is a single paragraph with three sentences, each earning its place. It is front-loaded with the main action and efficiently covers supported formats, computed properties, and privacy.

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

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

Given the tool's complexity (multiple formats, optional density, per-solid data) and no output schema, the description thoroughly explains what the tool returns and under what conditions, making it complete for agent decision-making.

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 has 0% description coverage; the description fully compensates by explaining that 'density_g_cm3' is for mass calculation and 'path' is for the model file. It adds semantic value beyond the schema.

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

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

Description clearly states the tool summarizes a CAD model with specific outputs (bounding box, volume, etc.) and lists supported file formats. It contrasts with sibling tools like model_validate and model_build, making its purpose unambiguous.

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

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

The description implies usage for inspection without explicit when-to-use vs siblings, but it provides context such as 'Reads the file on this machine; nothing leaves it,' which guides on privacy. A more explicit comparison would improve 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?

Annotations already indicate idempotent and non-destructive. Description adds constraints: refuses collision with input (safety check) and writes only one output file. It also mentions tolerances are echoed in report. 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 sentences covering all critical aspects: action, inputs, outputs, constraints, and tolerances. No wasted words.

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

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

Covers input formats, output formats, tolerances, and collision constraint. Lacks explicit description of the report output (echoed but not defined) and error handling, but is sufficient for a simple file conversion tool with no 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?

Schema has 0% parameter descriptions. Description compensates by defining linear_tolerance_mm and angular_tolerance_deg with units, implying path/out_path are file paths, and clarifying output format determined by suffix. Could be more explicit about input/output roles.

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 specifies the exact verb (Tessellate), source (B-rep models: STEP/BREP/IGES), and output (mesh files: STL, GLB, GLTF, 3MF by suffix). It clearly distinguishes from siblings like model_inspect or model_validate which have different purposes.

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?

Clearly implies use when converting a B-rep model to a mesh at given tolerances. Does not explicitly state when not to use or compare with alternatives, but the sibling tools are sufficiently different that context is clear.

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

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

Annotations already set readOnlyHint=true, confirming safety. Description adds significant behavioral context: every finding includes evidence and threshold, and it clarifies that missing checks are 'absent, not hidden'. This fully informs the agent about tool behavior.

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

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

Three sentences, each adding value: first states the core purpose, second adds transparency about findings, third clarifies exclusions. Front-loaded with 'DFM-lite lint', no wasted words.

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

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

Despite no output schema, the description covers purpose, parameter usage (clearance_mm), limitations, and behavioral transparency. Sibling tools are sufficiently diverse, so no risk of confusion. Complete for a linting/validation 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?

With 0% schema description coverage, the description partially compensates by clarifying that clearance_mm is used for pairwise interference and clearance checks. However, it does not explain the 'path' parameter, which is self-explanatory but still relies on schema for name/type.

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

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

Description clearly states 'DFM-lite lint for a B-rep model' and enumerates specific checks (kernel validity, non-manifold topology, etc.), distinguishing it from siblings that perform different operations like building, inspecting, or meshing.

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?

Provides clear context for when to use (for B-rep model linting) and explicitly lists what it does NOT check (wall thickness, draft, threads, GD&T), implying when it should not be used. However, it does not name alternative sibling tools for those 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?

Discloses network call (consistent with openWorldHint), file output location, editable source, and the STARTER quality warning. Exceeds annotation alone.

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 concise sentences front-loaded with purpose, covering prerequisites, side effects, and a warning. No redundant phrases.

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?

Good context on output (files in out_dir, KCL source) and network usage, but missing explanation for two parameters and no return value details.

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% and description only outlines prompt and out_dir, ignoring timeout_s and output_format. Insufficient for an agent to understand all 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?

Clearly states the tool generates a STARTER CAD model from a text prompt via a specific API, which differentiates it from inspection/validation sibling tools.

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

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

Explicitly mentions required environment variable (ZOO_API_KEY) and the need to verify dimensions, but does not compare to alternatives like model_build for manual modeling.

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