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

With no annotations, the description carries full disclosure burden: it does name what data comes back (model, MVS version, build date, engine number, colours, CARATT options), which is genuinely useful. It says nothing about failure behavior for unknown/invalid VINs, whether results hit an external ePER service (latency, rate limits), or read-only/reversibility traits.

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

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

A single front-loaded sentence with the action and scope first and the return fields following. No filler, nothing repeated from 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?

With no output schema and no annotations, the list of returned fields is a meaningful compensation, but the definition still leaves an agent without error handling guidance, any indication of external-service dependency, or whether partial results are possible (e.g., VIN unknown in some catalogues).

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 each parameter (vin, lang, include_options) is documented in the schema, so baseline 3 applies. The mention of 'factory options (CARATT)' loosely maps to include_options but adds no syntax or defaulting detail beyond the schema.

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

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

States a specific verb (Decode) plus resource (VIN) and names the data source (ePER chassis data), then enumerates the payload. No sibling in the list does VIN decoding, so no differentiation is needed, though the enumeration reads more like a field list than a purpose statement.

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 / when-not-to-use guidance, no prerequisite conditions (e.g., that a 17-char VIN is required, or that it queries ePER chassis data specifically), and no pointer to any alternative tool for parts lookup if the VIN is not found. Usage is only implied by the verb.

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 disclosure burden. It explains the visual output and red framing behavior, but it does not cover return format, permissions, handling of multiple views, failure cases, or what happens when no exploded view exists.

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

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

The description is two efficient sentences, front-loading the primary action and then adding usage examples and highlighting behavior. The parenthetical qualifiers are compact, though slightly informal.

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

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

The schema is fully documented and the description sufficiently identifies the operation, but with no annotations and no output schema, it should do more to explain what the tool returns and how it relates to get_drawing_image. The core invocation is clear, but context is incomplete for an image-producing 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 100%, so all four parameters are already documented in the input schema. The description mentions reference numbers being framed in red, which relates to the highlight parameters, but adds no syntax or behavioral detail beyond the schema.

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

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

The description states a specific verb-resource pair: show an exploded view of an assembly part. The brake caliper example and the has_components/inside_assembly condition make the intended resource clearer, though it does not explicitly distinguish this from the sibling get_drawing_image tool.

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

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

The description implies the tool is for assembly parts with components or parts inside assemblies, giving some usage context. However, it lacks explicit when-not guidance and does not name get_drawing_image or other siblings as alternatives.

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 the important behavioral trait: the return is a rendered drawing in which matching reference numbers are framed in red, which is non-obvious visual behavior. It omits any mention of error cases (e.g., missing variant) or whether all parts are shown when no highlight is requested.

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, front-loaded with the core action, and the second sentence explains the user-facing value of the highlighting rather than restating parameters. Efficient, with only minor redundancy between the two sentences about red framing.

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, 4-required tool with no annotations and no output schema, the definition covers the essentials (key source, draw action, highlight effect) but not the hierarchical semantics of catalogue/group/subgroup/sgs_code or what the image contains when no highlights are given. 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 coverage is 57%, so roughly half the parameters are documented in the schema. The description adds real meaning for highlight_refs/highlight_parts (they cause parts to be framed in red) and validates the key set against get_table_parts, but says nothing about group/subgroup/sgs_code hierarchy or variant selection beyond what the schema already states.

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 ('Show the exploded-view drawing of a parts table') and ties the key structure to get_table_parts, which lets an agent map inputs immediately. It doesn't explicitly contrast with the similar sibling get_assembly_image, so sibling differentiation is partial.

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?

'Same keys as get_table_parts' implies the workflow (look up a parts table, then request its drawing), but there is no explicit statement of when to choose this over get_assembly_image or what happens if no highlight parameters are supplied. Usage is inferable rather than stated.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the shape of the returned content (cut-over points: build date, chassis, engine, organization number), which compensates for the absent output schema, and "Describe" implies a read-only lookup. However, it says nothing about error behavior for unknown codes, whether one or many records come back, or locale fallback 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?

One sentence, front-loaded with the action and resource, with the explaining details (example code, return fields) parenthesized rather than padded into extra clauses. Nothing here is wasted.

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

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

