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

The description goes well beyond the annotations by disclosing the exact request pattern: one price request, one availability request, and one review-statistics request per product at approximately 2 seconds each. It also exposes the per-product result fields including the not-sold flag, prepayment flag, and whether the card merges several models. This is strong behavioral context beyond the read-only/idempotent hints.

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 compact and front-loaded with the core purpose. The second paragraph lists useful behavioral and field details without excessive elaboration. It could be slightly tighter by moving some field enumeration to the output schema, but it remains efficient 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?

Given the rich annotations, full schema coverage, and presence of an output schema, the description covers the essential operational facts: batching, latency, and returned attributes. It is slightly less complete on when to choose this tool over siblings, but for actually invoking it correctly, the needed context is present.

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

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

Schema description coverage is 100%, so the baseline is 3. The input schema already explains that products are codes, GUIDs, or URLs with a max of 24, and city is a DNS shop location or GUID. The description adds little parameter-level meaning beyond restating the 24-product limit, so it does not elevate above baseline.

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 opens with a clear verb and resource: 'Live side-by-side offers for up to 24 DNS products.' It makes the multi-product comparison intent obvious and distinguishes itself from single-item siblings like get_product or get_reviews, though it does not explicitly name those alternatives.

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 use case: compare up to 24 DNS products at once and receive aggregated pricing, availability, and review statistics. However, it never states when not to use this tool or when to prefer search_products, get_product, get_reviews, or get_price_history instead. Usage guidance is present only implicitly.

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, openWorld, and idempotent hints. The description adds valuable behavioral details: the data granularity (weekly averages), the partial week caveat for the last point, and the uncertainty about city-specificity. This goes beyond the structured hints and gives the agent realistic expectations about the data's nature and 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?

The description is two short paragraphs, front-loaded with the main purpose. Every sentence contributes either data characteristics or a caveat. There is no redundancy or filler, making it highly efficient for an agent to parse quickly.

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

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

Given the output schema already defines the return structure, the description covers all essential behavioral aspects: what the data represents, the partial week caveat, and a pointer to the current price. It is complete for a simple retrieval tool, leaving no critical information missing for correct invocation.

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

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

The schema already describes both parameters with 100% coverage, including defaults and formats. The description adds a semantic note about the `city` parameter by warning that city-specificity is unconfirmed, which informs how to interpret results by city. This is a modest but useful addition 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 clearly states the tool provides weekly average selling prices for a product, with the specific resource being the price history card on DNS. It distinguishes itself from current-price retrieval by explicitly noting the last point is not the current price and referencing `current_price_rub`, which differentiates it from sibling `get_product`.

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 guides usage by clarifying that the returned data is historical weekly averages, not the current price, and points to `current_price_rub` as the source for current price. However, it does not explicitly name an alternative sibling tool or state when to choose this tool over `get_product`, leaving some inference to the agent.

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 behavior. The description adds valuable behavioral context: the data is live, delivery cost is only known in the cart, and the three include flags each add exactly one request. This goes well beyond the structured annotations.

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

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

The purpose is front-loaded in one clear sentence, followed by a dense enumeration of returned content. The list is long but every clause contributes useful information; it is slightly unwieldy as one continuous sentence, so it does not earn 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 and annotations covering side effects, the description adds the missing context: live freshness, request-cost implications of flags, delivery-cost limitation, and the card's scope. An agent has enough information to select and invoke this tool correctly.

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

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

Schema description coverage is 100%, and each parameter already has a clear description. The tool description does not add per-parameter semantics, so the baseline of 3 is appropriate; the schema carries the parameter documentation burden.

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 opens with a precise verb and resource: 'Full, live product card for one DNS product in one city.' It lists concrete card components, which clearly distinguishes it from sibling tools like search_products, get_reviews, compare_products, and get_price_history.

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 intended context clear: use this when you need the complete live product card for a single product in a single city. It does not explicitly mention when not to use it or name alternative tools, but the scope is strong and unambiguous.

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

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds genuinely non-obvious behavior beyond those annotations: statistics are only computed on unfiltered requests, the response indicates whether the card merges several models, and reviewer names are never returned. This is exactly the kind of contextual detail an agent needs before invoking the 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 compact and front-loaded with the core output, then adds the conditional statistics behavior and a privacy caveat. There is no filler, and every sentence contributes operational value without requiring the agent to parse a long block of prose.

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

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

Given the rich input schema, output schema, and annotations, the description is complete: it covers what the reviews contain, the conditional statistics behavior, the multicard scope implication, and the reviewer-name privacy constraint. Nothing essential for an agent to call and interpret this tool is missing.

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

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

The input schema already describes all 11 parameters with high coverage (100%), so the baseline is 3. The description adds no per-parameter syntax or format details; its extra notes about unfiltered requests and scope are behavior-level observations rather than parameter semantics. The schema carries the weight here.

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 immediately identifies the resource as buyer reviews from dns-shop.ru and enumerates the concrete fields returned (date, stars, pros, cons, comment, usage period, bought variant, votes). This clearly distinguishes get_reviews from sibling tools like search_products, get_product, and compare_products, which are about product discovery and comparison rather than reviews.

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 use case is implied by the tool name and content: use this when you need buyer reviews or their statistics. However, the description never explicitly says when to use this instead of a sibling, nor does it mention any exclusions or alternative tools. The guidance is present but only by implication.

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 mark the operation read-only, idempotent, and non-destructive. The description adds substantial behavioral detail beyond that: fixed 24-item pages, conditional price estimates, merged ratings, the resolved_category behavior, total_found_in_category semantics, and the extra request cost of with_availability. No contradiction with annotations.

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

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

The description is dense but every sentence earns its place: it front-loads the core search behavior, then details per-item fields, category narrowing, and the next step. The colon-list structure makes it scannable without wasted words.

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

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

For a complex 9-parameter tool, the description covers the important behaviors: result shape, category resolution, pricing nuances, stock semantics, and the follow-up tool. An output schema exists, so the description does not need to restate return types. The only minor gap is not explicitly covering all sibling alternatives, but the tool is fully usable.

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 baseline is 3. The description reinforces concepts like price window and stock filter but adds little meaning beyond what the schema already provides. It does not introduce new parameter semantics or clarify formats 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 clearly identifies the tool as a DNS product search with site-like behavior: pagination, sorting, price window, and stock filter. It also differentiates itself from get_product by stating 'Confirm finalists with get_product', so an agent can distinguish search from detail retrieval.

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 clear this is the discovery/search step and explicitly points to get_product as the follow-up for confirming finalists. It does not discuss when to prefer compare_products, get_reviews, or get_price_history, but the core usage context is unambiguous.

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