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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it discloses what happens when articles are not returned ('listed with a reason'), and enumerates the data fields delivered. This gives the agent a realistic expectation of response completeness without needing to inspect the output schema.

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, zero filler. The first sentence front-loads the tool's capability and key output fields; the second adds an important edge-case behavior. Every word contributes to an agent's understanding.

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

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

Given the tool's moderate complexity (2 params, 1 required, output schema present), the description is complete. It states the upper bound (20), the data returned, and the fallback behavior for missing articles. The output schema covers return structure, and the city parameter is documented in the schema. There are no critical gaps that would prevent 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%, with both 'articles' and 'city' already described in the schema. The description mostly reiterates the maxItems=20 constraint and provides a list of returned fields, but does not add new meaning about parameter formats, city syntax, or article identifier types. Baseline 3 is appropriate because the schema carries the semantic burden.

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

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

The description uses a clear verb-resource structure: 'Up to 20 articles side by side in one request' immediately identifies a batch comparison tool. It lists specific output dimensions (price, discounts, promotions, stock, delivery), which distinguishes it from siblings like get_product (single product) and search_products (search). The resource and scope are 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 implies when to use it: when you need multiple articles compared in one request, with up to 20. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an agent to select it over get_product for batch comparison tasks. Minor gap: no explicit exclusion guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering safety. The description adds behavioral nuance beyond annotations: it discloses the disambiguation rule for duplicate town names (appending ', <region>') and that results are intended for use as the `city` parameter elsewhere. This is meaningful added context, though it doesn't discuss pagination or result volume.

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 with no filler: the first states the purpose, the second provides the essential usage follow-up. The most important information 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?

For a single-parameter lookup tool with rich annotations, an output schema, and no competing city-related siblings, the description covers everything needed: what it does, how to call it (via schema), and how to consume the result. No critical operational or usage detail 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%; the `query` parameter is fully documented in the schema ('City name or its beginning, e.g. «Березовский» or «Каменск»'). The tool description does not add significant semantic detail about the parameter beyond what the schema already states, 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 verb-resource pair: finding cities in the shop's directory by name and returning their region. It clearly distinguishes this from all siblings, which deal with products, reviews, stores, and comparisons, not city lookups.

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 second sentence explicitly instructs how to use the result: 'Use the exact name (plus ', <region>' when several towns share it) as `city` in other tools.' This tells the agent when and how to apply the tool's output, making the call context concrete.

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 goes well beyond the read-only/idempotent annotations by disclosing concrete behavioral details: delivery cost is only available at checkout, store stock separates city stores from the region, and ratings distinguish line-level rating from variant rating computed from its own reviews. It also notes promotion card rules and that every variant is returned with its own price and stock.

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 one-sentence overview 'Full live card of one article' is front-loaded, and the following detailed sentence is dense but relevant. It could be more scannable if split into bullets, but no clause is wasted.

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 annotations covering the safety profile and an output schema present, the description supplies the remaining context an agent needs: exact data categories, a stock-location nuance, a delivery-cost caveat, and a rating computation distinction. No critical operational detail appears missing.

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

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

Schema coverage is 100%, and the parameter descriptions already explain city, article, include_stores, include_variants, and include_description clearly. The description adds useful output context but does not materially improve an agent's understanding of how to populate the parameters beyond what the schema already provides.

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

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

The opening phrase 'Full live card of one article' clearly states the resource (one article) and the result (a complete live card). It doesn't explicitly contrast overlapping siblings like get_reviews or get_store_availability, but the one-article scope is enough to separate it from search_products and list_stores.

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 establishes clear context: use this tool when you need a detailed live card for a specific article, including price, stock, delivery, ratings, and characteristics. It doesn't list exclusions or directly recommend alternative tools, but the intended use case is explicit enough to guide selection.

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 read-only, idempotent, and non-destructive, and the description adds valuable behavioral details: line-scope reviews are not tied to a shade, the star split and average are computed for the chosen scope, and author names, e-mails, phones, and order numbers are never returned. These are meaningful privacy and aggregation behaviors beyond what annotations provide.

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

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

The description is compact and front-loaded, starting immediately with the returned fields, then adding aggregate behavior, scope nuance, and privacy guarantees. Every sentence contributes useful information 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?

For a read-only review-fetching tool, the description covers the returned data, aggregate statistics, scope semantics, and privacy exclusions. Pagination, sorting, limits, and required article are documented in the schema, and an output schema exists, so nothing critical is left unexplained.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds beyond this by explaining the line-scope behavior ('not tied to a shade') and how the star split/average relates to the chosen scope, which enriches the meaning of the 'scope' 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 clearly identifies the tool as a buyer-reviews retriever and enumerates the exact fields returned (date, stars, text, pros, cons, verified flag, likes, photo count, time of use). It also distinguishes the tool from siblings by mentioning the variant/line scope, making it obvious this is the review-specific tool among product search, store, and comparison 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?