For a simple three-parameter lookup with a fully documented schema and no output schema, the description covers the essential contract: what it looks up and what comes back. The remaining gaps (unknown-code behavior, cardinality of results) are minor for a reference lookup 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 100%, so the schema already documents all three parameters, including the D/C-prefix rules and language fallback. The description adds only the contextual detail that the code originates in a MODIF field, which is mildly helpful but not required to call correctly. 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 pairs a specific verb ("Describe") with a specific resource (a modification code from a MODIF field) and lists the exact content returned (build date, chassis, engine, organization number). It also grounds the input with a concrete example ("D2105"), making the tool unambiguous. It doesn't explicitly contrast with siblings, but none of the listed siblings overlap in domain.

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 only implied: the agent infers it should call this when it has a MODIF code in hand. There is no statement of when not to use it, no prerequisite call sequence, and no mention of what happens with an unknown/invalid code. The pointer to decode_vin/list_catalogues for the catalogue param is in the schema, not the description.

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 carries the full burden; it does disclose the returned fields and a conditional behavior (components only when the part is an assembly), which is real value. It says nothing about behavior when the part number is unknown, whether lookups are cached, or result size, which is a notable gap for an unannotated, output-schema-less 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?

One front-loaded sentence that spends its words listing actual return fields rather than filler. It is close to ideal length, though the field list could be grouped or the part-number expectation appended without bloat.

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 does a fair job of describing the response shape, but omits what an agent needs to call it confidently: accepted part-number format and not-found behavior. Adequate but with clear gaps for a two-parameter lookup 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 coverage is only 50%: 'lang' is documented in the schema with its ja default and English fallback, but 'part_number' has no schema description and the description never specifies format, normalization, or prefix expectations. The description adds no parameter meaning beyond restating that a part number is the input.

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 (get) and resource (details of a part number) and enumerates the payload: description, family, unit, weight, supersession counts, assembly components. It does not name or contrast with siblings like get_part_history or where_used, so the agent must infer the boundary.

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?

Implies you must already have a part number, but gives no when-to-use conditions and no routing against near siblings such as get_part_history, where_used, or search_parts. Nothing tells the agent when this is the wrong choice.

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 does disclose the payload shape (dates, quantity ratios, interchangeability) and the bidirectional, depth-bounded traversal. It does not cover what happens with an unknown or non-superseded part number, whether chains can be cyclic, or what ordering the results come in.

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, front-loaded with the core action, and every clause carries information (directions, attached metadata, endpoint tool). The phrase 'which numbers replaced it… and which older numbers it replaced' is slightly redundant but not wasteful.

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 three-parameter read tool with no annotations and no output schema, the description gives a decent sketch of the returned data and chain semantics. It still leaves out error behavior, whether the queried part appears in the results, and any indication of result size or depth effects.

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 67%: lang and max_depth are documented in the schema, but part_number has no schema description at all. The prose implies part_number identifies the chain to traverse but adds no format or validity guidance, and it does not elaborate on how max_depth interacts with the two-way walk beyond what the schema already says.

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 ('Follow the supersession (replacement) chain of a part number') and makes the direction of traversal explicit (both newer replacements and older predecessors). It does not, however, contrast itself with nearby siblings such as get_part or where_used, so an agent must infer that this is the supersession tool rather than a fitment tool.

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 concept of a supersession chain, and the closing note tells the agent to use current_parts for chain endpoints. There is no explicit 'use this when…' statement, no exclusions, and no guidance on when get_part or where_used would be the better 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?

With no annotations, the description must carry the behavioral burden. It does disclose the shape of the response (field list) which compensates for the absent output schema, and explains the fitment evaluation behavior, but says nothing about result size, pagination, error behavior for an invalid table, or whether the call is a pure read.

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 with the core purpose front-loaded and the field list second. The vin sentence is slightly redundant with schema text but is short enough not to be waste.

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 10-parameter tool with no annotations and no output schema, the description covers what is returned and one fitment hint. It omits the discovery chain for catalogue/group/subgroup/sgs_code, the mvs-without-VIN path, and any guidance on variants or the only_fitting filter, leaving the agent to reconstruct workflow from the schema alone.

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 80%, so the baseline is 3. The description's note about vin fitment duplicates the schema's own vin description, and it adds nothing about the mvs fallback, lang, drive, variante, or only_fitting parameters beyond what the schema already documents.

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?

