CheckFitment

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds value beyond that: it discloses the data is bounded by 'the dataset' and explicitly labels torque ranges as 'guidance only', a meaningful caveat for an agent relaying safety-relevant numbers to a user.

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 'Use for' followed by four high-signal example queries, then a compact enumeration of outputs. It is one dense sentence that stays readable, though the example-query list is long enough that a reader must parse it fully to reach the capability list.

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 an output schema present, return values need not be explained, and the description covers inputs, outputs, and safety caveats adequately for a single-parameter read tool. The main omission is routing guidance against the near-duplicate sibling bolt_pattern_lookup, which an agent would need to choose 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 100% and the pattern parameter already carries format examples (5x114.3, 5x4.5, 6x139.7, 8x6.5). The description restates that both mm and inch notation are accepted but adds no syntax, normalization, or parsing rules beyond the schema. Baseline 3 applies.

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

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

States specific verbs and resources: unit conversion of bolt patterns, look-alike listings, vehicle membership, lug tightening order, and torque ranges. An agent knows exactly what comes back. It does not, however, distinguish itself from the sibling 'bolt_pattern_lookup', which sounds like it covers overlapping ground.

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 quoted example queries ("what is 5x114.3 in inches", "is 5x114.3 the same as 5x115", "will 6x135 wheels fit 6x139.7", "which vehicles use a pattern") give concrete triggering contexts that map directly onto user intent. No explicit exclusions or named alternatives are given, and the overlap with bolt_pattern_lookup and wheel_fitment_check is left unresolved.

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

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

Beyond the readOnly/openWorld=false annotations it discloses the crucial behavioral trait: the tool reads from a fixed dataset where each spec is cited and marked verified or unverified. It also documents the failure mode (not_in_database / year_covered false, no figures returned) and forbids filling gaps from memory — exactly the context an agent needs to avoid hallucinated fitment data.

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 use cases are front-loaded in a single dense sentence, then failure semantics. Every clause carries information, but the paragraph is long and run-on, which slightly slows scanning for the critical 'no figures returned' constraint.

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?

An output schema exists, so return values need not be spelled out, yet the description still flags the key response keys (not_in_database, year_covered) and the verified/unverified marking. For a fixed-dataset lookup with four simple parameters, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 75%, and the description adds real meaning beyond the schema by explaining that optional wheel_center_bore_mm 'runs the hub-centric check' rather than just echoing 'center bore of a wheel you want to check'. The year parameter gains implicit semantics from the year_covered false outcome, though make/model normalization behavior is 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?

The description names a specific resource (bolt pattern, lug torque, center bore, thread size, offset, tire size) and anchors it with concrete example queries ('what is the bolt pattern on a 2019 Ford F-150'). It also carves out the boundary against wheel_fitment_check by limiting itself to cases 'when the vehicle is named'.

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

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

It gives clear trigger conditions via the example phrasings and an explicit exclusion ('when the vehicle is named', and the wheel_center_bore_mm path for fitment checks). It does not name sibling tools such as wheel_fitment_check or tire_size_compare directly, leaving the routing inference slightly implicit.

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

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

Annotations already establish that this is read-only, idempotent, non-destructive, and closed-world. The description adds useful behavioral context by listing the computed outputs: effective ratio, before/after RPM, stock-feel restoration ratio, nearest sold gear set, and severity of the change. It does not contradict annotations, though it adds little about units, assumptions, or limits beyond the output 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 front-loaded with the intended use cases and then states what is returned. Every clause maps to a real query pattern, but the first sentence is long and lists several examples in a run-on way, making it slightly less crisp than a 5.

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 an output schema present, the description does not need to enumerate return values, but doing so reinforces what the tool computes. Annotations cover the safety profile, and the description covers the main use cases and the crawl-ratio dependency on first gear and transfer-case low ratio. It is complete enough to invoke correctly, though it could explicitly route overlapping tire-comparison questions elsewhere.

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

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

Schema description coverage is 67%, and the description helps explain several parameters in context: old/new tires, axle ratio, highway speed for RPM, and crawl ratio using transfer-case low ratio plus first gear. It compensates for the two schema parameters with no descriptions by naming first_gear_ratio and transfer_case_low_ratio in the crawl-ratio use case. It still does not clarify tire notation or speed defaults, which the schema handles.

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 makes the tool's domain specific: gear ratio effects from tire changes, regearing, highway RPM, and crawl ratio. It gives concrete example queries and returned values, so an agent can tell it is not a bolt-pattern or wheel-fitment tool. It does not explicitly name or contrast with the closest sibling, tire_size_compare, 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?

