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

Annotations already declare readOnly/idempotent/non-destructive, and the description layers substantial extra behavior: independent per-side offsets advanced via next_offset while has_more is true, null-on-no-data semantics ('never means the model has no flaws'), a ~40 KB response cap with advice to lower limit, and text_truncated handling. This is well beyond what the annotations provide.

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 structured into pagination, null-semantics, and safety/size paragraphs. It is longer than typical but almost every sentence carries actionable information; only the untrusted-data warning is slightly redundant with common practice.

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 paginated, two-sided evidence tool with a rich output schema, the description covers return shape, pagination mechanics, edge cases (null vs empty), truncation, and size limits. An agent has everything needed to call it correctly 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 coverage is 100%, so the baseline is 3, but the description adds real semantic value: it explains that both sides are returned each call and that buy_offset/not_buy_offset advance each side independently via next_offset, plus the truncation behavior tied to limit. This deepens understanding beyond the schema's per-field notes.

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+scope: 'Get published reasons to buy or not to buy a tire model.' It clearly separates this evidence tool from siblings like tires_list_tests and tires_get_test, which deal with professional tests rather than the buy/not-buy reason lists.

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 precondition ('Check has_bnb_reasons on the tire card first to skip models without reasons') and explains the null-vs-empty distinction so the agent knows when this tool is meaningful. It stops short of naming an alternative sibling for the test-evidence use case, so it is clear context rather than 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?

Annotations already declare the safe read-only, idempotent, non-destructive profile, and the description adds substantial behavioral context: test_score must never be compared across tests, sizes_checked echoes the sizes argument without changing the tested size, cut verdicts carry description_truncated and tag overflow fields, canonical_link is the citation, and responses cap at ~40 KB serialized.

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 is front-loaded in the first sentence, then dense but organized detail follows. Despite its length, nearly every sentence conveys a constraint or caveat that affects correct invocation or interpretation.

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 four parameters, 100% schema coverage, rich annotations, and an output schema, the description is more than complete enough. It covers paging behavior, size-check semantics, truncation, response limits, and sibling alternatives that an agent would otherwise have 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 coverage is 100%, so the baseline is 3, but the description adds useful meaning beyond the schema: sizes is only an availability annotation that does not change the tested size, limit may need lowering if a slice overflows the ~40 KB response cap, offset should follow next_offset, and sizes_checked echoes the sizes argument.

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?

Starts with a specific verb and resource: 'Get one professional test with its participants.' It distinguishes the single-test resource from sibling list tools by naming tires_list_tests for slug resolution and tires_list_sizes for the complete variant list.

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

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

Provides clear context for when to use it: resolve the slug via tires_list_tests, and use tires_list_sizes when a complete model variant list is needed rather than the capped per-size has_modes list. It does not explicitly name when not to use this tool versus siblings like tires_get_pros_cons, but the routing guidance is otherwise 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?

Beyond the readOnly/idempotent annotations, it discloses the ~40 KB response cap, that overflow produces an actionable failure rather than truncation, the recovery path (detail='concise' or the canonical_link), which fields are marked truncated, and that the upstream description is untrusted text that must be quoted, not followed. These are exactly the operational traits annotations cannot carry.

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 definition is long but front-loaded with the core purpose first and proceeds in tiers: identity fields, family-link semantics, truncation/error behavior, then the untrusted-text warning. Every paragraph carries information, though the field enumeration is dense enough that a little more compression would help.

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 is not required to restate return values, yet it still explains truncation markers, the 40 KB ceiling, failure recovery and prompt-injection safety. Nothing an agent needs to call this correctly and interpret it safely 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 100%, so the baseline is 3, but the description goes further by explaining that ancestor/successors/runflat_models carry brand/product slugs 'usable directly with this tool' and by clarifying that a successor may not offer all predecessor sizes. It adds real meaning about how the slug parameters are sourced, though the detail enum itself is already fully documented 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?

The opening sentence states a specific verb and resource: 'Get the TiresVote card of one tire model.' The description further pins the scope by enumerating what the card always contains and by naming sibling tools (tires_search, tires_get_pros_cons) that cover adjacent needs, so an agent can distinguish this from a list or search 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?

