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

Annotations already declare readOnlyHint and openWorldHint, so the description is not burdened with basic safety disclosure. It adds useful behavior: returns competitor medians and concrete recommendations, and requires no token. It does not mention rate limits or data freshness, but the read-only annotation lowers that need.

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: purpose, compared attributes, result type, and auth requirement are each covered in short clauses. No filler or repetition of the 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?

For a read-only audit tool with no output schema, it covers input, comparison scope, output (medians + recommendations), and access requirements. It does not state what happens when the competitors array is empty, but that is a minor gap given the schema default and examples.

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 both article and competitors are already documented in the schema. The description does not add parameter-level meaning beyond what the schema provides, so the 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?

Description states a specific action — checks a WB product card and compares it with competitors — and lists concrete comparison dimensions (photo, video, rich content, description length, price, rating, etc.). This clearly distinguishes it from sibling tools like wb_product or wb_compare by emphasizing competitive benchmarking and improvement recommendations.

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 context is clear: use this to audit a card against competitors. It also adds a practical access condition ('Работает без токена'). It does not explicitly name alternatives or say when not to use it, so it falls short of a 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 readOnlyHint and openWorldHint, but the description adds valuable context: it works without a token, saving the agent from auth setup. It also discloses the behavior of highlighting leaders per metric. This goes beyond the annotations without contradicting them.

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, no fluff. The first sentence front-loads the verb and purpose, lists the compared fields, and states the leader-marking behavior; the second adds the auth-free trait. Every word 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 no output schema, the description should clarify what the response looks like or how 'leaders' are presented. It does not. It also omits potential limitations (e.g., max 20 items) but those are in the schema. For a comparison tool, this is a noticeable gap, though annotations and the simple parameter list keep it manageable.

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 description does not explicitly describe the 'articles' parameter, and schema description coverage is 0%. However, the input schema itself provides a good description for articles (Wildberries nmId), and the tool description explains that these products are compared, giving purpose to the parameter. It compensates partially but does not add format or constraint details 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 opens with a specific verb 'compares' and the resource 'several Wildberries products', listing concrete metrics (price, discount, rating, reviews, stock, delivery time) and the unique behavior of marking leaders. This clearly distinguishes it from siblings like wb_product (single product) and wb_price_history (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 provides a clear usage scenario: comparing multiple products, such as one's own versus competitors. It does not explicitly name alternatives or give exclusion criteria, but the phrase 'several products' implicitly directs single-product queries elsewhere. This is clear context without explicit when-not-to-use 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 provide readOnlyHint and openWorldHint; the description adds useful context by stating that no token is required and by explaining the weekly scope and summary fields. It does not discuss rate limits or exact fetching behavior, but the annotation coverage lowers the bar.

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 sentences: the first front-loads the core function and output fields, and the second concisely states the no-token requirement. There is no filler, redundancy, or unnecessary detail.

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 fully documented parameter, read-only/open-world annotations, and no output schema, the description covers the essential return information (weekly history plus min/max/current/change) and authentication context. It is sufficient for correct invocation, though the exact representation of the 'graph' is left to inference.

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 the single 'article' parameter is fully documented with the nmId format and a catalog-link example. The tool description adds no parameter-level meaning beyond what the schema already provides, so the baseline score 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?

The description clearly identifies the resource ('price history of a Wildberries product') and the output ('summary: min, max, current, change'), which distinguishes it from product-detail, review, and seller tools. It lacks a finite verb and does not explicitly name sibling tools, so it stops short of the strongest possible differentiation.

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 phrase 'Работает без токена' (works without a token) gives a clear context for when this tool is appropriate, and the 'price history + summary' wording implies the natural use case. It does not explicitly state when-not-to-use or name alternatives, so routing guidance is somewhat 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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses that no token is required and that products not on sale are excluded from the response. It also enumerates the returned data fields, adding real 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?

Two tight sentences: the first lists the returned data, the second adds auth and filtering caveats. There is no filler or repetition.

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, the description carries the burden of describing return content, and it does so with a clear field list and an important exclusion rule. For a single-parameter read-only tool this is largely complete, though explicit error or invalid-article behavior is not mentioned.

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 covers the only parameter fully with a clear explanation of nmId and a URL example. The description's 'по артикулу' just restates the schema, so it adds little beyond the 100% schema coverage.

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 exactly what the tool returns (price, discount, rating, review count, seller, stock, delivery time) for one or more Wildberries products by article. The resource and scope are clear, and the field list implicitly distinguishes it from sibling tools like wb_price_history or wb_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 description gives useful context such as 'works without a token' and notes that unavailable products are omitted, but it does not explicitly say when to choose this tool over siblings like wb_product_details or wb_compare. Usage is implied 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?

The description claims 'full description' (Полное описание) while annotations include openWorldHint=true, which indicates the result may be incomplete or non-exhaustive. This contradicts the annotation, and no other behavioral details beyond the token note are provided.

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 sentences, front-loaded with the primary purpose. It is concise and has no fluff, though it could mention the token requirement earlier.

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 read-only tool with one parameter and no output schema, the description gives a general idea of the returned data (description, characteristics, composition). However, the contradiction with openWorldHint and lack of detail on response format or pagination make it incomplete.

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 the article parameter is already documented with its meaning and source. The description adds no extra parameter semantics, but the baseline for high coverage is 3.

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 full product description, characteristics, and composition from the seller card, which is a specific verb+resource. It distinguishes from siblings like price history or reviews by the nature of the data, though it does not explicitly name 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 only usage guidance is 'works without token,' which is a prerequisite note. There is no explicit when-to-use instruction or comparison to sibling tools like wb_product or wb_reviews, so the agent must infer when this is the right 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?

Annotations already declare readOnlyHint=true, but the description adds valuable behavioral context: it works without a token, defaults to 1-3 star reviews, and specifies what it highlights (recurring phrases, negativity share, response share, fresh examples). No contradiction with annotations; the description enriches transparency beyond the structured 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 a single, well-structured paragraph that front-loads the main action and outputs. It avoids redundancy and provides relevant details (token requirement, default star range) without excessive length. It 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?

The description covers the output behavior (highlights complaints, shares, examples) and the operational prerequisite (no token needed). With no output schema, it adequately explains what the agent can expect. Minor gaps like pagination or rate limits are not mentioned, but given the simplicity and the schema's maxItems=10, it is sufficiently complete 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?

Schema description coverage is 50%, but both parameters (articles and max_stars) have clear descriptions in the schema itself. The description only mentions the default star rating ('по умолчанию 1–3★'), which is already in the schema (default: 3). It adds no additional meaning beyond the schema, so a 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 clearly states a specific action: collecting negative reviews (1-3 stars by default) across multiple Wildberries products, and lists concrete outputs (frequent complaints, negativity share, response share, fresh examples). It distinguishes itself from siblings by emphasizing multi-product aggregation and complaint analysis, making its purpose 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?

It explicitly says the tool is useful for finding weaknesses of competitors or one's own product and for improvement ideas, giving a clear 'when to use'. However, it doesn't explicitly mention when NOT to use it or name alternative tools like wb_reviews, so it lacks explicit exclusions, though the context is strong.

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 and openWorldHint, and the description adds valuable access context by stating 'Работает без токена' (works without a token). This goes beyond the structured hints and helps the agent understand authentication requirements, though it does not detail rate limits or pagination.

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 concise sentences with no fluff. The first sentence states the core deliverable, and the second adds usage value and the no-token fact, making it front-loaded and efficient.

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, the description carries the burden of explaining the return content, and it does so by naming the rating distribution, review text, pros, cons, and seller response. It also communicates the no-token requirement. It could mention sorting or exact response shape, but the provided details are sufficient for basic selection and 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?

Schema description coverage is 100%, so all three parameters (article, limit, max_stars) already have meaningful descriptions. The tool description itself does not add parameter-level detail beyond mentioning review text and ratings, which matches the schema's existing documentation. 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 clearly identifies the tool as returning a distribution of ratings plus the latest customer reviews for a Wildberries product, including text, pros, cons, and seller responses. This specific verb+resource framing distinguishes it from sibling tools like wb_product, wb_price_history, and wb_seller_feedbacks.

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 usage context: it is useful for understanding what customers praise or criticize about a product or competitor. It also adds the practical note that it works without a token, which helps an agent choose it when authentication is unavailable, though it does not explicitly name alternative tools or when not to use it.

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 this as non-read-only and non-idempotent. The description adds valuable behavioral context: the reply is published publicly, user consent is required before invocation, and a specific WB_API_TOKEN scope ('Отзывы и вопросы', not read-only) is needed. This goes beyond the structured fields without contradicting them.

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 three short sentences, each earning its place: purpose, consent requirement, and auth prerequisite. It is front-loaded with the core action and contains no redundant or filler 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?

For a simple two-parameter mutation tool, the description covers the essential operational context: what it does, the public visibility consequence, required consent, and token scope. It does not describe return values or error cases, but no output schema exists and those details are not necessary 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?

Schema description coverage is 100%, so the schema already fully documents both parameters ('id' from wb_seller_feedbacks and 'text' of the reply). The description does not add significant extra meaning about parameter formats, constraints, or relationships beyond what the schema 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 states a specific action ('Публикует ответ продавца на отзыв покупателя') with a clear resource and consequence: the reply will be publicly visible on WB. This differentiates it from sibling wb_seller_answer_question, which targets questions rather than feedback.

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 usage context: it should be used to publish a seller's reply to a customer review, and it explicitly instructs the agent to show the text to the user and get consent before calling. It does not explicitly mention alternatives or when not to use it, so it stops short of a 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 indicate a non-read-only, non-idempotent write operation. The description adds meaningful behavioral context: the answer becomes publicly visible on WB, user consent is required, and a non-read-only token is needed. There is no contradiction with 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?

Two short, purposeful sentences: the operation comes first, then the consent requirement, then the authorization prerequisite. There is no filler, no repetition of schema fields, and the important constraints are front-loaded.

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

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

For a two-parameter mutating tool, the description covers the purpose, public visibility of the outcome, the consent prerequisite, and the required auth scope. It does not describe the response or confirmation behavior, but with no output schema and a simple publish action, that is a minor gap.

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 documents 'id' well ('id вопроса из wb_seller_questions'), but 'text' has no semantic description beyond min/max length. The description mentions showing 'текст' to the user, indirectly identifying it as the answer content, but it does not explicitly map both parameters or add format guidance. At 50% schema coverage, the description only partially compensates.

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 'Публикует' and a specific resource: a seller's answer to a buyer's question. It also notes the answer is visible to all on WB, and the mention of 'вопрос покупателя' distinguishes this from the sibling wb_seller_answer_feedback.

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 a clear precondition: show the text to the user and obtain consent before calling. It also states the required token scope ('Отзывы и вопросы', not read-only). It does not explicitly name alternatives or exclusion cases, but the usage context is reasonably 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?

Annotations already mark the operation as read-only, and the description adds useful behavioral context: results default to unanswered feedback, responses include IDs for replying, and a specific token/permission is required. Nothing in the description contradicts the readOnlyHint or openWorldHint 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?

One compact sentence conveys the resource, default behavior, output hint (IDs for answers), and authentication requirement. 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?

For a simple list tool with optional parameters, the description supplies the key invocation context: auth token, default filter, and the purpose of returned IDs. Since there is no output schema, the exact return shape and pagination details are only lightly covered, but the description is adequate for basic correct use.

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 33%: only 'answered' has a schema description, while skip and take are undocumented. The description only reinforces the default unanswered behavior and does not explain pagination semantics, so it fails to compensate for the low coverage.

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 a listing tool for buyer feedback on the seller's products, including the default unanswered filter and the presence of IDs for replying. It is specific about the resource and scope, but it does not explicitly contrast with siblings like wb_reviews or wb_seller_answer_feedback, so differentiation is mostly inferred.

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 provides clear usage context: fetch seller feedback, defaulting to unanswered items, with IDs meant for later answers, and requiring WB_API_TOKEN with the relevant permission. It does not explicitly name alternatives or state when not to use this tool, such as directing answering to wb_seller_answer_feedback.

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 include readOnlyHint=true, so the description is not required to restate safety. It adds context about the token verification purpose but does not disclose potential error cases, output format details, or what happens if the token is invalid. This adds some value but leaves behavioral gaps.

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 extremely concise—two short sentences—and front-loads the primary purpose (returning seller name and ID) before the secondary purpose (token verification). No 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 zero-parameter tool with no output schema, the description adequately covers what it returns (name and ID) and why to use it (token check). It could specify the exact output format or error behavior, but given the simplicity and existing annotations, it is sufficiently 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 tool has zero parameters, so the schema fully covers parameter semantics. The description isn't required to explain parameters, and it correctly omits any. Baseline 4 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 clearly states the tool returns the seller's name and ID for the token, which is a specific verb+resource. It also differentiates from sibling tools by indicating it's for verifying the token, not for retrieving sales, stocks, or other specific data.

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 a use case (checking that the WB_API_TOKEN works) but does not explicitly contrast with alternatives or state when not to use it. It lacks clear when/when-not guidance, though the purpose is fairly self-evident.

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 and openWorldHint=true, so the description adds value beyond them by specifying the required token scope ('Статистика') and the WB API rate limit of 1 request per minute. It also outlines what output aggregates to expect (quantity, amount, cancellations, daily breakdown, top articles). 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 two sentences with the purpose front-loaded in the first sentence and operational constraints in the second. Every sentence provides essential information without filler, making it highly concise and well-structured.

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 tool with no output schema, the description covers the purpose, the returned metrics, the required authentication, and the rate limit. It does not explicitly mention default date behavior or pagination, but these are either in the schema or not critical for a summary tool. Overall, it is sufficiently complete for an agent 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% and both date parameters are already documented in the input schema with format and defaults. The description only refers to 'за период' (period) and does not add meaning beyond the schema, so it meets the baseline of 3.

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 retrieves seller orders for a period with specific metrics (quantity, sum, cancellations, daily breakdown, top articles). It names a distinct resource ('Заказы продавца') but does not explicitly differentiate from the sibling tool wb_seller_sales, so it is clear but lacks sibling differentiation.

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 for retrieving seller orders over a period and provides necessary prerequisites (WB_API_TOKEN with 'Статистика' scope) and the rate limit (1 request per minute). However, it does not explicitly say when to use this tool versus alternatives like wb_seller_sales, nor does it state when not to use it.

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 and openWorldHint=true, covering the safety profile. The description adds the crucial authentication requirement: WB_API_TOKEN with 'Цены и скидки' permission, which is beyond what annotations provide. It does not detail pagination or error behavior, but the added token context is valuable, so a 4 is appropriate.

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 concise sentences, front-loaded with the core purpose and followed by the token requirement. Every sentence serves a distinct function with no redundancy or 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?

The tool is a simple read-only list operation with pagination parameters and no output schema. The description states the data type and authentication need, but does not mention that results are paginated via limit/offset or what specific fields (e.g., price, discount) are returned. Given the presence of annotations and the simple nature of the tool, the description is adequate but leaves the agent to infer response structure.

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 0%, and the description must compensate for the two parameters (limit, offset). It does not mention either parameter or explain how pagination works. The phrase 'по артикулам' ('by articles') could mislead an agent into expecting an article filter, which is not in the schema. This is a significant omission.

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 as the seller's current prices and discounts per article, and the title reinforces this. It distinguishes from siblings like wb_price_history (historical data) and wb_seller_stocks (stocks) by focusing on current price/discount information. However, it lacks an explicit verb like 'get' or 'list', relying on a noun phrase, so it is not a perfect 5.

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

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

The description implies usage for retrieving current prices and discounts, but does not explicitly state when to use this tool versus alternatives like wb_price_history or wb_seller_sales. The token requirement is a necessary prerequisite, but not a usage condition. There is no exclusion guidance or alternative references, so it only achieves implied usage.

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 description adds the default unanswered filter and the token requirement, going beyond the readOnly and openWorld annotations. It does not describe pagination behavior or response structure, but for a read-only listing tool the added context is acceptable.

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 filler: the first states the resource, the second gives the authentication requirement and default behavior. The description is front-loaded and every 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?

The description is too sparse for confident invocation: it omits pagination semantics, return format (with no output schema), and differentiation from feedback/review siblings. The token hint and default state are helpful but not enough.

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 phrase about default unanswered provides slight semantic value for the 'answered' parameter beyond the schema default, but skip and take are completely unexplained. With 0% schema description coverage, this is insufficient compensation.

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 (buyer questions about a seller's products) and the default state (unanswered), which helps distinguish it from siblings like wb_reviews and wb_seller_feedbacks. It lacks an explicit verb such as list or get, so the action is implied rather than stated.

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?

No guidance is given on when to use this tool versus alternatives such as wb_seller_feedbacks or wb_reviews. The only additional context is the required WB_API_TOKEN scope, which is a prerequisite rather than a usage condition.

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 mark the tool as read-only and open-world, and the description adds practical constraints beyond them: the API token category and the rate limit. It does not contradict the annotations and gives the agent useful runtime expectations.

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 tool's purpose and outputs, the second covers auth and rate-limit requirements. Every phrase earns its place and there is no 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 no output schema, the description usefully enumerates the returned metrics (quantity, buyer payment, seller payout, top SKUs by revenue) and includes the operational constraints. It could mention pagination or exact response shape, but for selection and invocation the key 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 coverage is 100%, with date_from and date_to already documented including defaults and date format. The description only says 'за период' and adds no parameter semantics beyond what the schema provides, so the baseline score 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?

The description identifies the resource — seller sales and returns over a period — and lists concrete outputs (counts, buyer payments, seller payout, top SKUs by revenue). It is distinct from sibling tools like wb_seller_orders or wb_reviews, though it lacks an explicit action verb such as 'fetch' or '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?

It provides operational guidance (required WB_API_TOKEN with 'Статистика' category and a 1-request-per-minute rate limit), so an agent knows what to prepare before calling. However, it does not explicitly state when to choose this tool over the sibling tools or mention exclusion cases.

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

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

The description adds the token requirement and specifies the data categories (in transit to/from customer, ended/ending), which goes beyond the readOnlyHint annotation by disclosing a necessary access precondition. It does not contradict annotations, but it does not describe rate limits or output size, so the added behavioral context is moderate.

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, information-dense sentence that front-loads the core purpose and then states the token requirement. It is efficient with no filler, earning a high but not perfect score because it could be broken into clearer parts.

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 there is no output schema, the description gives a high-level overview of the returned data but omits structural details like pagination or the exact response format. The token requirement and data categories are covered, but the description is not fully complete for an agent to predict the tool's behavior reliably.

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 single parameter low_threshold is fully documented in the schema with a clear description, so the tool description adds no additional semantic value. Since schema coverage is 100%, the baseline of 3 applies; the description doesn't enhance understanding of the parameter.

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 uses a specific resource (seller's balances) and details the data scope (by SKU, warehouse, in transit, ended/ending), clearly distinguishing it from sibling tools like wb_seller_sales or wb_seller_orders. The high level of specificity makes the purpose 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 provides no guidance on when to choose this tool over alternatives; it only states a prerequisite (WB_API_TOKEN). Since the sibling tools cover sales, orders, feedback, etc., the agent is left to infer the appropriate context without explicit direction.

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