The description explicitly says to use this for "what does my 3.73 axle behave like on 35s", regear questions, highway RPM after tire changes, and crawl ratio calculations. That is clear positive guidance, but it does not state when not to use it or name an alternative tool for overlapping tire-comparison questions.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered there. The description's added content is mostly a restatement of the return values, which the output schema already provides; it adds no new behavioral context such as calculation assumptions or limitations.

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

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

Two sentences, trigger examples front-loaded before the return list, with no filler. Slightly heavy on enumerating outputs that the output schema already covers, but still tight and readable.

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-input, read-only calculator with a complete output schema and full annotation coverage, the description supplies everything an agent needs to select and invoke it; return-value detail lives in the output schema as intended.

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

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

Schema description coverage is 100%: the schema already documents the metric/flotation formats, P/LT prefixes, exclusion of load index and speed rating, and the default/range for speed_shown. The description only supplies illustrative examples of those same formats, so baseline 3 applies.

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

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

The description names a specific comparison operation between two tire sizes and enumerates the concrete outputs (diameter, width, sidewall, ride-height change, true speed, odometer error). This clearly separates it from siblings such as wheel_fitment_check or gear_ratio_calculator.

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?

Three natural-language example triggers ('what changes if I go from 265/70R17 to 285/75R17', 'how far off is my speedometer with 33s', odometer error) make the intended use case unmistakable. It does not, however, state when NOT to use it or name which sibling to prefer for fitment/clearance questions.

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

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

Annotations already declare the tool as a safe, read-only, idempotent calculation. The description adds useful behavioral context: it explains the fitment verdicts (fits / tight / rub) and that clearances must be measured on the current setup. It does not disclose assumptions such as same bolt pattern or stock suspension.

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 but front-loaded sentences; the main comparison purpose is first, and the optional tire-field behavior is placed last. It is appropriately sized, though the long first sentence packs many outputs together.

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 an output schema and read-only annotations, the description is complete enough to call correctly: it covers the comparison, the optional tire fields, and the clearance-based verdict. Minor gaps remain around assumptions (same bolt pattern, suspension setup) and offset sign semantics.

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 50%, and the description adds meaning mainly for the optional tire fields and the clearance measurements. It does not explain the offset sign convention or how the required wheel width/offset parameters drive the comparison, leaving several parameters to the schema names and ranges.

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 comparison task: current wheel/tire vs new wheel/tire, with outer/inner clearance, diameter, speedometer, backspacing, and tire-to-rim suitability. The purpose is clear, but it does not explicitly distinguish itself from the sibling tire_size_compare or wheel_spacer_calculator.

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?

Begins with 'Use to compare...' and gives a clear conditional: omit tire fields for a wheel-only offset comparison. It does not state when not to use it or name alternative sibling tools for overlapping cases.

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

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

Beyond the readOnly/idempotent annotations, the description discloses the underlying rule ('a spacer lowers the effective offset by its thickness'), the slip-on vs bolt-on classification, and the exact engagement thresholds (>= 1x stud diameter and >= 6.5 turns). It also makes clear that the engagement check only runs when `stud`, `stud_protrusion_mm` and `wheel_pad_thickness_mm` are supplied — conditional behavior not visible in annotations.

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

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

Two sentences, examples front-loaded, no filler. The second sentence is long and packs several clauses together, but every clause carries distinct information about outputs or thresholds.

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 read-only calculator with an output schema, the description covers the physics, the two computation modes, and the qualitative outputs (track change, slip-on vs bolt-on). The only residual gap is the sign/relationship between `offset_mm`, `spacer_mm` and `target_offset_mm` when both spacer and target are supplied.

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 only 50% (`spacer_mm`, `target_offset_mm` and `stud` are undescribed in the schema), and the description compensates by explaining that `target_offset_mm` drives the recommended spacer and which three parameters trigger the engagement check. `spacer_mm` is never explicitly described, leaving one mode of the tool to inference.

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

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

The description states a concrete verb+resource ('spacer needed for a target offset', 'thread-engagement check') and its opening quotes make the real-world questions it answers unmistakable. It is clearly distinct from siblings like wheel_fitment_check, though it never names an alternative, so it stops 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?

The three quoted user phrasings ('do I need spacers', 'what spacer gets +35 wheels to +20', 'is a 10 mm slip-on spacer safe') effectively convey when to reach for this tool. There is no explicit when-not guidance or named sibling to route away to, so context is clear but exclusions are absent.

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