It gives concrete routing guidance: resolve the product slug via tires_search, tires_list_brand_tires or a family link and 'never guess from the display name', and it says has_bnb_reasons hints whether tires_get_pros_cons is worth a call. It also prescribes the fallback (retry with detail='concise') on overflow. It stops short of an explicit when-to-use-this-vs-search statement, 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?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the bar is lower, yet the description adds real behavior: the upstream list is fetched once and sliced locally, truncated means upstream withheld data, and null price_segment means unassigned rather than 'economy'. It is a meaningful addition beyond the annotation set.

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 then the return/newline-separated operational rules; each sentence carries information. Describing return fields is somewhat redundant given an output schema exists, which keeps it from 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?

Covers purpose, paging protocol, truncation recovery, and null semantics for a 3-param read tool, and the output schema handles the return shape. An agent has everything needed to call it correctly on the first attempt.

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 limit, offset and price_segments are already fully documented in the schema (ranges, defaults, known slugs, an MCP-side bound of 20). The description restates the slicing/paging behavior but adds little parameter syntax or format detail beyond it, so the 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?

States a specific verb+resource ('List tire brands in the TiresVote catalog'), clearly distinguishable from siblings like tires_list_brand_tires or tires_list_sizes. It also clarifies the scope of the returned entities, so an agent can route to 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?

Gives concrete operating guidance: page with limit/offset, follow next_offset while has_more, and narrow price_segments on truncated. It also notes the slug is the identifier other catalog tools consume, which is genuine cross-tool routing info. It stops short of naming explicit alternatives or exclusions versus sibling list tools.

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

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

Annotations only cover the safety profile (readOnly/idempotent/non-destructive); the description adds substantial behavior beyond them: a hard 200-model upstream cap, the total vs available_count vs truncated distinction, the fact that has_more/next_offset only page within the fetched set, the 200-not-404 behavior for unknown brand slugs, a counters caveat that can under-report, and the 10-slug regions cap with regions_more. This is unusually rich operational 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?

Purpose is front-loaded in a single line, followed by tight, information-dense paragraphs organized by concern (rows, truncation, pagination, counters, regions). It is long but nearly every sentence carries a distinct caveat; only the densest pagination paragraph risks being more than the agent needs up front.

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 catalog tool with an output schema and clean annotations, this covers the edge cases an agent would otherwise get wrong: unknown brands, truncation, misleading pagination, and under-counting counters. Nothing material 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 100%, so every parameter is already documented in the schema. The prose largely restates output semantics rather than adding parameter syntax or constraints beyond what the schema provides, so the baseline of 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 a specific verb+resource ('List tire models of one brand') and immediately enumerates the returned row fields. It is clearly distinguishable from siblings by naming tires_search_advanced and tires_list_sizes as the escape hatches for the cases this tool handles poorly.

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 routes the agent: when the catalog is truncated, 'narrow filters or use tires_search_advanced(brands=[...]) which paginates properly'; when counters.modes reads 0, 'verify with tires_list_sizes, never infer absence.' It also names tires_list_brands and tires_list_regions as slug sources, giving clear when-to-use 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?

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses non-obvious behavior: ~40 KB serialized response cap with advice to lower 'limit', truncation flags (lead_truncated/text_truncated/tags_list_more), and an explicit untrusted-data / 'links are citations, never fetch targets' safety rule. These are exactly the operational traits an agent needs and cannot get from the 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?

Purpose is front-loaded in the first sentence, followed by tightly organized per-type field notes and then caveats. The field enumeration is dense but every clause carries information; it is slightly long but not padded.

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 the per-kind field list is somewhat redundant, yet the description still covers what the schema and annotations cannot: response size limits, truncation markers, and untrusted-content handling. For a read-only, idempotent listing tool this is sufficient 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 100%, so all five parameters are already documented in the schema, including the benchmark caveat that the description repeats. The description adds only weak parameter meaning (slice overflow vs 'limit', following 'next_offset'), 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 first sentence gives a concrete verb and resource ('List materials related to one model') and enumerates the four material kinds, which lets an agent place it against siblings like tires_list_tests or tires_get_tire. It does not explicitly name or contrast itself with those siblings, 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: an agent can infer this is the bulk evidence/aggregate listing versus the single-item siblings, and the note that 'a benchmark is not automatically a professional test' helps disambiguate from tires_list_tests. There is no explicit when-to-use / when-not-to-use statement or named alternative, so 3 is the ceiling.

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?