A specific verb and resource ('Get the parts list of a table (drawing)') plus an enumeration of the returned fields (reference number, part number, quantity, description, notes, option pattern, modifications). This clearly separates it from get_part (single part) and search_parts (query-based), though it never names those siblings explicitly.

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 only usage guidance is 'Pass vin to evaluate fitment for that vehicle', which explains one optional parameter rather than when to choose this tool over search_parts or get_part. Nothing states prerequisites (e.g. that sgs_code must come from list_tables) or what to do when no VIN is available.

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 behavioral load. 'List' plus optional filters makes the read-only, idempotent nature clear, but there is no statement about return volume, ordering, pagination, or whether an empty filter set returns everything — gaps that matter for a catalogue enumeration.

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

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

A single compact sentence with the core action front-loaded and the filter semantics following. No filler; the parenthetical gloss and code legend both earn their place, though the phrase 'text in the description' is ambiguous (catalogue description vs. this tool's 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?

There is no output schema, so the description is the only place the return shape could be characterized — yet it never says what a catalogue record contains (code, name, model years?) or how many typically come back. For a simple two-parameter lookup this is adequate but leaves the agent guessing about the response.

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%, so the baseline would be 3, but the description adds genuine value beyond the schema: it decodes the sub-make enum (F=Fiat, T=Fiat Commercial, L=Lancia, R=Alfa Romeo, C=Abarth), which the schema lists only as bare codes. It also reinforces that the two filters are combinable ('and/or').

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 ('List catalogues') and immediately glosses the domain term as '(model ranges)', which an agent can't infer from the name alone. It does not explicitly differentiate itself from near-neighbour siblings like list_groups or list_subgroups, 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?

Usage is only implied: 'Filter by sub-make ... and/or text in the description' tells the agent the filters are optional and combinable, but says nothing about when to choose this tool over list_groups/list_subgroups or what happens when both filters are omitted (presumably a full listing, but that is 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 disclosure burden. While 'List' implies a read-only operation, the description does not state whether the result is paginated, requires specific permissions, or has any other behavioral constraints, leaving meaningful gaps for an unannotated tool.

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

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

The description is a single efficient sentence with the core purpose front-loaded. The parenthetical examples add useful concreteness without any wasted wording.

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

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

For a simple two-parameter list tool with no output schema and no annotations, the description is minimally adequate: it states what is listed and gives examples. However, it omits return-shape context, pagination behavior, and differentiation from the closely related list_subgroups 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 coverage is 100%, and both parameters are fully documented in the input schema, including the catalogue code and language fallback. The description adds only the examples of groups, not additional parameter semantics, so baseline 3 is appropriate.

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

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

The description gives a clear verb and resource: it lists the main groups of a catalogue, and parenthetical examples (engine, brakes, body) make the content concrete. It does not explicitly distinguish itself from the sibling tool list_subgroups, but the core operation 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 states what the tool does but gives no guidance on when to use it versus alternatives such as list_subgroups, list_tables, or list_catalogues. There are no prerequisites, exclusions, or routing cues beyond the implicit meaning of 'main groups'.

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 behavioral burden, but the tool is a zero-parameter read-only lookup, so the risk surface is small. It does not state that no filtering/pagination exists or what the result set looks like, which would have been cheap and useful 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?

One short sentence, front-loaded with the verb and resource, with zero filler. Nothing is padded or buried.

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 leaves the return shape (language codes vs. human-readable names) and whether the list is static or catalogue-scoped implicit. For a trivial lookup this is tolerable, but it is not complete.

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

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

The input schema defines zero parameters, so there is nothing for the description to disambiguate — baseline 4 applies. Mentioning the 'catalogue' scope is a small bonus that clarifies which universe of languages is returned.

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 ('List') and resource ('languages') scoped to 'the catalogue', which is clear enough to distinguish it from list_catalogues, list_tables, and the other list_* siblings. It stops short of explicitly naming a sibling it is not, so it lands at 4 rather than 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?

Use is only implied — an agent can infer this is the lookup to call when a language code/name is needed for other queries, but the description never says when to use it, what alternative to prefer, or any prerequisite. Adequate minimum with clear gaps.

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, yet it says nothing about read-only safety, whether results are recursive or single-level, pagination, or what happens for a leaf group. Only the bare operation is 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?

A single, front-loaded sentence with no filler. It is efficient, though the terseness borders on under-specification rather than crispness.

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 hierarchy-listing tool with no annotations and no output schema, the description should at least clarify nesting depth and result shape. As written, an agent cannot tell whether subgroups are returned flat or as a tree, or how to continue traversal.

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%, so the schema already documents the catalogue and lang parameters reasonably well. The description adds no parameter meaning beyond that, and the required 'group' parameter has no description at all in either place.

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 ('List the subgroups of a group in a catalogue'), so an agent knows exactly what the tool returns. However, it never distinguishes itself from the sibling list_groups or explains how the two relate in the hierarchy.

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 mention of when to prefer list_groups or list_tables, and no stated prerequisites such as needing a catalogue code first. The agent must infer the hierarchy traversal from the name alone.

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 discloses that results include applicability and that vin adds fit information, but it omits read-only confirmation, pagination, error behavior, and output 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?

Two short sentences with no wasted words. The primary action is front-loaded, and the vin hint follows immediately.

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

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

The tool has 7 parameters, no annotations, and no output schema, yet the description does not explain the result structure or the hierarchy of catalogue/group/subgroup. It is minimally callable but leaves significant gaps for an agent to infer.

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 71%, so the schema already documents most parameters well. The description only reiterates the vin behavior without adding syntax, constraints, or meaning for catalogue, group, and subgroup beyond what the schema shows.

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: list the parts tables (drawings) of a subgroup, with applicability. This clearly distinguishes it from get_table_parts, but does not explicitly contrast with list_subgroups or list_groups.

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

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

The description implies usage context by explaining that passing vin shows which tables fit the vehicle. However, it does not state when to use this tool versus list_subgroups, get_table_parts, or other siblings.

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

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

With no annotations, the description carries the behavioral burden and does well: all words must match, Japanese/English handling, terse katakana naming pitfalls, fallback strategy, VIN-driven catalogue selection, and fitment sorting. It omits pagination/limit behavior and result size, but discloses the traits that most affect correct invocation.

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 behavior and query modes are front-loaded, and the fallback advice is placed immediately after the primary matching rule. It is dense but contains little waste, though the katakana example could be 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?

For an eight-parameter search tool with no annotations and no output schema, the description covers query semantics, language pitfalls, fallback behavior, VIN effects, and sorting. Missing pagination and limit semantics are minor given the high schema coverage.

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 already 88%, so the baseline is 3, but the description adds meaningful semantics for the two most important inputs: query matching rules and VIN-driven catalogue selection plus fitment sorting. Other parameters such as limit, group, drive, and lang are left to 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 and resource (search a catalogue for parts) and names the two supported query modes: description words or part number prefix. It is clearly distinguishable from siblings like get_part, get_table_parts, and list_groups.

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 a concrete recovery path when nothing matches (shorter word, English, or browse groups), and explains that supplying a VIN changes catalogue resolution and result ordering. It does not explicitly contrast with get_table_parts or state hard exclusions, so it falls short of a full when/when-not routing guide.

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. 'List' implies a read operation, but the description does not disclose permissions, pagination behavior, result ordering, or whether results are limited by default.

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

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

A single efficient sentence that front-loads the core action and result. It has no wasted text, though it could be structured with a brief usage note.

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 four-parameter lookup tool with no annotations and no output schema, the description is too thin. It does not explain result shape, pagination, catalogue filtering, or language fallback 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 only 25%, and the description adds meaning only for part_number. The catalogue, limit, and lang parameters are undocumented in both schema and description, leaving important filtering and localization behavior unclear.

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: lists catalogue tables and assemblies/kits where a part number is used. It is clear what the tool returns, though it does not explicitly differentiate itself from siblings such as get_table_parts or get_part.

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 any prerequisites or exclusions. The purpose implies a reverse-lookup use case, but the agent must infer that without explicit routing.

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