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

With no annotations, the description carries the full behavioral burden and does so well: asynchronous execution, the degradation dict on missing ElmerSolver, `{job_id, status, cache_hit}`, and the need to poll `job_result` for final outputs. It describes validation against exact oracles and expected ratios, which is unusually transparent for a simulation submit 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 purpose and key behavior are front-loaded, but the description is long and dense, mixing physics explanations, oracle details, and return fields. While much of the detail is relevant for a complex simulation tool, it is not maximally concise or easy to parse at a glance.

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?

It gives strong context on async behavior, dependency failure, return fields, and kind-specific validation, and there is no output schema to rely on. However, with 15 parameters and 0% schema description coverage, the lack of parameter explanations leaves an agent guessing about several inputs, so the overall definition is not complete enough.

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

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

Schema description coverage is 0% and there are 15 parameters, but the description only explains a subset (`kind`, `kl`, `lx_m`, `ly_m`, `span_pct`, `n_steps`, `mode_nx`, `mode_ny`, `case_dir`). Important parameters such as `sif`, `nx`, `ny`, `c_m_s`, `length_m`, and `n_elements` are not described, so the text does not come close to compensating for the schema gap.

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

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

The description names a specific verb and resource (Acoustic FEM via Elmer HelmholtzSolve), marks it asynchronous, and explicitly distinguishes it as the higher-order twin of `acoustic_screen` gated against exact closed forms. An agent can identify the tool's scope and its relationship to the sibling without opening the schema.

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

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

It states the dependency (`Requires ElmerSolver`), the fallback behavior when absent, and explains the two `kind` modes with their physical setups. It also names `acoustic_screen` as the related lower-order alternative, though it does not give explicit when-to-use-this-vs-that guidance beyond 'higher-order twin'.

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 delivers: the solve runs out-of-process in a dedicated .venv-bempp because of a meshio version clash, it is asynchronous/off-channel, it degrades to {ok:false, reason, install} when no bempp venv resolves, and results come back as {job_id, status, cache_hit} to be polled via job_result. These are exactly the operational traits an agent must know before invoking.

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?

Long but densely packed with no filler; the environment/isolation caveat and the mode definitions are front-loaded before the return-format note. The heavy parenthetical nesting and backtick-heavy inline code make it slightly harder to scan, but every sentence carries information.

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

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

No output schema exists, and the description fully compensates by enumerating the return shapes for each mode ({ok, ka, radiated_power_w, farfield_pressure_x_r, surface_pressure_abs_mean, n_elements, wall_s} and the scattering results array). For a 15-parameter async tool this is complete enough to invoke and to interpret results.

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 explains the meaning of most parameters (a_m, u_amp, freq_hz, rho, c, h as fraction of a, ka_list, theta_deg, h_per_wl in elements/wavelength, model handle, scale_to_m mm→m, linear_deflection mesh tolerance, problem). Only r_m and timeout are left unaddressed, so one documented gap remains in an otherwise strong compensation for the coverage deficit.

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

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

States a specific verb and resource ('Exterior-acoustics boundary-element solve on Bempp, asynchronous') and immediately positions it against named siblings: the analytic monopole_sphere / rigid_sphere_scattering oracles. The three problem modes ('radiation', 'scattering', 'mesh_solve') are each defined concretely, so an agent can tell exactly what the tool does and how it differs from acoustic_fem_submit and the analytic oracles.

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

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

Gives clear context for each mode and explains that radiation/mesh_solve are gated against the monopole oracle and scattering against the Mie oracle, which effectively routes the agent between modes. It does not, however, state when to prefer this expensive BEM path over the cheap analytic oracles, nor any exclusions beyond the implicit venv-availability degradation.

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 so well: it discloses the closed-form nature, per-kind fidelity bands (±10%, ±3 dB, exact), and the 'escalate_to' behavior. It stops short of stating cost/read-only traits or runtime limits, but accuracy and escalation behavior are clearly disclosed.

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

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

Front-loads the core purpose and the '(NO solver)' constraint, then uses a pipe-delimited kind enumeration that earns its density. It is information-dense but well structured; the embedded formulas are borderline heavy but serve the 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?

Although there is no output schema, the description specifies the full return shape ({kind, c_m_s, fidelity, band_pct, band_db, valid_range_ok, warnings, escalate_to} plus per-kind payloads), covers all four modes, and gives escalation routing. 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?

Schema coverage is 0%, so the description must compensate, and it does for the mode-specific inputs (lx/ly/lz_mm, neck_area_mm2, neck_length_mm, cavity_volume_mm3, frequency_hz, surface_density_kg_m2, duct_width_mm/duct_diameter_mm, c_m_s, t_ambient_c). The n_modes parameter is only implied via 'the lowest n_modes', so it is not fully specified, keeping this below a 5.

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

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

States a specific verb and resource ('Closed-form acoustics screen') and immediately disambiguates the scope with '(NO solver)', then enumerates the exact 'kind' modes each with its formula. An agent can tell this apart from the Elmer FEM solve without opening the schema.

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

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

Names the alternative (the Elmer `acoustic_fem_submit` solve) and gives an explicit triggering condition: 'escalate ... when the margin is within ~2× the band.' Each kind's required inputs and validity envelope are stated, leaving little to inference.

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 behavioral burden. It usefully discloses the coordinate convention (mm, origin bottom-left, +Y up, matching TechDraw view placement) and the return shape, but says nothing about persistence requirements (e.g. whether a transaction or save is needed) or whether the annotation is attached to the page or a specific view.

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

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

Two tight sentences: placement semantics are front-loaded and the return value is stated compactly. No filler or redundant restatement of the tool name.

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

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

For a 5-parameter mutation tool with no annotations and no output schema, the description covers placement and return shape but omits the semantics of the defaulted parameters and any persistence or transaction expectations. Adequate but with clear 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. It explains the trickiest parameters (x, y) with a full coordinate-frame definition, but leaves 'name', 'page', and 'text' — including the required 'page' identifier and the default 'Note' name — completely undefined. Partial compensation only.

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

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

States a specific verb ('Add') and resource ('free text annotation to a drawing page'), which is clearly more precise than a tautology. It does not, however, distinguish itself from close siblings such as add_feature_note, add_dimension, add_gdt_callout, or balloon_drawing, so an agent must infer the boundary between free-text notes and structured callouts.

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 context of 'drawing page' implies the usage phase (post-drawing creation), and the coordinate note implies placement during page layout. But there is no explicit when-to-use instruction and no mention of alternatives or prerequisites (e.g. whether a drawing page must already exist).

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 error behavior (ValueError on unknown designation or OD <= bore), the seal-suffix identity semantics, coordinate frame (axis +Z, near-face origin), and the precise return shape including the orderable/catalog distinction. This is far beyond a minimal statement.

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?

Information-dense and front-loaded, with the envelope definition first and mechanics after. Slightly long, but every sentence earns its place by answering a real design question; only marginally less tight than an ideal.

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

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

For a 7-param assembly-feature tool with no annotations and no output schema, the description leaves nothing an agent needs to call it correctly: input modes, defaults, error cases, coordinate frame, seal identity, and full return-field semantics are all present.

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

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

Schema description coverage is 0% and the description fully compensates: it defines bore/outer_diameter/width in engineering terms ('sizes the shaft', 'sizes the housing bore', 'shoulder spacing'), documents placement as a near-face xyz translation, and enumerates the seals enum values and their meaning. Every one of the 7 params is given engineering context.

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

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