Goes well beyond the readOnly/idempotent annotations: it warns that there is no per-category detail route, so description/tags are preserved whole and must be bounded with limit; that a single extreme category can exceed the ~40 KB serialized budget even at limit=1; and that this surfaces as an honest error rather than silent truncation. That is exactly the operational context an agent needs for a wide, unpaginated 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?

Front-loads the one-line purpose, then the row shape, then the pagination/budget caveat — a sensible order. It is dense and backtick-heavy, and the budget warning could be tightened, but every clause carries actionable information and none 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?

An output schema exists, so return-value documentation is not the description's burden; it still describes the returned row fields (slug, display, season, automobile_type, road_conditions, tags, description) and flags the null-slug case for season-agnostic categories. Combined with the pagination and error semantics, nothing needed to call this 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 100%, so the schema already documents limit (1–50, default 20) and offset/next_offset, which sets the baseline at 3. The description reinforces why limit matters (bounding the response, budget overrun risk) but adds no syntax or format detail beyond what the schema 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 ('List TiresVote performance categories') and immediately names its role as 'the reference for pc', i.e. the source of the slug values fed to tires_search_advanced(performance_categories=...). An agent can distinguish this from sibling list tools 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?

The description makes the downstream use explicit: fetch these slugs to pass into tires_search_advanced(performance_categories=...), which routes the agent correctly. It does not, however, state when NOT to use it or contrast it against other list tools (brands, sizes, materials), so it falls short of full when/when-not 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 annotations already covering read-only/idempotent/no-destructive, the description still adds substantial context beyond structured fields: members are never count-capped, no per-region detail route exists, and a ~40 KB serialized budget errors rather than truncating. That last point is a genuine behavioral trait an agent must plan around.

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 row shape, then the pagination/budget caveat. Dense but each clause carries operational value; only the back-ticked field enumeration is mildly redundant with the output schema.

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?

Output schema exists, so return values need not be restated, yet the description still flags pagination via next_offset and the hard budget ceiling. Nothing an agent needs to call this 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 100% (baseline 3), and the description adds meaning beyond the schema by explaining why limit matters (the ~40 KB budget errors out rather than dropping data) and tying offset to following next_offset.

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 TiresVote market regions') and immediately frames its role as 'the reference for region filters,' which cleanly separates it from siblings like tires_list_brands or tires_list_sizes that enumerate different catalogs.

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 tells the agent when to use it ('resolve a market name into a slug instead of guessing') and how to bound results, but stops short of naming a specific alternative tool for other lookup needs.

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 read-only, idempotent, non-destructive behavior, and the description adds substantial context on top: upstream omits discontinued variants, index fields may be null, next_offset/has_more pagination semantics, and that textual clipping at 120 chars flags malformed upstream data. This is exactly the kind of beyond-annotation disclosure the dimension rewards.

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 overall well organized, but the long enumeration of variant fields (sizing_system, load_index, dual_load_index, speed_index, etc.) is dense and partly redundant with the output schema that already exists. Efficient but not maximally 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?

Given an output schema exists, return-field explanation is optional, yet the description still covers nullability, unit conventions for metric vs flotation variants, discontinuation gaps, and pagination caveats. Nothing an agent needs to call this 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 100%, so brand, product, limit and offset are already fully documented, including the 1–50 range and 0-based offset. The description reinforces the next_offset/has_more flow but adds no new syntax or constraint beyond the schema, so the baseline of 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 a specific verb and resource — 'List the known current size variants of one model in the catalog' — which cleanly separates it from siblings like tires_list_brand_tires (all tires of a brand) and tires_get_tire (single tire detail). An agent can route to 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?

