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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description's extra details are genuinely additive. It discloses sequential per-card requests, approximate 5-second latency, per-card error rows, and that captcha/rate limits abort the whole comparison—exactly the behavioral traits an agent needs before invoking.

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

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

The description is compact: the result shape is front-loaded, followed by two tightly written caveat sentences. Every line earns its place and there is no filler or repetition of schema content.

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

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

Given the output schema exists, the single well-documented parameter, and safety annotations, the description covers the remaining operational concerns: item limit, sequential latency, failure behavior, and abort conditions. Nothing critical is missing for a read-only comparison 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 single `products` parameter is fully documented by the schema. The description reinforces the 'up to 10' limit but adds no new parameter semantics beyond what the schema already provides.

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

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

The description clearly identifies the resource (up to 10 seller cards) and the output shape (side-by-side rows with prices, rating, seller, delivery), which makes the tool's purpose recognizable. It does not explicitly name a sibling, so it stops short of fully distinguishing itself from tools like get_product or get_offers.

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 intended use is implied: compare multiple seller cards side-by-side, and the latency/failure caveats help an agent judge whether it is appropriate. However, it never explicitly says when to prefer this over alternatives such as get_offers or get_product, so the routing guidance is left to inference.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds significant behavioral facts beyond those: the server ignores `page` and returns at most 16 offers per sort, different sorts yield overlapping but different subsets requiring dedupe, and the model group's rating can merge different products. These are non-obvious runtime behaviors an agent must know.

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: the opening sentence states the core purpose, followed by the critical limit, the workaround, and the rating caveat. Every sentence carries essential information, with no filler.

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

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