The description provides clear context for when to use the tool: fetching reviews for a chosen article, with a selectable scope of 'variant' or 'line'. It does not explicitly name sibling alternatives or state when not to use it, but the context is strong enough that an agent can infer the appropriate use case.

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 convey read-only, idempotent, and non-destructive behavior. The description adds two non-obvious behaviors: the online warehouse is returned separately, and store prices may differ from the online price. That is useful context beyond the structured fields.

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

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

The description is three sentences, front-loads the core purpose, and every sentence adds information: output scope, returned per-store fields, and online/price caveats. There is no fluff.

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 lookup with two parameters, an output schema, and strong annotations, the description covers all behavioral context needed: scope (city/region/online), per-store data presence, separate online warehouse, and price discrepancy. Nothing material is missing.

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

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

Schema coverage is 100%, so the schema already documents the article format and city default. The description does not add new parameter-level details; its references to 'one article' and geographic scope are helpful but already implied by the schema and annotations.

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 leads with a concrete task, 'Where one article can be picked up today,' then defines the result: stock per store, region, and online. This clearly separates it from sibling tools like get_product (product info) and list_stores (store info without availability).

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

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

It gives clear context: use this to answer where a single article is available today, including local stores, regional stores, and online. It does not explicitly name alternatives or exclusion conditions, but the scope is obvious enough that an agent will not confuse it with the listed siblings.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds useful context beyond that: grouping by address interpretation (this city, another town, no town) and the meaning of products_in_stock as the site's catalog count rather than physical inventory.

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

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

Three compact sentences with no filler. The first sentence states the output and purpose, the second defines an important field, and the third explains grouping. Appropriate length for the tool's simplicity.

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 low-complexity, read-only list call with one optional parameter and an output schema, the description covers scope, field semantics, and grouping behavior. It could be slightly more explicit about when to use this tool over siblings, but nothing needed to invoke 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?

The input schema already fully documents the single optional city parameter, including the default and the region-suffix formatting hint. The description adds no additional parameter-level detail, 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 names the resource ('stores of the chain'), the scope ('in the city's region'), and the purpose ('ids for search in_store'). It is more than a restatement of the name, though it is phrased as a noun phrase rather than an explicit verb like '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 gives an implicit usage context ('for search in_store') and explains how stores are grouped, but it does not explicitly say when to prefer this tool over siblings like get_store_availability or search_products, 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?

Even with readOnlyHint and idempotentHint already present, the description adds substantial behavioral detail beyond the annotations: pagination at 20 tiles per page, grouping of variants, semantics of total_found counting tiles rather than items, and has_more meaning another page exists. It also discloses the per-item fields returned and the recommendation to confirm finalists with get_product. This is rich, honest behavioral disclosure.

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

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

The description is front-loaded with a clear purpose and then organized into a scannable list of return values, followed by pagination semantics and tool routing. It is longer than minimal, but each sentence carries information; however, some of the per-item return details may be redundant with the existing output schema, which keeps it from a 5.

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

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

Given 12 parameters with full schema coverage, a detailed output schema, and rich annotations, the description adds the missing contextual glue: how pages and tiles work, what total_found and has_more mean, that variants are merged, and that get_product should be used for finalist confirmation. This is complete enough for an agent to call the tool correctly without further documentation.

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

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

The schema already covers 100% of parameters with individual descriptions, so the baseline is 3. The description does not significantly add parameter-specific semantics; it refers generically to sorting, price window, and filters, which map to sort, price_min, price_max, profit_only, and other schema fields, but without new meaning. The output-focused details (total_found, has_more, per-item fields) are behavioral rather than parameter semantics, so the description earns the baseline but not more.

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 resource: 'Search the podrygka.ru catalog like the site' and immediately scopes the function to catalog search with pagination, sorting, price window, and filters. It also names a sibling tool, get_product, as the follow-up for finalizing results, which distinguishes it from other tool operations. This makes the purpose unmistakable even without inspecting the schema.

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

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

The description gives clear context: it behaves like the site's search, returns tiles with detailed product info, and explicitly says 'Confirm finalists with get_product,' which routes the agent to the right follow-up. It does not enumerate when to avoid this tool in favor of compare_products or list_stores, but the primary search role and the get_product handoff are clearly conveyed.

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