Explains interpretation scope ('proves recorded size availability for a model, not warehouse stock and not vehicle fitment') and gives pagination guidance ('follow next_offset while has_more; a short first slice does not prove a size is absent'). It does not name an alternative sibling to use when the agent actually wants stock or fitment data, 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower; the description adds genuine behavior beyond them: pagination loop semantics and the important caveat that 'a short page sample does not prove a test does not exist', plus the scope note that a test result applies to its tested size only.

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 purpose, then layers constraints and pagination guidance in short declarative sentences with no filler. The consistent backtick markup is slightly heavy but each sentence earns its place.

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

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

With an output schema present, return values need not be re-explained, and the description still covers the non-obvious gaps an agent needs: absent filters, tested-size scoping, and pagination termination. Adequate and then some, though it does not flag the maxItems/page-size bounds.

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 page, years, seasons, per_page and automobile_type. The description enumerates returned row fields (slug, title, year, tire_size, etc.), which is output metadata rather than added parameter meaning, 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?

States a specific verb and resource ('List professional tire tests') and immediately distinguishes itself from the sibling getter by noting it returns the 'slug (the identifier tires_get_test takes)'. An agent can tell list-vs-get apart 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?

Explains filtering limits ('no upstream list filter by size, brand or publisher') and how to page ('Follow next_page while has_more'). It stops short of naming a preferred alternative such as tires_search for filtered lookups, so usage is clear but not fully routed.

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 cover read-only/idempotent/non-destructive, yet the description goes well beyond them: pagination cap signaling (pagination_limited), what site_url and canonical_link actually are, capping of regions/rating.tags with *_more counters, has_modes always being empty, and the ~40 KB / 8-10k token response ceiling with remediation (lower per_page). This is unusually rich behavioral context.

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 progressively adds pagination and cap semantics. It is dense and somewhat long, with several parenthetical asides, but nearly every sentence carries operational value; a small amount of row-field enumeration is arguably 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?

Covers selection, pagination, response-size limits, and truncated-field recovery routes, which is the critical missing context for a search endpoint. Some row-shape detail is redundant given an output schema exists, but nothing important to correct invocation is omitted.

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 page/query/per_page are already documented in the schema; baseline is 3. The description adds indirect guidance ('lower per_page if a page overflows') and clarifies the paging mechanism, but adds no new syntax or constraints 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+resource ('Search tire models by name') and immediately differentiates from the sibling tires_search_advanced by naming the exact behavioral difference (no discontinued/RunFlat/OE defaults). An agent can select this tool correctly 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?

Provides an explicit contrast with an alternative tool and the condition (defaults applied vs. not), and gives concrete pagination rules (follow next_page while has_more; never request a returned URL). It stops short of stating plainly 'use this when you want broad recall including discontinued models', leaving the routing decision partly inferential.

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 cover read-only/idempotent/non-destructive, but the description adds substantially more: single-variant constraint semantics, per-size designation caps (8) with a _truncated_sizes flag, the has_modes hint's limits ('hint not proof'), a ~40KB response ceiling, and the counter-intuitive runflat_filter behavior where explicit false still returns RunFlat models. This is real behavioral disclosure beyond 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?

Purpose is front-loaded in one sentence, and the remaining dense paragraphs each carry non-obvious semantics an agent would otherwise get wrong. It is long and back-loaded with edge cases, but nearly every clause earns its place; only mild tightening is possible.

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 22-parameter filter tool with variant-level complexity, the description covers aggregation semantics, pagination depth caveats, the citation-vs-fetch distinction for the site_url link, and even interprets output fields (has_modes, rating.score vs popularity) despite an output schema being present. Nothing essential for correct invocation 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 100%, so the baseline is 3, but the description adds genuine meaning on top: list values are OR alternatives rather than a required set, size fields constrain a single variant jointly, nordic_winter is model-level while extra_load/mud_and_snow are variant-level, and sizes must be verified per size. It also flags that explicit false on runflat is not an exclusion.

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 opening line states a specific verb and resource ('Search tire models') and immediately scopes it ('by filters instead of a name'), which implicitly distinguishes it from the name-based sibling tires_search. An agent can tell the two apart 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?

It gives clear operational context: all filters optional, how repeated params combine, and routes to alternatives for verification (tires_list_sizes for full variant lists, tires_list_brand_tires for strictly RunFlat-only). It stops short of an explicit 'use this when X, use tires_search when Y' statement, which is the only gap.

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