For a read-only listing tool with full annotations and an output schema, the description covers all non-obvious operational details: the 16-offer cap, the page-ignoring server behavior, dedupe guidance, rating-merge caveat, and single-request nature. Nothing critical is missing for an agent to call and interpret the 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%, so the baseline is 3. The description adds functional meaning for `sort` by explaining that each sort returns a different first-16 subset, making repeated calls with different sorts an explicit expansion strategy. It also links `sku_id` and `model_id` to 'one product,' though this is modest extra value over the schema's own descriptions.

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: 'All sellers' offers of one product (the site's «Все N предложений»), as tiles.' It clearly scopes the tool to listing offers for a single product and distinguishes it from siblings such as search_products, get_product, and compare_products by the resource it returns.

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

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

The description gives clear context for when this tool is appropriate ('offers of one product') and provides a concrete usage workaround: 'call again with another sort to see more (dedupe by offer_id).' However, it does not explicitly name alternatives or state when not to use this tool, so it falls just short of full exclusion 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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds valuable behavioral details: it notes the number of HTTP requests ('One request (three with include_seller_legal)') and warns that one of those calls hits '/api/' disallowed by robots.txt, which is critical for rate-limit and compliance awareness. This goes beyond what 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?

The description is moderately long but well-structured: a lead sentence captures the core purpose, followed by a compact list of additional features. It is front-loaded with the essential 'one seller's product card' and avoids redundancy. The style is efficient, though the bullet-like formatting (line breaks) is not perfectly concise but remains clear.

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 that an output schema exists, the description does not need to explain return values. It covers all major aspects of the product card (prices, promo, delivery, seller, rating, badges, flags, stock, characteristics, question count) and mentions the optional include flags. It also notes the interaction with get_offers. This is comprehensive enough for an agent to understand the tool's scope without guessing.

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 provides 100% parameter description coverage, so baseline is 3. The description enriches include_seller_legal by explaining the extra request cost and robots.txt issue, giving the agent a reason to set it to true/false. It does not repeat the other parameter descriptions, relying on schema clarity, which is acceptable. The added nuance justifies a 4.

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 explicitly states the tool returns 'One seller's product card' and enumerates its contents (labelled prices, promo conditions, delivery, seller). It also highlights unique aspects like the seller rating and the 'Все N предложений от X' aggregation check. This is a specific verb-resource pair that clearly distinguishes it from siblings like get_offers or get_seller.

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 references get_offers for listing offers, which is a hint about separation of concerns, but it does not explicitly state when to use this tool versus alternatives (e.g., 'use get_seller for legal entity details' or 'use get_reviews for reviews'). The usage context is implied but not fully articulated, leaving an agent to infer the boundaries.

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 tool read-only, idempotent, and non-destructive; the description adds valuable behavior: buyer names are never returned, greetings with names are masked, dates are exact, and seller answers are flagged by_seller. The phrase 'One request' adds context but is ambiguous.

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?

Three compact sentences carry meaningful information with the core resource stated first. There is no padding, though 'One request' is terse and could be more explicit.

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 a complete parameter schema and an output schema present, the description covers important behavioral quirks like privacy masking and exact dates. It lacks explicit usage guidance and leaves 'One request' open to interpretation, but is otherwise sufficient.

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 covers both parameters fully (100%), including defaults, constraints, and an example value for product. The description adds no additional parameter-level semantics; the by_seller mention concerns output rather than 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?

The description identifies the resource clearly: buyers' questions about a card, with answers as shown on the site. It distinguishes the tool from siblings like get_reviews by topic, though it does not explicitly name alternatives or use a direct verb like 'returns'.

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 this tool is for buyer questions rather than reviews or offers, but it never states when to prefer it over get_reviews or when not to use it. There is no explicit context, exclusion, or alternative 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 readOnlyHint=true, openWorldHint=true, and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral details: it clarifies that author names and order numbers are never returned, explains the header-number behavior for scope='variant', and notes that items without text are ratings only. It also states 'One request' which implies a single call fetches all results. This goes beyond the annotations and is valuable.

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 concise and front-loaded with the main purpose. The first sentence lists the returned fields, and the second paragraph adds necessary edge-case behavior. There is no redundant repetition of schema details. It is appropriately sized for the tool's complexity.

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

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

The description covers the core output contents, scope behavior, and explicit exclusions (author names/order numbers). It also mentions the single-request nature. The existence of an output schema means return-value details are not needed. It could mention pagination explicitly, but the schema's 'Page of 10' already covers that. Overall, it is sufficiently complete for a read-only tool with these annotations.

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 each parameter is documented. The description adds significant semantic value by explaining the nuances of the 'scope' parameter (e.g., how 'variant' still shows the whole card's numbers labelled) and the 'sort' parameter (e.g., 'worst' means complaints first). These clarifications are not fully captured in the schema and help the agent choose correct values.

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 it returns buyer reviews with specific fields (date, stars, pros, cons, comment, votes, photo count) and identifies the product each review is about. It is distinct from sibling tools like get_questions (questions) and get_offers (offers), so an agent can immediately understand its purpose.

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

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

The description explains the three scopes ('card', 'variant', 'model') and how they affect the results, which gives usage context. However, it does not explicitly state when to use this tool versus alternatives like get_questions or get_offers, nor does it mention any exclusions. Usage guidance is implied by the resource type but not stated outright.

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. The description adds value by revealing that the data is assembled from the seller-info popup via two POST requests to Market's /api/ and that the endpoint is disallowed in robots.txt. This is useful behavioral context, though it doesn't discuss auth or failure modes.

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 compact sentences: the first front-loads the primary output, the second adds relevant implementation detail. There is no filler or redundancy.

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

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

With one required parameter, full schema coverage, an output schema present, and safety annotations, the description supplies the additional behavioral context (request count and source) needed to understand the call. It doesn't enumerate return values, but that is unnecessary given the output schema. A small gap is the lack of explicit usage guidance, but that is already scored separately.

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%: business_id has a description identifying it as a seller id from search_products/get_product. The tool description adds no further parameter semantics, so the baseline of 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 specifies the resource (seller) and enumerates the returned components: storefront header fields (rating, ratings count, orders, years, status) and legal entity fields (name, INN, OGRN, address, cross-border flag). This clearly differentiates get_seller from siblings like get_product or get_reviews, which concern product or review data rather than seller identity.

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: an agent needs a seller's storefront rating/status or legal entity after obtaining a business_id from search_products/get_product. However, the description never states when to prefer this tool over siblings or gives exclusions, so the guidance is only implicit.

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

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

Annotations already mark it read-only, idempotent, and non-destructive. The description adds valuable behavior beyond that: real pages, site sort orders, price window, page size differences (8 vs 16 tiles), ad-heavy first page on popular sort, and the 'one request per call' constraint. This gives the agent a much richer behavioral model without contradicting 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?

The description is front-loaded with the core purpose in one clear sentence, then provides a structured list of output fields. The field list is long but each item is relevant and not redundant; overall it is efficient without being terse.

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

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

For a search tool with six parameters and an output schema, the description covers everything needed: it clarifies the search behaves like the real site, specifies the result fields, notes the one-request-per-call limit, and the schema already documents pagination and sort values. Nothing critical is missing for an agent to invoke 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%: every parameter (page, sort, price_max/min, include_sponsored, query) already has a clear description in the schema. The tool description does not add further parameter-level meaning, so the baseline of 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 opens with a specific verb-resource pair ('Search Yandex Market') and a clear scope ('like the site'), then enumerates the exact fields each item returns (ids, prices, seller, sponsored flag, etc.), making it easy to distinguish from the sibling get_product or get_offers tools.

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 clearly describes what the tool does and offers internal tips (e.g., using price_asc with price windows for depth, and noting that popular page 1 is ad-heavy), but it never explicitly contrasts this tool against siblings like get_product or get_offers. The context makes the intended use clear without formal exclusions.

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