The description states a specific verb and resource ('Add a deep-groove ball bearing as an assembly envelope solid') and immediately scopes what it is and is not ('an annular ring ... Balls/races are not modeled'). It distinguishes itself from siblings like add_gear/add_sprocket by clarifying this is a fit envelope, not a purchasable modeled component.

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 names two mutually exclusive input paths (designation vs. bore+OD+width) with the rule for what happens when both are given ('Explicit values override'). It also states when an envelope is deliberately unnamed ('a dimensional envelope, not a purchasable part'). Nothing is left ambiguous about how or when to size the call.

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 and it does disclose non-obvious behavior: auto-mode semantics (overall extent across every part-view or a named subset), tolerance fit lookups against ISO 286, forehortening semantics for edge mode, and default vs half-angle behavior. Gaps remain: it does not say whether adding a dimension mutates the drawing page (it does, but 'add' implies it), whether duplicate dimensions are rejected, or permission requirements for this mutation.

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

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

The description is front-loaded with the one-line purpose, then structured as a numbered mode list, followed by parameter and return notes. Every line for tolerance and modes earns its place, but the paragraph is dense and could be slightly tighter; no filler is present.

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

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

For an 11-parameter, output-schema-less mutation tool with zero annotation coverage, the description covers modes, parameters, and return values sufficiently for correct invocation. It stops short of stating the side effects on the page (does it modify the drawing file, need a saved document, cause pagination?) and does not explain how `edge`/`face` tags should be obtained, which would be a useful pointer to list_edges/resolve_edge.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it defines semantics for auto, views, view, edge, face, kind (with all six allowed values and the aligned default), half_angle, tolerance (with three concrete shapes and an ISO 286 example), from_point/to_point as [x,y,z] model points, and even the returned value field. This is far more than the schema conveys.

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 (Add) and resource (dimension(s)) to a drawing page, and then enumerates five distinct modes with clearly distinguished triggering parameters. An agent can tell exactly which invocation shape maps to which outcome. It stands apart from siblings like add_annotation or add_gdt_callout by focusing on measured dimensional callouts.

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?

Explicit when-to-use guidance is provided via the five modes, each listing the exact parameter combination that selects it ('auto=True', 'view + edge', 'view + kind=diameter|radius + edge', 'view + kind=angle + face', 'view + from_point/to_point'). The default kind is documented, and the half_angle flag's effect is explained. The agent has clear routing without having to guess.

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 discharges it: threads are cosmetic (plain cylinder of major diameter), grade changes no geometry but affects the orderable designation, an unrecognised grade is a loud error and never a guess, and an unstocked length is a FINDING rather than a refusal (solid still built). These are exactly the non-obvious traits an agent needs.

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

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

Purpose is front-loaded and the kind list is cleanly bulleted, with almost no filler. It is long, but the density is warranted for a geometrically complex parametric tool; a couple of meta-remarks (e.g. the orderable/grade explanation) run slightly long.

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 6-parameter tool with no output schema and no annotations, the description supplies everything needed: units, threading caveat, minimum hole/counterbore mating numbers, and a full return-shape breakdown (handle, designation, orderable, catalog, per-kind fields). Nothing essential is missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: kind is enumerated with per-kind geometry notes, size is an explicit ISO list (M3–M12), length's requiredness is conditioned by kind, grade defines the three ISO standard families, and placement defines the origin convention (head top at z=0, shank in -z). Each parameter gains meaning beyond the bare schema.

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

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

Opens with a specific verb+resource ('Add a standard ISO metric fastener ... as a solid') and immediately enumerates the four supported kinds, letting an agent distinguish this from siblings like add_bearing or add_gear without opening the schema. The scope and output artifact are 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?

