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?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely new context: 'Работает без токена' (no auth token required) and it discloses the analytical output the caller receives. It does not cover rate limits or behavior for invalid articles, which keeps it at 4 rather than 5.

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 short sentences, front-loaded with the core capability, then the analytical detail, then the practical use case and the no-token note. No filler, though the selling-style phrasing ('удобно... ловить, кто демпингует') is slightly verbose.

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

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

There is no output schema, so the description correctly carries the burden of explaining return content (current price vs history, min/max/average, changes, markers) and auth requirements, which it does. Minor gaps remain around pagination/limits and what happens with invalid or unknown articles.

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%: the weeks parameter and the article item type are documented in the schema, but the articles array itself has no top-level description. The description only hints at both ('нескольких товаров', 'за последние недели') without adding format, limits, or the 20-item cap, so it adds marginal value over the schema.

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

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

States a specific verb and resource: it monitors Wildberries prices for multiple items at once, listing the exact analysis produced (current vs min/max/average, change over weeks, markers for minimum/drop/rise/sale). The phrase 'нескольких товаров сразу' implicitly distinguishes it from single-item siblings like wb_price_history, but no sibling is named explicitly.

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

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

'Удобно регулярно проверять конкурентов и ловить, кто демпингует' describes a use case (recurring competitor monitoring, catching dumping) but gives no explicit when-to-use vs alternatives and no exclusions relative to wb_price_history or wb_compare. Usage is implied rather than 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?

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?

Annotations already declare readOnlyHint and openWorldHint, so the read-only nature is covered — the description restates it. However, it adds a genuinely useful behavioral fact not present in structured fields: the call works without an authentication token, lowering the invocation barrier for the agent.

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: the returned content is listed first, then usage, then sibling routing, then the read-only/no-token note. It is dense but every clause carries information; only the explicit restatement of read-only status is arguably redundant with annotations.

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 compensates by enumerating the returned fields (name, category, seller article, description, characteristics, composition), which is enough for an agent to know what comes back. Minor gap: no mention of pagination or characteristics volume limits, but not critical for a single-article lookup.

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 sole 'article' parameter (nmId, with link format and range) is already fully documented in the schema. The description adds no syntax or format detail 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?

The description states a specific resource (текстовое содержимое карточки товара Wildberries) and enumerates exactly what it returns: название, предмет и категория, артикул продавца, полное описание, все характеристики, состав. It also distinguishes itself from siblings by naming wb_product (цена, рейтинг, остатки) and wb_reviews (отзывы) as the tools for adjacent 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?

It gives an explicit use case (изучить, как продавец описывает товар, или сравнить описания) and routes the agent away to concrete alternatives with the condition that selects them (price/rating/stock → wb_product, reviews → wb_reviews). Nothing about when to pick this over siblings 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=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, so the mutual 'Только чтение' is consistent but redundant. The description adds genuinely useful non-schema context: the required WB_API_TOKEN with category «Цены и скидки», which the agent needs before calling. No rate limits or pagination behavior disclosed.

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

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

Three sentences, front-loaded with the resource and field list, then exclusions, then auth. No filler; every sentence carries distinct routing or precondition information.

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 compensates by enumerating the returned fields, and it names the alternatives and the auth requirement. Pagination behavior beyond the schema's limit/offset is not explained, leaving a small gap for a list-fetching 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% — both limit and offset are documented inline with defaults and bounds. The description adds nothing about pagination or result ordering, 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?

Names the specific resource (своих товаров в кабинете продавца) and enumerates returned fields: артикул WB, артикул продавца, цена до скидки, скидка %, цена со скидкой. It also scopes what is excluded (без СПП и акций WB), which sharply separates it from sibling price 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?

Explicitly routes the agent elsewhere for adjacent needs: витрина и цены конкурентов смотрите в wb_product / wb_price_watch. It states the boundary condition (prices set by the seller, excluding WB promotions) so the agent can decide when this tool is the wrong choice.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds real behavioral context beyond them: the auth requirement (WB_API_TOKEN with the «Отзывы и вопросы» category), the default filter state, and the sort order. It does not mention pagination limits or rate limits, so it is good but not exhaustive.

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 tightly packed sentences with zero filler; the core purpose and return fields come first, then the default filter, then the routing and auth constraints. Every clause carries information an agent needs.

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

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

There is no output schema, but the description compensates by enumerating the returned fields. Combined with the default-filter, sort-order, auth, and sibling-routing notes, an agent has everything needed to call this read 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 skip/take/answered are already fully documented in the schema, which sets the baseline at 3. The description's statement that the default is unanswered questions restates what the schema's `answered` default/false already conveys, adding little new meaning.

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 (список вопросов покупателей о товарах продавца), enumerates the returned fields (id, дата, текст, артикул, название, ответ), and fixes the sort order (новые сверху). It clearly distinguishes itself from the sibling wb_seller_answer_question, which it names as the follow-up action.

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?

Discloses the default filter ('По умолчанию — только вопросы без ответа') and routes the agent to wb_seller_answer_question for the write path, which is explicit when-to-use guidance. It does not contrast itself against other read siblings like wb_reviews or wb_seller_feedbacks, so it falls short of full alternative coverage.

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?

Annotations already declare readOnlyHint=true, but the description adds genuinely new behavior: the required WB_API_TOKEN scope («Статистика») and the ~30-minute WB data refresh cadence. The «Только чтение» sentence merely repeats the annotation, costing it the top score.

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 resource and payload, then usage, then auth/freshness caveats — no filler sentences. Dense but still readable in one pass.

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 single-optional-param, no-nested-object read tool with no output schema, the description covers what is returned (totals, per-warehouse split, in-transit both directions, zero/low lists), the threshold semantics, auth requirements, and data freshness. Nothing an agent needs to call it 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 single low_threshold parameter 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?

States a specific verb+resource and scope: остатки своих товаров на складах WB (FBO), with the exact breakdown returned (всего штук, разбивка по складам, в пути к/от клиента) plus separate out-of-stock and low-stock lists. This clearly distinguishes it from siblings like wb_seller_sales or wb_seller_orders.

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 says when to use it: «Используйте, чтобы понять, что пора поставлять». That is a clear usage context, but it names no alternative sibling for stock-vs-sales-vs-orders questions, so routing is left partly to inference.

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