Gives clear conditional guidance: length is REQUIRED for socket_head_cap_screw/hex_bolt and ignored for nut/washer, and grade is optional. It contextualizes the catalog/orderable verdict as a decision aid (move the stack-up vs accept a special), but does not explicitly route the agent to siblings such as standard_part_designate or catalog_search when off-the-shelf matching is the goal.

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 that the gate reads the note back as coverage, that text defaults to a sensible callout, and that it returns a structured object {handle, name, feature, text}. It does not state permission requirements or whether the note can be removed, but it goes well beyond a minimal mutation description.

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 plus two short sentences. It is somewhat front-loaded with the main action, but the middle sentence contains nested parentheticals and jargon ('per CAD model / profile table', 'BSpline wall's profile') that make it harder to scan. It is not wasteful, but it is not tightly structured.

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?

There is no output schema, and the description does provide the return shape and the interaction with drawing_gate's gate check. However, for a 7-parameter mutation tool with 0% parameter coverage, the description leaves most parameters unexplained and does not cover permissions or failure behavior. It is adequate but has clear 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% (all seven parameters lack descriptions), so the description must compensate. It explains that `feature` is the enumerated feature id from drawing_gate's enumerated_features and gives examples, and that `text` defaults to a sensible callout. It does not explain `page`, `x`, `y`, `kind`, or `name`, leaving five of seven parameters undocumented, which prevents a 5.

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 ('Attach an explicit manufacturing NOTE') and ties it to a concrete purpose (satisfying a curved/periodic feature that drawing_gate enumerates). It clearly distinguishes itself from siblings like add_annotation, add_dimension, and add_gdt_callout by focusing on gate-driven feature coverage. It's slightly dense and assumes familiarity with the drawing_gate workflow, but the verb+resource+goal are present.

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 it (when a curved/periodic feature needs 'per CAD model / profile table' coverage or a documented cone angle) and references drawing_gate's enumerated_features. However, it never explicitly says when NOT to use it versus add_annotation or annotate_face, nor does it name those alternatives. The condition is implied but not stated as an exclusion.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose real traits beyond a bare description — the frame renders as a compartmented symbol and is consumed by downstream inspection tools — but it never states that this mutates the drawing document, whether a page must already exist (make_drawing_page), or any reversibility/permission constraints.

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

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

Front-loaded with the core purpose, then a paragraph justifying the tool's value, then a clean per-parameter breakdown. Slightly verbose in the second paragraph, but every clause carries information an agent would otherwise have to guess.

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 11 parameters, no annotations, and no output schema, the description does most of the heavy lifting — covering most parameters and even stating the inline return shape ({handle, name, control, zone, datums, text}). It falls short only on the required `page`/`view`/`name` semantics and the preconditions for the target drawing page.

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, and it documents 8 of 11 parameters with genuine added meaning: the control vocabulary with 13 enumerated ASME Y14.5 values, zone units and Ø rendering rules, datum ordering with inspection implications, feature linkage to drawing_gate's enumerated_features, mmc_bonus, modifier examples, and x/y page-origin conventions. It leaves the required `page` plus `name` and `view` undocumented, which is a notable gap for a required parameter.

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

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

States a precise verb and resource: 'Place a GD&T feature control frame on a drawing page.' It also names the two downstream consumers (inspection_plan / fai_report) and the related-but-different sibling gdt_check, so an agent can distinguish it from add_annotation, add_dimension, and gdt_check at a glance.

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 frames when to use this versus gdt_check: declaring tolerance ON THE DRAWING 'rather than only checking a measurement with gdt_check' is what makes the characteristic inspectable and readable by inspection_plan/fai_report. It also explains that datum content selects the inspection method (CMM vs surface-plate), which is actionable routing guidance.

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

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

With no annotations, the description carries the full burden and does well: it enumerates the returned fields ({handle, name, volume, pitch_radius, tip_radius, root_radius, ...}), states the external/internal distinction, and gives the meshing/phase advice needed to avoid tooth interference. It does not explicitly state that this mutates document state or note any permissions, which keeps it short of a 5.

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

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

Front-loaded with the core purpose, then parameters, return shape, and finally the meshing tip – a logical ordering with no wasted preamble. The density is high but most sentences earn their place, though the return-shape block is somewhat terse.

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

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

With no output schema and no annotations, the description compensates by inlining the return structure and the meshing relationship, plus per-parameter meaning. It is nearly complete; only an explicit note on document-mutation side effects or prerequisites would round it out.

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

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

Schema coverage is 0% (all parameters have titles only), so the description must compensate and it does for every parameter: teeth (count, >= 3), module (mm, pitch diameter = module * teeth), height (extrusion thickness mm), pressure_angle (deg, default 20), external (True external / False ring profile), and placement ([x, y, z] mm translation). This is exactly the missing semantic layer the schema lacks.

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

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

States a specific verb ('Add') and resource ('involute spur gear'), and clarifies the implementation ('FreeCAD's core involute generator') plus the output form ('extruded to a solid'). An agent can immediately distinguish this from sibling gear-adjacent tools like add_rack, add_sprocket, and add_pulley.

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 meshing geometry (axes spaced pitch_radius_a + pitch_radius_b, phase by half a tooth), which is useful context, but it never states when to choose this tool over alternatives such as add_rack or add_sprocket. Usage is implied by the gear-type phrasing rather than explicitly guided.

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 accepted input shapes and the mate-vs-raw-placement relationship, but says nothing about side effects: whether the assembly must be active/open, whether external files are loaded, or what happens on a failed link. It adds format behavior but not mutation/effect transparency.

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

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

The purpose statement is front-loaded and the remaining lines are laid out as compact format definitions with no filler. It is dense but every sentence, including the publish_interface cross-reference, 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 5-param nested tool with no output schema and no annotations, the description supplies the input-format knowledge an agent needs for the two hard composite parameters. What is missing is side-effect/permission context and the meaning of `assembly`, but the core calling information is present.

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

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

Schema description coverage is 0% and nested objects are present, yet the description documents three of the five parameters in detail (source variants, placement forms, mate keys), which is meaningful compensation. `assembly` and `name` (defaults to 'Part') remain undocumented, keeping it short of a 5.

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

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

The first line states a specific verb and resource ('Add a part to an assembly') and names the mechanism (App::Link), which separates it from generic add_primitive/merge_assembly. It does not explicitly contrast itself against those siblings, but the purpose is unambiguous.

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

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

The description gives genuine usage guidance for `mate` ('place by aligning this part's published interface frame ... instead of (or after) a raw placement'), which is a real conditional. However it never states when to choose add_part over merge_assembly, copy_shape, or add_primitive, so the routing guidance is only partial.

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

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

With no annotations, the description carries the burden and does substantial work: it discloses that name sets the LABEL while leaving FreeCAD's internal Name alone, that Name must stay unique and stable for handles/register_handle, that omitting name yields a type default read by BOM and designation checks, and it documents the return tuple {handle, name, label, volume}. Missing a note on failure modes (e.g. no active document) or coordinate-frame semantics for placement, so not a 5.

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

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

Front-loaded with the core action, then structured per-parameter blocks and a returns line; each sentence carries information. The name paragraph is somewhat dense but every clause is load-bearing (label vs Name, uniqueness, defaults, downstream readers).

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

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

For a 7-parameter mutation tool with no annotations and no output schema, the description covers kinds, dimensions, placement, naming semantics, and the return shape, plus the downstream handle contract. It leaves out error conditions and whether an active/selected document prerequisite can fail, keeping it just short of complete.

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

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

Schema coverage is 0%, so the description must compensate and does: it maps w/d/h to 'box', r/h to 'cylinder', r to 'sphere', specifies placement as optional [x, y, z] mm, and explains the label-vs-Name distinction for the name parameter. This goes well beyond the bare 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?

States a specific verb and resource ('Add a primitive to the active document') and immediately enumerates the supported kinds ('box', 'cylinder', 'sphere'), which differentiates it from specialized siblings like add_gear, add_rack, or hole. An agent can identify the tool's scope without inspecting the schema.

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

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

Gives clear operational context: it operates on the active document, the three valid kinds and their dimension sets, optional placement in mm, and the consequences of omitting name. It does not explicitly name alternatives (e.g. 'for a geared part use add_gear instead') or state when not to use a generic primitive, so it stops short of full when/when-not routing.

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

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

No annotations are provided, so the description carries the full behavioral burden. It implies a mutation via 'Add' but does not state side effects, required object preconditions, permissions, or whether the page is modified; the default views list is parameter detail rather than behavioral disclosure.

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

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

Two front-loaded sentences with zero waste. The views example codes and default are useful and appropriately placed after the core 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?

For a 4-parameter mutation tool with no annotations or output schema, the description covers purpose and views defaults but omits the name parameter and does not explain body/page reference expectations. It is minimally sufficient for an agent with FreeCAD context but has clear 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. It thoroughly documents the views parameter with FreeCAD view codes and default value, but leaves the name parameter entirely undocumented and only names body/page without adding reference semantics or type details.

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?

Specific verb (Add) and resource (multi-view projection group), with target body and drawing page named. It does not explicitly distinguish itself from sibling drawing tools like add_section_view or add_dimension, so it falls short of a 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?

No when-to-use, when-not-to-use, prerequisites, or alternative routing. Usage is only implied by the phrase 'to a drawing page,' which is not actionable guidance.

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

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

With no annotations provided, the description carries the full behavioral burden and does so well: it states the axis (+Z), the toothed belt face extent ([0, width]), the effect of flanged (adds two guide discs), the height-overrides-width rule, and the return fields. It also gives the pitch-diameter formula and its mating significance, which are behavioral details not inferable from the schema.

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 appropriately sized for a 7-parameter CAD creation tool and is front-loaded with the core purpose. Each sentence earns its place by adding parameter meaning, geometric behavior, or return-value context, with no redundant restatement of structured fields.

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

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

Given the lack of annotations and output schema, the description is complete: it covers purpose, all parameter semantics, geometric behavior, constraints, and return shape. An agent has enough information to invoke the tool correctly without opening other documentation.

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

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

Schema description coverage is 0%, so the description must compensate, and it does for every parameter. It defines units and meaning for teeth, belt_pitch, width, height, flanged, placement, and name, including constraints (teeth >= 6), examples (2.0 for GT2, 3.0 for GT3/HTD-3M), and the pitch-diameter formula.

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 creation action and resource: 'Add a timing-belt (or V) pulley as a static solid.' It immediately distinguishes the tool from generic primitive creation and from other drive-component siblings like add_gear, add_sprocket, and add_rack by defining the exact mechanical part and its geometry.

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

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

The description provides clear usage context: it is for timing-belt or V pulleys modeled as static solids, with examples such as GT2 and GT3/HTD-3M belt pitches. It does not explicitly state when to choose this over sibling tools like add_gear or add_sprocket, but the context is strong enough to route usage correctly.

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 behavioral burden and discloses substantial detail: standard tooth form formulas, extrusion direction along +Y, profile plane, defaults, and return fields. It still does not cover document-state side effects or error behavior, keeping it from a 5.

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

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

The description is front-loaded with the tool's purpose and then structured into geometry, parameter, and return sections. Despite its length, every sentence provides useful design or invocation information without repetition.

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

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

Given 7 parameters, no annotations, no output schema, and 0% schema description coverage, the description is complete enough: it documents all parameters, return fields, meshing relationship, and geometric conventions. No essential invocation detail is missing for this primitive-creation 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 fully compensates by explaining every parameter: teeth (>=1), module (mm and circular pitch), height (extrusion thickness along +Y, default 6), width (rail base-band thickness, default 10), pressure_angle (deg, default 20, 0<pa<45), placement ([x,y,z] mm), and name (default 'Rack').

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

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

The description states a specific verb and resource: 'Add a linear gear rack (a spur gear's straight counterpart) as a solid.' It explains the geometry and relationship to spur gears, which helps distinguish it from sibling tools like add_gear and add_sprocket.

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 contextual usage: a spur gear meshes with this rack when their pitch values match, and length sizes the rail for travel. However, it does not explicitly say when to choose add_rack over add_gear or other siblings, nor does it state exclusions.

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

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

With no annotations, the description carries the full burden and delivers: it discloses the fallback implementation (native Rib unavailable, built as Pad), the material-adding guarantee (volume strictly greater), and precise raise conditions. This is exactly the behavioral context an agent needs beyond the name.

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

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

Front-loaded with purpose, then Args, Returns, and fallback sections. Well organized and nearly every sentence earns its place, though the length is substantial and the fallback paragraph could be marginally tightened.

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, but the description spells out the return dict (handle prefix 'rib_', name, volume, thickness) and every failure mode. For a complex PartDesign feature tool, 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?

Schema coverage is 0%, so the description must compensate, and it documents all six parameters with real meaning: body source, open-spine requirement, thickness units (>0), midplane semantics (thickness/2 each side), reversed flip sense, and name as label. The sketch attachment-plane note adds orientation semantics not in 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?

States a specific verb+resource ('Add a reinforcing rib/web inside a PartDesign Body') and the mechanism (thickening an open sketch profile into a wall that fuses with surrounding material). This clearly distinguishes it from siblings like pad, sweep, or loft.

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 rich context: the sketch must be an OPEN spine and not a closed loop, reversed is for landing on the wrong side, and the ValueError/RuntimeError conditions define failure boundaries. It stops short of explicitly naming alternative tools (e.g., pad/sweep) or stating when to prefer them, keeping it from a 5.

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 so richly: it discloses automatic feature judgment from the real solid, the cut orientation ('runs lengthwise through such a feature'), placement ('in clear space beside the existing views'), default auto behavior, and the return shape ({added, recommended, reasons, feature_ids, view?, normal?, origin?}).

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

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

The description is front-loaded with the core condition, then the auto semantics, then process and return shape in compact parentheticals. Every sentence contributes useful information about when the tool acts and what it returns, with no filler.

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

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

For a complex CAD automation tool with no annotations, no output schema, and 0% schema description coverage, the description is largely complete: it covers intent, automatic decision logic, override, feature enumeration modes, and return fields. It leaves minor gaps on name, symbol, and page semantics, but those are low-risk naming/placement parameters.

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 should compensate. It explains auto (default True, controls forced vs. conditional addition) and process ('auto' | 'prismatic' | 'turned' — how features are enumerated), but says nothing about page, name (default 'Section'), or symbol (default 'A'). It adds meaningful semantics for two of five 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 states a specific verb and resource ('Add a cross-section view') and scopes it precisely: 'when the part has internal features the outline / hidden-line views convey ambiguously — a counterbore, a blind hole/bore, or a pocket.' An agent can tell this is an automated section-view creation tool distinct from a plain manual section_view call.

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

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

It gives explicit when-to-use conditions and when-not behavior ('auto ... add the section ONLY if the part actually has hidden internal geometry; otherwise return {added: False, recommended: False}') plus an override ('Set auto=False to force a section'). It also references drawing_gate for advance decision support. It does not explicitly name the sibling section_view as an alternative, which keeps it from a 5.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does not state what happens on invalid constraints, whether the sketch must be open, or any side effects, reversibility, or error behavior. It only describes parameter formats.

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?

Concise, front-loaded with the purpose, and organized with clear labeled sections for type, refs, and value. Every sentence adds useful information without redundancy.

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

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

For a constraint-adding tool with four parameters and no output schema, the description adequately covers parameter semantics but omits usage context and behavioral details. It lacks prerequisites, expected outcomes, and error handling. It is minimally sufficient for an agent that already understands the modeling context.

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

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

Schema coverage is 0%, so the description must compensate, and it does well: it enumerates all valid type values, explains the refs structure as [geom_idx, vertex_role] pairs with role codes, and specifies that value uses mm or radians. It could further clarify how many refs each constraint type requires, but this is substantially more than the raw schema provides.

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

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

States a specific verb and resource: 'Add a constraint to a sketch.' The purpose is clear enough to distinguish from geometry-adding siblings like add_sketch_geometry. However, it does not explicitly contrast itself with other sketch-related siblings such as close_sketch or add_sketch_external.

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 no guidance on when to use this tool versus alternatives, nor prerequisites such as requiring an open sketch. It only implies usage through the description of constraint types. No exclusions or context are 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?

With no annotations, the description carries the full burden. It usefully discloses a non-obvious behavioral trait: the projected element gets a negative geom index so subsequent constraints can reference it. However, it does not state permission/auth requirements, whether the projection is reversible, or what happens if the referenced geometry changes or is deleted.

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

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

Front-loaded with the one-line purpose, followed by necessary ref-format detail and a usage example. The ref paragraph is dense but earns its place given 0% schema coverage. No redundant filler.

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

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

For a two-parameter projection tool with no annotations and no output schema, the description covers purpose, ref syntax, behavioral effect, and usage. The sketch parameter itself is left implicit, but it is self-evident from context.

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

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

Schema coverage is 0%, so the description must compensate, and it does: it spells out the ref shapes ({handle, edge: tag|'EdgeN'}, face/vertex variants, and {handle, tag} with e_/f_ prefixed tags). This is far more than the schema's bare object type provides.

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

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

States a specific verb (project), resource (external edge/face/vertex) and destination (into a sketch as construction geometry). This clearly distinguishes it from sibling add_sketch_geometry, which adds sketch-native geometry rather than projecting upstream edges.

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 a clear when-to-use rationale and a concrete example ('a hole 5mm from a tagged edge that survives pad-length edits'), which tells the agent this is for anchoring sketches to upstream geometry. It stops short of naming an explicit alternative or exclusion condition.

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 exist, so the description must carry the full behavioral burden. It discloses that the operation is an append (a mutation) and that it returns Sketcher-assigned indices, but omits prerequisites such as requiring an active sketch/document, transaction requirements, failure modes, and reversibility.

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?

Purpose is front-loaded in one sentence; the item formats are presented as a compact bullet list; the return note is a single terse line. No sentence is redundant.

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 CAD tool with 0% schema coverage and no annotations, the description covers the critical items payload and return value, but leaves the sketch parameter undefined and omits required context such as active document/sketch state and transaction handling.

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

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

Schema description coverage is 0% and the items parameter is an untyped array. The description compensates by specifying the full shape of each item type (line, circle, arc, point) with coordinates and fields, though it does not explain the sketch parameter.

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 begins with a specific verb and resource: append geometric primitives to a sketch, and enumerates the supported primitive types. It clearly distinguishes from siblings like add_sketch_constraint and add_sketch_external, which add different sketch elements.

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 implies usage for adding geometry before constraints and gives the return indices for that purpose, but does not explicitly state when to use this versus alternatives such as add_sketch_external or close_sketch. No prerequisites (active sketch, transaction) or exclusions are 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?

With no annotations, the description carries the full burden and does disclose meaningful behavior: material assumption (STEEL, G=79.3 GPa), spring-rate formula, return fields, and limitations such as unsquared end coils. It does not discuss document state, permissions, or side effects, so it is strong 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 front-loaded with purpose, then organized into parameter meanings, geometry formula, and returned values. Despite its length, each section adds needed engineering context for a 7-parameter CAD insertion tool.

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

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

There is no output schema and no annotations, so the description must carry both usage and return-value context. It does so by listing the exact return fields, their units, and how to use them in a mechanism, making the definition complete for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate, and it does for almost every parameter: units, definitions, constraints (OD > wire_diameter), placement format, and fractional coils are explained. The 'name' parameter is not described, leaving one minor 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 precise verb and resource: 'Add a helical compression spring: a round wire swept along a cylindrical helix.' It also specifies the supported mode ('compression' only in v1) and distinguishes the result from generic helix or other add_* mechanical components.

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 useful constraints such as 'kind: compression (only supported mode in v1)' and notes that end coils are not squared, but it does not explicitly say when to choose this tool over siblings like spring_check, helix, or add_gear. Usage is implied rather than guided.

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 behavioral burden and does so well: it discloses the approximation nature, the exact construction recipe, that bore is 0 (no shaft hole), and enumerates the returned fields. It does not explicitly state document-mutation side effects, but 'Add' plus the return handle makes the create semantics 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?

Front-loads parameters, then build method, then return semantics — a sensible order with units on every numeric. The build-recipe paragraph is slightly verbose for an LLM caller but every clause adds actionable information rather than filler.

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

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

Given 6 params, no output schema and no annotations, the description supplies everything needed: parameter meanings, the derived return values (pitch_diameter, tip_radius), the mating semantics with chain and centre distances, and the known limitation. Nothing required 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?

Schema description coverage is 0%, so the description must compensate, and it does for 5 of 6 params with units and constraints (teeth >= 3, chain_pitch in mm with #40 example, roller_diameter in mm, height default 6.0, placement [x,y,z] mm). Only 'name' is left undocumented, and its title/default make it self-evident.

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

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

States a specific verb+resource ('Add a roller-chain sprocket (ISO 606 / ANSI)') and immediately scopes it as 'built as a static solid plate', which sets it apart from sibling generators like add_gear, add_pulley and add_rack. An agent can identify it without opening the schema.

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

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

Usage is implied by the mating/geometry context and the note that it is a 'fit/visualisation approximation... not a load-rated profile', which effectively tells the agent when this is appropriate. However it never explicitly names alternatives (add_gear, chain_drive) or states exclusions, leaving routing to inference.

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 so richly: it discloses the fallback behavior (plain cylinder tagged with modeled=False), the discrepancy between the modeled minor (5H/8 truncation) and the reported minor_diameter formula, that `grade` changes no geometry, and the mating/drill conventions. This is well beyond baseline behavioral disclosure.

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

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

Front-loaded with the key differentiator and organized with per-parameter lines and labeled notes. It is somewhat long and the multi-sentence `grade`/DIN 976-1 explanation is prose-heavy, but nearly every sentence adds operative detail rather than filler.

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

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

No output schema exists, so the description must explain returns, and it fully enumerates the returned fields ({handle, name, volume, major_diameter, minor_diameter, pitch, length, starts, internal, modeled, designation, orderable, catalog}) and the stocked/cut semantics. For an 8-parameter generative tool this is complete.

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

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

Schema coverage is 0%, so the description must define every parameter, and it does: diameter (major/crest, and bore for internal), pitch (mm per turn with M8 example), length (along +Z from z=0), internal, starts (with lead=pitch*starts rule), grade, placement, and name. Each parameter is given meaning and units beyond the bare 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?

States a specific verb and resource ('Generate a REAL helical ISO-style 60-degree thread as a static solid') and immediately distinguishes itself from the metadata-only siblings `hole`/`list_thread_options` by explaining it 'cuts actual helical geometry'. An agent can tell exactly what this produces versus the alternatives without opening any schema.

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

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

Explicitly names the alternative tools and the condition that selects this one over them, and details the internal=False vs internal=True modes and how to fuse/cut into a hole. It stops short of an explicit 'don't use when' clause, but the routing context is strong and unambiguous.

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

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

With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses that the thumbnail is rendered through the same vector path as other views, scaled to a reserved top-right box, pinned there, left untouched by fit_page, excluded from dimensioning and the manufacturability gate, and returned as a structured best-effort result with placed/box/scale/view/reason fields.

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

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

The core action is front-loaded and the structure moves logically from placement to rendering behavior to failure handling to return shape. It is somewhat verbose and repeats the fit/overlap condition, but the length is mostly justified by the tool's behavioral complexity.

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

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

For a tool with no annotations and no output schema, the description is quite complete: it explains placement, rendering type, fit_page interaction, manufacturability-gate exclusion, failure mode, and return fields. The notable gap is parameter meaning for page and name, which is left entirely to the undocumented 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 description coverage is 0% for two parameters, and the description never explains the page or name parameters. It refers generically to "the sheet" but does not say what page accepts or what name controls, leaving the agent with no semantic guidance beyond the raw schema.

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

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

The description states a specific verb and resource: place a small isometric pictorial of the part in the top-right corner of the sheet. It immediately distinguishes the output from other drawing content by describing it as a vector-line isometric TechDraw projection, not a raster, and as the machinist's glance reference.

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

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

It gives explicit timing and conditions: call AFTER placing views and dimensions and after fit_page, so "fits" is judged against the final layout. It also states the when-not case clearly: if the top-right corner is already occupied, it returns placed=False rather than overlapping content.

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 well: it discloses that the role binds to the stable f_* tag, persists in the .FCStd as a JSON property bag (same mechanism as publish_interface), survives save/reopen, and that re-using a name updates that annotation. Missing only failure/edge behavior (e.g. invalid tag handling).

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

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

Front-loaded with the purpose, then parameter semantics, then return shape. Every sentence carries information, though the prose is slightly long and the return-value sentence could be trimmed given it is partly derivable.

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 but the description documents the return dict in detail (handle, name, role, tag, index, roles). Combined with persistence and update semantics, an agent has everything needed to call this mutation-style tool correctly.

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

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

Schema coverage is 0% (no parameter descriptions in the schema), so the description must compensate entirely — and it does, documenting all five params: handle, face (f_* tag, 'FaceN', or int index), role (full enum list), name (default and update semantics), and meta (stored verbatim with an example).

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

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

States a specific verb+resource: 'Declare the semantic ROLE of a face — what it is FOR'. This clearly distinguishes it from nearby siblings like classify_face_sides (classifying geometry) and list_face_roles (reading roles) by naming the intent-binding purpose.

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?

Explains why to use it (so later edits can be checked against intent) and names a concrete downstream consumer: 'check_airtight_path accepts the role/name directly (e.g. inlet="inlet")'. It does not explicitly contrast with alternative declaration tools such as declare_intent, but the usage 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?

No annotations are provided, so the description must carry the full behavioral burden. It explains the provenance purpose, the timing (after merge), the default filename, and the return shape. It doesn't disclose overwrite semantics or permissions, but it's strong for a 0-annotation 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 dense sentences plus a return summary; every sentence adds information and the purpose 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 2-param, no-annotation, no-output-schema tool, it's remarkably complete: purpose, timing, default, and return shape are all covered. Minor gaps remain around failure modes and overwrite behavior.

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 clarifies that 'lockfile defaults to <manifest>.lock.json' and implies manifest is the input file, adding meaningful semantics beyond the bare schema types.

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

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

States a specific verb (Write) and resource (lockfile) with the exact contents recorded (content hash, interface hash, mate dependencies). It names its sibling function (assembly_lock_check) implicitly via 'provenance baseline a coordinator uses to detect drift'.

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

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

Explicitly says 'Call after a clean merge,' giving a clear precondition. This differentiates it from assembly_lock_check (which presumably verifies rather than writes), though it doesn't name that sibling explicitly.

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, and it does well: it defines each drift category precisely, explains stale as a propagation consequence, and clarifies the meaning of ok. It omits whether the operation is read-only or what permissions it needs, but the semantics strongly imply a non-mutating check.

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?

Written as a compact classification list with a summary of the return object. Front-loaded with the action and outcome. Slightly dense but every line (each drift class) 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 2-parameter comparison tool with no output schema, the description is nearly sufficient: it enumerates return keys and defines each drift class. The one missing element is the lockfile parameter's optionality/default, which the schema alone does not explain.

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 both parameters (lockfile, manifest) are undocumented. The description references a lockfile and a manifest by name but gives no format, default behavior, or interaction semantics (e.g., that lockfile defaults to null). This is the weak point; it partially compensates but leaves real gaps.

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

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

States a specific verb (compare) and resources (component files vs lockfile) with an explicit outcome (classification of drift). It does not name or differentiate itself from the two nearest siblings, assembly_lock and validate_manifest, which an agent could easily confuse it with.

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

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

Usage is implied by the classification semantics (the ok flag offers implicit guidance on when a re-merge is safe), but there is no explicit statement of when to run this versus assembly_lock or validate_manifest. The agent must infer the routing.

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

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

With no annotations, the description carries the full burden and does well: it discloses the non-blocking execution model, the exact return shape ({job_id, status, cache_hit}), and a non-obvious caching behavior (identical (duration_s, value) is a content-hash cache hit with no recompute). It omits failure/timeout or auth characteristics, so not perfect, but rich context is provided.

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

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

Front-loaded with the core behavior and the polling guidance in the first two sentences, so the essential contract is read first. The parenthetical meta-commentary about ankusdrive/jobs.py and the 'real FEM/CFD solve' is helpful context but slightly dilutes the core message.

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-required demo tool with no annotations and no output schema, the description covers what it does, how to retrieve results, and what is returned. It is complete on the interaction loop; only the meaning of the 'value' parameter remains unaddressed.

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, and it only partially does. It names both parameters via the cache-key tuple '(duration_s, value)' and implies duration_s is the compute time ('computes for duration_s'), but 'value' is never explained, leaving the semantics of the first parameter undocumented.

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

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

States a specific verb and resource ('launch a job') plus its defining trait ('runs OFF the MCP channel and return immediately'), which cleanly distinguishes it from synchronous siblings and from job_status/job_result. An agent knows this is the async-launch entry point without opening the schema.

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

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

Explicitly says to poll with job_status / job_result, naming the alternatives for the follow-up step, and explains the off-channel rationale (a multi-minute solve never blocks the worker). It doesn't enumerate when to prefer a synchronous solve over this facility, but the async 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?

With no annotations provided, the description carries the full burden and delivers rich behavioral detail: balloon numbers are persisted identities, re-running reassigns nothing, added dimensions append rather than renumber, deleted dimensions retire their number, and renumber=True discards numbering and invalidates records. It also states the rendered output format (SVG/PDF export) and the exact return shape.

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

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

The description is front-loaded with the core action, then layers essential identity semantics, the renumber warning, call timing, and return shape. Every sentence adds value, but the length is on the higher side for two parameters, and a sentence like the quality-engineer framing is contextual rather than strictly operational.

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 still explains the return value structure (count, balloons, assigned, kept, retired, next_balloon) and the mapping of source objects to numbers. With no annotations, it also covers persistence, identity retirement, and renumber invalidation, leaving no critical gap for correct invocation.

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

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

Schema coverage is 0%, so the description must compensate. It thoroughly explains renumber=True semantics and consequences, which is the non-obvious parameter. The page parameter is only implicitly described via 'drawing page' and the fit_page prerequisite, leaving its expected value format unspecified, so it falls just short of full compensation.

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

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

The first sentence gives a specific verb (number) and resource (every characteristic on a drawing page) with inspection balloons, and explicitly enumerates what gets ballooned (dimensions, feature control frames, feature notes). It clearly distinguishes this from siblings like add_dimension, add_annotation, and add_feature_note by describing the output and rendering behavior.

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 states the prerequisite sequence ('Call it after the dimensions are placed and fit_page has run') and warns about the when-not condition for renumber (invalidates existing inspection records). It also names the downstream consumers (inspection_plan, fai_report) that depend on balloon identity, giving clear context for when this step matters.

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 well: it declares immutability, determinism ('same state -> identical bytes'), byte-level fingerprinting, and the optional sidecar write via 'out'. It omits collision/overwrite behavior for an existing label and any permission requirements, which keeps it short of a 5.

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

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

Front-loads the core action, then lists parameters, then return/determinism. Efficient overall, though the parenthetical jargon ('issue #142, C3', '{item: revision + content fingerprint}') adds density without much selection value.

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 6-param mutation tool with no annotations and no output schema, the description covers parameters, side effects, determinism, and a brief return note ('Returns the baseline object'). It is nearly complete, missing only collision/overwrite and auth context.

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

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

Schema description coverage is 0%, so the description must compensate and does: all six parameters (label, registry, items, base_dir, note, out) are individually explained with meaning and defaults. This is exactly the value-add the schema lacks.

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

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

States a specific verb (pin/create) and resource (a labeled, immutable BASELINE snapshot over an items.json registry), with concrete analogies (git-tag/lockfile over the item graph). An agent can distinguish it from baseline_verify or release_package without opening any schema.

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

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

The stated purpose ('for reproducible rebuilds', 'verifiable byte-for-byte') implies when it is useful, but there is no explicit when-to-use vs the sibling baseline_verify, no exclusions, and no stated prerequisites. Usage must be inferred from context.

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

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

With no annotations, the description carries the full burden and largely meets it: it discloses that every pinned item is re-resolved and checked against both rev AND content fingerprint, and enumerates the drift cases (changed bytes, bumped rev, vanished item) that are caught rather than silently accepted. It does not mention permission or rate-limit behavior, so it falls short of a 5.

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

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

Front-loaded with purpose, then a parameter glossary, then the return shape. Well organized and mostly waste-free, though the parenthetical issue tag and drift examples add some length.

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

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

With no output schema and no annotations, the description supplies both the return shape ({ok, label, drifted, missing} and the ok semantics) and the behavioral core, which is strong coverage. Minor gaps remain around prerequisites/permissions for a gate that pins reproducibility.

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 documents all three parameters: baseline (baseline sidecar path), registry (current items.json sidecar path), and base_dir (artifact root for fingerprinting, with its default). This meaningfully exceeds the bare type info in 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?

States a specific verb (Verify) and resource (a rebuild against a pinned baseline) and frames it as 'the reproducible-rebuild gate.' It is clearly distinguishable from siblings like baseline_create, items_validate, and verify_contract without opening any schema.

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

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

It gives a strong contextual frame ('reproducible-rebuild gate') that implies when to use it, but it never names an alternative (e.g. items_validate, items_resolve, baseline_create) or states a when-not condition. Usage is inferable rather than explicit.

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

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

With no annotations, the description carries the full burden and does well: it discloses the method (exact Euler + Johnson, no solver), the transition mechanic at √(2π²E/σ_y), that the safety factor is returned when load_n is given, and enumerates the return payload including fidelity, band_pct, valid_range_ok and warnings. It does not state failure modes or what invalid/out-of-range inputs produce, which keeps it short of a 5.

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

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

Dense but front-loaded: the core identity and the no-solver distinction come first, then input modes, then the return shape. Telegraphic style packs a lot into few sentences, though the mid-paragraph formula details are slightly heavy for a description.

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 annotations and no output schema, yet the description supplies the return field list, the escalation path, and the physics governing the computation, which is enough for an agent to call it correctly. Minor gap: length_mm and precise behavior on out-of-valid-range inputs are not spelled out.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: it maps the three section input modes (width_mm+height_mm, diameter_mm, area_mm2+i_min_mm4), the material-property sources (youngs_gpa/yield_mpa or a Materials-DB material), the four end_condition values, and the role of load_n. The required length_mm is only implied, not explicitly explained.

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

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

States a specific verb+resource ('Exact column-buckling screen (Euler + Johnson, NO solver)') and immediately positions itself against the sibling eigen-solve tool fem_buckling, including the analogy to beam_modal/fem_modal. An agent can distinguish it from fem_buckling without opening either schema.

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

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

Gives an explicit escalation rule: 'Escalate to `fem_buckling` for non-prismatic / eccentric / built-up cases', which is a clear when-not/alternative condition. It also implies when-to-use by framing itself as the closed-form screen the FEM solve is gated against.

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 well: it discloses that there is no solver, that only up to 5 modes are supported per boundary, the material alternatives, and the accuracy domain of slender-beam theory. It does not state numeric limits (min slenderness ratio) for when the result becomes unreliable, so not a 5.

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

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

Front-loads the identity and formula, then physical caveats, then return shape. Dense but nearly every clause earns its place; the formula and symbol-heavy phrasing make it slightly heavier than strictly necessary 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?

For a physics oracle with no output schema, the description compensates fully by listing the return object's fields and explaining the underlying model, units, and applicability limits. An agent has everything needed to call and interpret it.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it enumerates all five valid `boundary` values (which the schema does not), explains `n_modes` (up to 5 each), the `youngs_gpa`+`density_kg_m3` vs `material` alternatives, and the bending direction tied to `height_mm` (I = width·height³/12). It adds little on the sheer `length_mm`/`width_mm`/`height_mm` units, but the physics context is strong.

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

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

States a specific verb+resource+method: 'Exact Euler-Bernoulli natural frequencies of a uniform rectangular beam' and explicitly identifies itself as the closed-form modal oracle that fem_modal is gated against, cleanly separating it from that 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?

Establishes when this tool is appropriate (closed-form, no solver, slender beams) and when it is not ('thick beams need a Timoshenko correction'), and names the gating relationship to fem_modal. It does not spell out an explicit either/or selection rule with fem_modal, so it stops short of a 5.

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

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

No annotations are present, so the description carries the burden and does so well: it explains the ISO 281 model, the two-path C sourcing, that catalog lookup additionally reports bore/OD/width, C0 and static safety factor, and how the 'pass' field is evaluated against target_hours. It does not explicitly state side-effect/auth profile, but for a pure computation tool that is minor.

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

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

Front-loaded with the core purpose and formulas, then the return shape; every sentence earns its place with no filler. It is dense and formula-packed, which is warranted for a 6-parameter engineering tool but slightly reduces readability.

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

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

With no output schema, the description enumerates the returned fields ({l10_million_rev, l10_hours, load_ratio, dynamic_load_c_n, exponent, pass, ...}) and the pass logic, and covers most of the 6 params. It is nearly complete for a stateless calculation tool, missing only explicit units and edge-case precedence rules.

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 by mapping dynamic_load_c_n to C, designation to the catalog lookup with an example, target_hours to the pass condition, and implicitly P and n through the formulas, plus 'p=3 ball, 10/3 roller' for the kind parameter. It does not spell out the roller value or precedence when both designation and dynamic_load_c_n are given, keeping it just below full marks.

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

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

States a specific computation (basic rating life L10 per ISO 281) with the governing formulas, making the tool's job unambiguous. The topic is clearly distinct from siblings like gear_rating, spring_check, or fatigue_check. An agent can tell immediately what this tool produces.

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

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

Gives clear context for invocation: supply C directly as dynamic_load_c_n, or pull it from the deep-groove ball catalog via designation (with an example and the extra data returned). It does not name alternative sibling tools to prefer or state when not to use it, so it stops short of full when/when-not routing.

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

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

With no annotations, the description carries the full behavioral burden. It helpfully discloses the computation model and the exact return keys, but says nothing about what determines the 'pass' flag, what limits or thresholds are applied, or how inputs like tight_side_limit_n affect 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?

Very compact and front-loaded: the core purpose leads, followed by equations and the return list with no filler. It is a bit dense (formula block crammed into one line), but every element earns its place.

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

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

For an 8-parameter tool with no output schema and no annotations, the description usefully enumerates the return fields and the physics model. However, it omits the meaning of the 'pass' result, threshold criteria, units for several inputs, and full parameter definitions, leaving meaningful 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. The equations do add engineering meaning for several parameters (power_w=P, diameters=D/d, center_distance=C, friction_coef=mu, vbelt_groove_deg=beta), but the mapping is implicit and tight_side_limit_n and small_pulley_rpm are left unexplained, so coverage is partial.

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

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

States a specific verb+resource ('Rate a belt drive') and even names the governing method (Eytelwein/capstan), so the agent knows exactly what computation this performs. It does not explicitly contrast itself with the related sibling 'chain_drive', but the belt-specific framing is unambiguous.

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

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

There is no when-to-use guidance, no prerequisites (e.g., which inputs are mandatory vs optional, valid ranges), and no mention of alternatives like chain_drive or gear_rating. The description only explains the math, leaving the agent to infer applicability.

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 it discharges much of it: it discloses the computation path (T=K*F*d), the defaults, and enumerates the returned fields (preload_n, bolt_stress_mpa, pass, governing). It never explicitly states that the tool is a side-effect-free rating computation or notes any rate/auth limits.

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

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

Front-loaded with purpose and method, then proceeds through inputs and returns. The semicolon-chained sentences are dense but each clause carries real information; nothing is filler.

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

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

Since no output schema exists, the description usefully enumerates returned fields, and it covers geometry sourcing, preload derivation, and the judgment basis. Minor gaps are the unexplained material, k_factor, and joint_stiffness_ratio parameters, but overall an agent has enough to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: bolt_size semantics with 'M8'/'M8x1.0' examples, property_class with the ISO 898-1 '8.8' example, torque/preload alternatives, and preload_target_pct are all explained with meaning. Gaps remain for k_factor, material, external_load_n, proof_strength_mpa, and joint_stiffness_ratio, which are not described.

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

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

States a specific verb ("Rate") and resource ("a bolted joint") and names the underlying method (VDI 2230-lite), which lets an agent distinguish it from sibling strength/contact checks like hertz_contact or press_fit_stress without opening the schema.

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

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

Gives clear conditional guidance for inputs: geometry via bolt_dia_mm (+pitch_mm) OR a standard bolt_size, preload via torque_nm OR preload_n, and explicit preload_target_pct values for reused vs critical permanent joints. It does not, however, state when to choose this tool over sibling 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, the description carries the full burden and does so thoroughly: it discloses the default return type, the alternate dict return shape and its fields, that offending rows stay IN the list rather than being dropped, and that availability is a curated market snapshot ('captured', 'market'), not physics. This is exactly the beyond-schema behavioral context an agent needs.

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

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

Front-loaded with the return contract before the parameter details, and every paragraph maps to a parameter or behavior. It is long and dense, with some detail that could be trimmed, but no sentence is purely redundant.

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

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

For a 5-parameter tool with an output schema and no annotations, the description covers modes, defaults, return shapes, edge-case handling, and the nature of the stock data. 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?

Schema description coverage is 0%, so the description must compensate and it does: density is given a unit (kg/mm³) and marked optional, recursive's default and semantic effect are explained, orderable's default and view-switch meaning are explained, and check_stock's effect on designation is stated. Only the required 'assembly' param is left implicit, which is self-evident.

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

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

States a concrete verb and resource ('Walk an assembly and return rows grouped by source'), and explicitly disambiguates the grouping key ('component file + object, NOT the bare object name'). An agent can tell what it produces and how it differs from a naive BOM listing without opening the schema.

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

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

Gives explicit when-to-use guidance for each mode: recursive=True flattens to leaf parts vs False counting subassemblies as one line; orderable=False is the default bare list because everything downstream consumes it, orderable=True opts into the BUYABILITY view; check_stock=False designates without availability checks. The condition selecting each mode is 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, the description carries the full burden and does so: it discloses the default warn-don't-fail policy and the rationale (cutting everything away is legitimate), the two failure modes (annihilation, miss), and the key-absence contract so the caller knows 'warnings' in result is the test. This is exactly the behavioral context an agent needs.

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

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

Front-loaded with the core purpose and op semantics, then progressively details return values and warnings. Every unit of information is useful, though the return-value block is dense and slightly verbose in places rather than perfectly tight.

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, yet the description fully specifies the return object (handle, volume, removed_volume, volume_ratio) including the sign convention on fuse and the None case for an empty base. For a 4-param, annotation-free CSG tool, 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?

Schema coverage is 0%, so the description must compensate and it does: it defines each op value, explains that base/tool are handles from add_primitive with example format ('box_1', 'cylinder_1'), and describes strict's effect (raise vs warn on degenerate cut). All four parameters gain meaning beyond the bare schema.

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

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

States a specific verb (boolean operation) and resource (two existing objects referenced by handles), and enumerates the three operation semantics ('cut' base minus tool, 'fuse' union, 'common' intersection). This clearly distinguishes it from nearby modelers like pad, pocket, and revolve that build rather than combine bodies.

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

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

Gives strong conditional guidance: when the two warned degenerate cases occur and when to opt into strict=True ('pass strict=True in a scripted recipe'). It also tells the caller where base/tool handles come from (add_primitive). It stops short of explicitly framing when to choose boolean_op over sibling CSG/modeling 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?

No annotations are provided, so the description carries the full burden and does so richly: it discloses the issue #284 analytic-box over-estimation quirk, the ~1.4s tessellation cost of tight=True, the meaning of every `verified` verdict, and the guarantee that the true box lies between tight and analytic. This is exactly the behavioral context annotations would otherwise supply.

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?

Long but front-loaded: purpose and the critical quirk come first, then parameter semantics, then the return dict. Every section is purposeful given the complexity, though the prose is denser than strictly necessary in a few places.

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

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

With no output schema and no annotations, the description correctly takes on documenting the full return dict (min/max/size/center/diagonal/oriented/verified/tight/warnings) and the safety/behavior profile. Nothing an agent needs to call or interpret this tool is missing.

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

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

Schema coverage is 0% (no property descriptions), so the description must compensate, and it does: it defines handle, oriented (orientation vs tightness, null on failure), tight (mesh-derived, opt-in cost), and deflection (chord tolerance, default diagonal/2000, floor 0.001mm, larger = coarser/faster). This fully covers all four otherwise-undocumented 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?

States a specific resource (axis-aligned bounding box of a shaped object) plus units and coordinate frame, and explicitly frames it as a read-only measurement ('returns numbers, not a new object, and does not modify the model'). This distinguishes it from measurement siblings like measure_distance and mass_properties without needing the schema.

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

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

Gives clear situational guidance: 'Before you conclude a part is the wrong size, check "verified" (and pass tight=True)' and explains when to opt into the costly tight box. It does not, however, explicitly contrast against sibling tools (e.g. measure_distance) for the same measurement need, so 4 rather than 5.

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 so well: it declares the tool is offline and deterministic, enumerates every return `code` with its meaning, specifies that `ok` is True only for `stocked`, and explicitly warns that `not_catalogued` is an absence of evidence rather than a claim of unavailability. That is exactly the kind of non-obvious behavioral context an agent needs.

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

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

Front-loaded with the core question, then the input modes, then the return contract. The code enumeration is long but each entry is load-bearing since no output schema exists; only slight verbosity in the branching explanations.

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?

There is no output schema, so the description must describe the return shape — and it enumerates the full result object and the meaning of each status code, including edge cases like cut-to-length stock and undesignated inputs. Complete for the task.

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% with two undocumented parameters, so the description must compensate; it does by defining `designation` as a canonical designation, giving concrete format examples ('ISO 4762 M4×12 A2', '608-2RS'), and explaining that `handle` refers to a part whose designation was stamped at generation. It doesn't clarify precedence if both are supplied, minor 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?

States a specific decision question ('Is this exact part something you can buy off the shelf?') with a clear resource (catalog stock lookup), and its scope is distinct from siblings like catalog_search, catalog_nearest, and designation_check. An agent can tell immediately what question this tool answers.

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?

Explains the two accepted input forms and cross-references catalog_search's `not_covered` field for the out-of-corpus case, which gives useful context. However, it never states when to prefer this over designation_check or catalog_search/catalog_nearest, so sibling routing is only partially addressed.

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 and does so: it states that arithmetic is exact on a discrete ladder with no interpolation, no silent rounding, both rungs plus signed deltas returned, and that ok=True means the request is already stocked. These are precisely the behavioral traits an agent needs and none are in structured fields.

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

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

Front-loaded with the core behavior and organized into purpose, per-parameter notes, and return semantics. A few sentences are narrative flourish ('This is the call that changes how you design') that cost space without adding invocation-relevant information, but overall it stays tight.

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 4-parameter tool with no output schema and no annotations, the description covers inputs, arithmetic behavior, the full returned field set, the meaning of designation, and the ok flag. An agent has everything needed to call it and 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?

With 0% schema description coverage, the description compensates fully: it defines standard (with two alias examples), size (thread designation, nominal mm, shaft/bore mm), length (omit for no-length products or to list the whole ladder), and grade (optional property class/material used to complete the returned designation). It adds semantics far beyond the bare schema.

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

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

States a specific verb and resource: snapping a desired standard part to the nearest one that actually exists, with a concrete example (ISO 4762 M4×13 → 12/16 stocked). This is distinguishable from catalog_search and catalog_check because it is explicitly about resolving to the nearest discrete rung rather than searching a catalog.

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

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

Gives clear context for when to call it — the moment a fastener length falls out of a dimension chain, before geometry hardens. It does not explicitly name or exclude alternatives such as catalog_search or catalog_check, so the routing guidance is strong but not complete.

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 — and it does: 'Offline, deterministic, zero network' declares the side-effect profile, and it proactively warns that availability is 'a curated snapshot of a MARKET... not physics' and to 'read `not_covered` before concluding from an empty result that a part does not exist.' That is exactly the caveat an agent would otherwise get wrong.

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

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

Front-loaded with the essential distinction and structured as filter list + return-shape list, so it scans well. It is somewhat long and includes a rhetorical 'somebody can build' clause, but nearly every sentence carries actionable content.

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

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

With no output schema, the description fully enumerates the return envelope ({ok, count, truncated, items, standards, fidelity, captured, market, not_covered}) and the item shape, and it flags the truncation and market-fidelity semantics. An agent has everything needed to call it and interpret results.

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

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

Schema description coverage is 0% and there are 10 parameters, so the description must compensate — it documents every filter with example values and accepted vocabularies (family enum of 9 names, 'ISO 4762' or 'DIN 912' for standard, min_length/max_length window semantics, limit default 50). This adds meaning the bare anyOf/null schema does not.

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

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

States a specific verb+resource ('Browse the off-the-shelf catalog') and then draws the exact boundary against adjacent tool families: 'The dimensional corpora (threads/bearings/stock) tell you what a part measures. This one tells you whether it is a thing you can buy.' An agent can distinguish it from catalog_nearest, list_thread_options and the geometry builders without opening a schema.

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

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

Gives explicit when ('Call it while designing, before you commit geometry to a number') and an explicit contrast with the tools it resembles, plus the consequence of skipping it ('the difference between a design somebody can build and one that needs a special'). The 'run this before you pick catalog_nearest/catalog_check' workflow is inferable from the stated sequencing.

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