Server Quality Checklist

Tool Scores

• ozon_product_variantsA
  4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the read-only nature is covered. The description adds useful behavioral detail by specifying the return shape: aspects[] with variants[] containing sku, label, price, oldPrice, available, and url. It stops short of discussing pagination or data freshness, but that is less critical given 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.

  Conciseness5/5

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

  The description is three compact sentences with no filler: it states what the tool returns, gives concrete usage examples, and lists the output fields. The most important information is front-loaded.

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

  Completeness4/5

  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 provides the return structure. It also covers user-intent scenarios, making the tool reasonably complete for a simple read-only lookup. The main gap is that the sku/product parameter ambiguity and the zero-required-parameters situation are not clarified.

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

  Parameters3/5

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

  Schema description coverage is only 50%: the 'product' parameter is well documented, but 'sku' has no schema description. The description's statement that each variant has its own sku and price provides a useful semantic hint, but it does not clarify the relationship between the two parameters or why neither is required.

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

  Purpose4/5

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

  The description clearly identifies the resource (product configuration options) and what it returns (variants each with their own sku, price, availability, etc.). It is distinct from a simple product-details lookup, though it does not explicitly name a sibling tool for differentiation.

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

  Usage Guidelines4/5

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

  The description gives concrete trigger examples: '512GB or 1TB?', 'what colors available?', or needing a sku for a specific configuration. It provides clear usage context but does not mention when not to use the tool or explicitly compare it with alternatives among the many sibling tools.

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

• ozon_seller_catalogA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds return-field behavior ('same fields as ozon_search items plus seller info') and filter support, but doesn't disclose pagination behavior or compact/rich output effects beyond what the schema conveys.

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

  Conciseness5/5

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

  The description is compact and front-loaded: purpose, usage condition, and return/filter capabilities each get one sentence. No sentence is redundant or wasted.

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

  Completeness4/5

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

  For a read-only listing tool, the description provides the core purpose, use condition, return-field relationship, and filter capabilities. It lacks an explicit output schema and relies on knowledge of ozon_search fields, but the annotations and input schema cover safety and required parameters well.

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

  Parameters3/5

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

  With only 43% schema description coverage, the description partly compensates by mentioning 'sort and price filters', which maps to the sort, priceMin, and priceMax parameters. However, it doesn't explain limit semantics or the compact/rich distinction, leaving some parameter meaning to the schema and parameter names.

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

  Purpose5/5

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

  The description names a specific resource ('seller's shop page') and the action ('product listing', 'what else this shop sells'). It differentiates from siblings by noting it returns the same fields as ozon_search items plus seller info, making the tool's scope and output relation clear.

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

  Usage Guidelines4/5

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

  It gives an explicit triggering condition: 'Use when user wants to see what else this shop sells.' This provides clear context for when to select this tool, though it doesn't explicitly name alternatives or 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.

• ozon_brand_catalogA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds useful behavioral detail beyond annotations: plain brand names are resolved through Ozon search, ads are filtered from results, and filters{} are supported. This gives the agent a clearer model of what happens during invocation.

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

  Conciseness5/5

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

  The description is three short sentences with no filler. Key facts are front-loaded: what the tool is, what inputs it accepts, and what output behavior to expect. Every sentence earns its place.

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

  Completeness3/5

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

  With no output schema and eight parameters including nested filters, the description is somewhat thin. It tells the agent what is returned ('brand products') but not the shape, default limits, or how compact/rich modes affect the response. The brand input resolution is well covered, but the overall calling context is not fully complete for a tool of this complexity.

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

  Parameters3/5

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

  Schema description coverage is 50%, and the description compensates only partially. It adds meaningful semantics for the brand parameter by showing accepted formats (name, slug-id, URL) and the search-resolution behavior. It also mentions filters{}, but it does not clarify sort, limit, priceMin, priceMax, or rich/compact beyond what the schema already states, leaving some parameters under-explained.

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

  Purpose5/5

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

  The description uses a specific verb-resource pairing: browse an official brand storefront on Ozon. It clearly identifies the target resource as brand-specific, distinguishing it from category browsing, seller catalogs, and general search. The accepted input forms and the note about ads being filtered out add further specificity.

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

  Usage Guidelines4/5

  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 this tool: when the agent needs products from an official Ozon brand storefront. It explains the accepted brand identifiers and that plain names are resolved via Ozon search, which gives practical invocation guidance. It does not explicitly exclude sibling tools, but the brand-storefront framing sufficiently implies the appropriate scope.

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

• ozon_related_productsA
  4.1/5.0
  Behavior4/5

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

  The annotations already cover read-only, idempotent, and open-world hints, and the description adds useful behavioral context beyond those: the data comes from the product page's cross-sell block and is returned in the same format as ozon_search. This is meaningful disclosure for a read-only tool, though it does not describe pagination or error behavior.

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

  Conciseness5/5

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

  Three sentences, each earning its place: what the block is, when to use it, and what format the response follows. The description is front-loaded with the core concept and has no filler.

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

  Completeness3/5

  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 and 5 parameters, the description gives the key use case and return-format hint, but it does not clarify which parameter is semantically required — required parameters are marked as 0, yet the tool clearly needs a product identifier. There is also no information about how 'same format as ozon_search' resolves if the agent is unfamiliar with that tool. This leaves meaningful gaps for an agent invoking the tool.

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

  Parameters3/5

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

  Schema description coverage is 60%, so the schema already documents product, rich, and compact. The description adds little parameter-level meaning: it implies the 'product' identifier is central ('with this product') and references the ozon_search return format, but it does not clarify the relationship between 'sku' and 'product', nor explain 'limit' or default behavior. This is adequate but not exceptional.

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

  Purpose5/5

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

  The description states a specific verb and resource: it returns the cross-sell block from a product page, covering 'Покупают вместе', accessories, and similar items. It also specifies the return format (same as ozon_search), which helps distinguish it from product details, offers, and variants. This makes the tool's purpose immediately clear to an agent.

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

  Usage Guidelines4/5

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

  The description clearly says 'Use when user asks what to buy with this product or wants alternatives,' which is explicit when-to-use guidance. It does not mention when not to use it or name alternative tools for specific cases, but the usage context is specific enough for most agent decisions.

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

• ozon_product_questionsA
  4.2/5.0
  Behavior4/5

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

  Annotations carry the safety profile (readOnlyHint, idempotentHint, openWorldHint), lowering the burden on the description. The description adds genuine behavioral context beyond annotations by disclosing return contents (question text, author, date, answers from seller or buyers) and the identifier requirement (sku or URL). Pagination and error behavior are not disclosed, but that is a minor gap for a read-only tool with a limit parameter already documented in the schema.

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

  Conciseness5/5

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

  Four short sentences, tightly front-loaded: core purpose leads, use cases follow, then return format and input requirement. Every sentence earns its place and none repeats what annotations or the schema already state. This is an exemplary size and order for a low-complexity tool.

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

  Completeness4/5

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

  For a 3-parameter tool with no output schema, the description covers purpose, when-to-use context, return fields, and input requirements — reasonably complete. The residual gaps are the unclear sku-versus-product parameter relationship and the absence of behavior on invalid identifiers, both of which matter for an agent invoking the tool correctly.

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

  Parameters3/5

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

  Schema description coverage is 67% (limit and product documented; sku bare). The tool description adds marginal value with 'Requires product sku or URL', but it does not resolve the ambiguity between the sku and product parameters — product's schema description already accepts numeric SKU, URL, or slug, so an agent cannot tell which parameter to populate or whether they are alternatives. The schema carries most of the burden, warranting the baseline 3.

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

  Purpose5/5

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

  States a clear verb+resource: 'Questions and answers on the product page' — fetching product Q&A content distinct from other catalog data. It explicitly carves out '(not reviews)', distinguishing it from the closely related sibling ozon_product_reviews, and enumerates the content scope (compatibility, package contents, warranty, regional versions, setup tips). This is specific enough that an agent can separate it from all 18 siblings without opening schemas.

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

  Usage Guidelines4/5

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

  Gives explicit when-to-use conditions: 'Use for compatibility, package contents, warranty, regional versions, setup tips — things buyers ask before purchase.' It also provides a when-not via '(not reviews)'. However, it never names the alternative sibling (ozon_product_reviews) for the reviews case, so the routing instruction stops just short of fully explicit.

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

• ozon_products_batchA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare read-only and idempotent behavior. The description adds useful behavioral context: imageDataUri auto-disables above 24 SKUs and large batches can bloat context. The reload note is ancillary operational guidance but does not conflict 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.

  Conciseness4/5

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

  The description is three sentences, front-loaded with the core purpose followed by two targeted caveats. The 'Reload MCP after upgrades' note is mildly tangential for tool selection, but the overall description remains tight and readable.

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

  Completeness3/5

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

  The description covers batching limits, imageDataUri caps, and context-cost concerns, which is strong. However, with no output schema, it never specifies the shape of a 'product card' or how compact vs rich output differs, leaving some ambiguity for an agent invoking a six-parameter tool.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds value by linking the payload to nutrition and imageDataUri, and by clarifying that imageDataUri is auto-disabled above 24 products — a behavior stated more explicitly than the schema's 'capped' wording.

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

  Purpose5/5

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

  The description opens with 'Fetch 1–40 product cards in one call,' naming a specific verb, resource, and batch scope. This clearly distinguishes it from the singular ozon_product_details sibling, and the mention of nutrition and imageDataUri reinforces the card-fetching purpose.

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

  Usage Guidelines4/5

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

  It states when to use the tool (batching 1–40 product cards) and gives an explicit when-not: for huge canvases, prefer a Docker script over stuffing MCP context. However, it does not explicitly route single-card requests to the ozon_product_details sibling, so the alternative guidance is not fully complete.

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

• ozon_seller_infoA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so safety is covered. The description adds value by disclosing the exact output shape, badge-derived counts like '20,6 K заказов', and a caveat about rating richness. This goes beyond what annotations alone provide.

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

  Conciseness5/5

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

  The description is front-loaded with purpose, then use cases, then a compact output list, and finally a relevant caveat. Every sentence earns its place and there is no filler or repetition of schema details.

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

  Completeness4/5

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

  With no output schema, the description correctly takes responsibility for listing return values and does so in useful detail. It also covers the main use case and a known data-quality limitation. Minor gaps like error behavior are not critical for a read-only profile lookup tool.

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

  Parameters3/5

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

  Schema coverage is 100%, with the seller parameter already documented as a slug, numeric id, or URL. The description does not add any further parameter-level meaning, but it does not need to because the schema already fully explains accepted input formats.

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

  Purpose5/5

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

  The description names a specific resource ('Shop profile for a seller') and ties it to a concrete purpose: trust checks before buying from an unknown shop. It also enumerates the returned fields, making it unmistakable what the tool does and how it differs from sibling tools like product details or seller catalog.

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

  Usage Guidelines4/5

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

  The description explicitly states when to use it: when the user asks 'is this seller trustworthy?' or before buying from an unknown shop. It also gives a useful limitation—'Product-card seller.rating is often richer than this page'—which steers agents toward richer data when available, though it does not name the exact sibling tool to use instead.

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

• ozon_product_offersA
  4.3/5.0
  Behavior5/5

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

  Beyond the readOnly/idempotent/openWorld annotations, the description discloses key behaviors: includeCurrent=true prepends the current card's seller with isCurrentListing=true, delivery comes from the product page rather than only /otherOffers, advantages[] contains all badges, and delivery dates depend on city/address state. This gives the agent a realistic model of what the call will produce and what side effects location settings have.

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

  Conciseness5/5

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

  The description is compact and front-loaded: the core purpose appears in the first sentence, followed by dense behavioral details that earn their place. There is no filler or repetition of schema text — every sentence adds distinct information.

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

  Completeness4/5

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

  For a 7-parameter tool without an output schema, the description covers the essential behavior including row fields, default inclusion of the current seller, and the location prerequisite. Minor gaps remain, such as an explicit return-shape overview or sorting/limit implications, but these are largely covered by the schema defaults and descriptions.

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

  Parameters4/5

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

  Schema coverage is high at 86%, so the schema already documents most parameters. The description adds meaningful semantics for includeCurrent by explaining the default behavior and the isCurrentListing flag, which the schema does not capture. It also emphasizes that a product sku is needed, though this is slightly ambiguous given the separate product parameter accepts URLs or slugs.

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

  Purpose4/5

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

  The description clearly states the tool "Lists sellers for the product cluster" and enumerates row-level fields such as price, rating, delivery text, and badges, so an agent can see it returns seller-offer comparison data. However, it does not explicitly name or differentiate against sibling tools like ozon_product_details, ozon_product_variants, or ozon_compare_products, so the clarity relies on inferred rather than stated boundaries.

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

  Usage Guidelines4/5

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

  The description gives a concrete prerequisite workflow: "call ozon_search_cities then ozon_set_city (optionally with address for a specific PVZ area) first" because delivery dates depend on location.city / pickupAddress. It also notes that a product sku is required. It does not explicitly say when to choose this tool over alternatives or when not to use it, but the context is clear and actionable.

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

• ozon_product_specsA
  4.3/5.0
  Behavior5/5

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

  Annotations already signal read-only, open-world, and idempotent behavior. The description adds meaningful behavioral context: fieldCount varies, many cards have fewer than 8 fields, nutrition{} appears conditionally, and incomplete results should not be fabricated. This goes well beyond the annotations and prevents misuse.

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

  Conciseness5/5

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

  The description is dense but every sentence carries useful information: what the tool returns, variability, conditional nutrition data, incomplete-data behavior, and sibling comparison. It is front-loaded with the core purpose and wastes no words.

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

  Completeness4/5

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

  Given no output schema, the description does a solid job naming return details (fieldCount, nutrition{}, specsIncomplete) and warning about sparse data. It could be slightly more explicit about requiring a sku or product identifier even though the schema lists no required parameters, but overall it equips an agent to use the tool safely.

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

  Parameters2/5

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

  The description adds essentially no parameter-level meaning. The input schema already documents product with its accepted formats, but sku has no description, and schema coverage is only 50%. The description mentions 'another SKU' only incidentally and does not clarify which parameter to use or how they relate.

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

  Purpose5/5

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

  The description clearly identifies the tool as returning technical characteristics from an Ozon listing, with a specific resource (product specs) and scope. It also distinguishes itself from the sibling ozon_product_details by noting it is more complete when the seller filled the table.

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

  Usage Guidelines4/5

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

  The description gives concrete guidance: when specs are sparse/specsIncomplete=true, do not invent numbers and instead try another SKU or ozon_product_questions. It also mentions the alternative ozon_product_details and when that comparison holds. It does not exhaustively cover all sibling choices, but provides enough situational routing.

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

• ozon_category_browseA
  4.4/5.0
  Behavior5/5

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

  The description discloses a major non-obvious behavior: Ozon matches numeric id only, so a guessed slug can open a different category, and a text-prefix mismatch causes an error. This goes far beyond the readOnly/openWorld/idempotent annotations by explaining data provenance, failure modes, and the need to copy slugs from trusted sources. It also notes that filters{} behave like ozon_search, connecting behavior across tools.

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

  Conciseness5/5

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

  Four tight sentences plus one capital-letter warning carry purpose, usage, return summary, a critical caveat, and a cross-tool reference. The warning about slug provenance is front-loaded and earns its length; there is no filler or repetition. Despite 19 parameters, the prose stays compact and scannable.

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

  Completeness4/5

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

  For a 19-parameter tool with no output schema, the description gives enough context to select it correctly and avoid the main footgun (slug provenance). The compact/rich behavior and filter syntax are already described in the schema, so the description doesn't need to repeat them. The main gap is that return shape and pagination details are only implied, leaving some uncertainty about output expectations.

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

  Parameters3/5

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

  Schema coverage is only 42%, so the description must compensate. It does address the two most delicate parameters: category (exact slug, numeric-id matching, error on mismatch) and filters (same syntax as ozon_search), while also highlighting priceMax as a primary browsing axis. But 16 other parameters—sort, compact/rich, seller/delivery flags, minReviews, etc.—are left to bare names or schema descriptions, leaving a significant gap for an agent.

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

  Purpose5/5

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

  The description opens with 'Products inside a category without text search,' a specific verb+resource pair that makes the tool's function unmistakable. It contrasts with text-search tools (notably ozon_search) and names return artifacts (products, breadcrumbs, top brands). This clearly distinguishes it from the sibling tool set.

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

  Usage Guidelines4/5

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

  The description explicitly states the intended scenario: 'Use for browsing a department with priceMax/filters.' It also teaches where to source the required slug (ozon_list_categories, ozon_search_filters, or real ozon.ru link), which is a crucial prerequisite. However, it never explicitly says 'for text queries use ozon_search' or spells out when-not-to-use, relying on the phrase 'without text search' to imply the boundary.

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

• ozon_compare_productsA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare the operation is read-only, idempotent, and open-world. The description adds valuable behavioral detail beyond those annotations: default compact mode, what gets omitted (per-SKU characteristics dump and missingKeys), what full mode retains, and where extracted{} data originates. It does not fully describe the returned matrix shape, but it is sufficiently transparent for invocation.

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

  Conciseness5/5

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

  The description is three concise sentences with no filler. It front-loads the core purpose and range, then immediately explains the two output modes and the extracted{} source. Every sentence contributes actionable information.

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

  Completeness4/5

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

  Given the small parameter surface and lack of an output schema, the description does a strong job of explaining what the agent will receive: a matrix, slim or full product rows, characteristics, missingKeysByProduct, and extracted{} fields. It does not enumerate all possible output fields or edge cases, but it gives enough context for correct selection and invocation.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3. The description goes further by explaining the practical effect of compact versus rich/compact:false — slim rows to save context versus full characteristics and missingKeysByProduct — and clarifies that rich is an alias. This adds meaning beyond the raw boolean descriptions in the schema.

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

  Purpose5/5

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

  The description clearly states a specific action ('Compare') on a specific resource ('products') with an explicit count range of 2–8. The title and description together make this tool unmistakably distinct from sibling tools like search, details, or batch retrieval.

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

  Usage Guidelines4/5

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

  It conveys clear usage context: use this tool when comparing 2–8 products side-by-side, with two output modes depending on whether compactness or full detail is needed. It does not explicitly name alternatives or state when not to use it, but the comparison scope is strongly implied by the description and siblings.

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

• ozon_get_locationA
  4.5/5.0
  Behavior4/5

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

  Annotations already convey read-only, idempotent behavior. The description adds session scoping, the anonymous-session default to Москва, and the return shape, all of which are useful beyond 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.

  Conciseness5/5

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

  Three short sentences with no filler. Each sentence adds distinct value: what is returned, session behavior, usage timing, and return fields.

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

  Completeness5/5

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

  For a zero-parameter getter, the description covers the key context: what it returns, the session default, and when to call it. No missing information would prevent correct invocation.

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

  Parameters4/5

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

  The tool has zero parameters, so schema coverage is complete and there is nothing for the description to explain. The baseline of 4 is appropriate.

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

  Purpose5/5

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

  The description states a specific verb and resource: it retrieves the current delivery city/region for the browser session. It clearly distinguishes itself from sibling tools like ozon_set_city and ozon_search_cities by emphasizing retrieval of the current session value.

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

  Usage Guidelines4/5

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

  The instruction 'Use before quoting delivery dates' provides explicit timing context. It does not explicitly exclude alternatives, but for a simple getter the guidance is sufficient.

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

• ozon_search_citiesA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnly, idempotent, and openWorld, and the description adds the live dynamic behavior ('Live city lookup via Ozon maps API') and the exact return shape. This is meaningful context beyond the annotations, though no caveats about rate limits or API failures are mentioned.

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

  Conciseness5/5

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

  Three compact sentences cover behavior, trigger, query format, return shape, and next step. Every sentence earns its place and the live-vs-static distinction is front-loaded, followed by clear usage instructions.

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

  Completeness5/5

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

  Complete for a low-complexity, read-only search tool: it covers when to use, how to query, what the response contains, and what to do with the result. There is no output schema, but the return fields are listed, and the limit parameter is already documented in the schema.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds practical query semantics—'Pass first letters or full name' with concrete examples ('Каз', 'Санкт', 'Екатеринбург')—which is not present in the schema and helps the agent form correct inputs.

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

  Purpose5/5

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

  States a specific verb+resource: 'Live city lookup via Ozon maps API' and explicitly contrasts it with 'not a static list.' It also enumerates the returned fields (cities[]: label, city, region, lat, lng, uid), making the tool's function unmistakable and distinct from siblings.

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

  Usage Guidelines4/5

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

  Explicitly provides trigger conditions: 'Use when user asks about delivery to a city or you need options to choose from.' It also defines the follow-up workflow with ozon_set_city(city). It does not contrast with potential sibling alternatives like ozon_get_location, so a small gap remains.

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

• ozon_search_filtersA
  4.5/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, so the bar is lower. The description adds genuinely useful behavioral context: compact defaults to true and truncates long facet lists, category options include slug and url, and the tool excludes products. 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.

  Conciseness5/5

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

  Three compact sentences deliver the key scope, default behavior, an important parameter effect, a routing alternative, and an exclusion. Every sentence earns its place and the most important information is front-loaded.

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

  Completeness5/5

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

  For a read-only tool with no required parameters and no output schema, this description is complete enough to support a correct call: it states what is returned, what is not returned, how the compact parameter changes payload shape, and which sibling to use for category tree browsing.

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

  Parameters4/5

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

  Schema documentation covers all four parameters, so the baseline is 3. The description adds meaning beyond the schema by explaining what compact=true actually truncates and what kind of option data is preserved (brand/category/price fuller, category options with slug+url).

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

  Purpose5/5

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

  The description clearly identifies the resource ('filters and sort options'), states when it is relevant ('BEFORE / alongside searching'), and explicitly says it 'Does not return products,' which separates it from product-returning siblings like ozon_search. This is a specific, well-scoped purpose.

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

  Usage Guidelines4/5

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

  It names ozon_list_categories as the alternative for browsing the category tree and frames the tool's use relative to searching. It does not explicitly say to use ozon_search when products are needed, but the statement 'Does not return products' makes that boundary reasonably clear.

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

• ozon_searchA
  4.6/5.0
  Behavior5/5

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

  Beyond the readOnly/openWorld/idempotent annotations, it discloses concrete behaviors: default compact=true returns slim fields to save context, compact:false/rich:true returns full nested variants/configs/images, priceMin/priceMax are enforced client-side, and category slugs must be copied verbatim from another tool or URL. These are meaningful operational traits an agent needs to invoke the tool correctly.

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

  Conciseness5/5

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

  Every sentence earns its place: the opening states purpose, the second covers default response shape, the third describes the full-payload toggle, and the rest gives warnings, filter guidance, and next-step routing. It is dense but not bloated.

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

  Completeness5/5

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

  For a 21-parameter tool with no output schema, this description is remarkably complete. It covers default payload, full payload access, category-slug sourcing, key filters, seller-trust options, preferred limits, and downstream tool recommendations. The carefully documented schema fills in the remaining parameter details, so an agent has what it needs to select and call the tool effectively.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the baseline is 3. The description adds extra semantic value by explaining rich as an alias for compact:false, noting that priceMin/priceMax are enforced client-side, and bundling minSellerRating/minSellerOrders with withDelivery as a seller-trust pattern. It does not cover all 21 parameters, but the schema already documents those thoroughly.

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

  Purpose4/5

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

  The description frames this as the 'entry point for product discovery on ozon.ru' and enumerates the default result fields (sku, name, price, rating, reviews, brand, url), making it clear this is the product search tool. It distinguishes itself from siblings like ozon_list_categories and ozon_product_details by pointing to them as follow-ups. It stops short of stating 'searches products' with an explicit verb, so the purpose is clear but relies on context rather than direct wording.

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use and when-not-to-use guidance: 'Do NOT guess category slugs — call ozon_list_categories' and 'omit category for plain text search.' It also recommends parameter combinations for seller trust in one call and names the exact next tools (ozon_product_details, ozon_compare_products, ozon_product_offers), leaving little to inference.

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

• ozon_product_reviewsA
  4.7/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral nuance: variantOnly may return empty while the card shows pooled totals, sort values are listed, hasPhotos filters reviews, and key review fields including reviewsScope are disclosed. 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.

  Conciseness5/5

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

  A single, dense paragraph that front-loads the core purpose. Every sentence earns its place: scoping behavior, sort, hasPhotos, return fields, and fallback strategy. No filler or redundancy.

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

  Completeness5/5

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

  Although there is no output schema, the description enumerates the key review fields and explains edge-case behavior (empty variantOnly, retry strategy). Combined with 100% schema parameter descriptions, an agent has sufficient context to invoke the tool correctly.

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

  Parameters4/5

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

  Schema coverage is 100%, so baseline is 3. The description goes beyond schema by explaining the real-world meaning of variantOnly ('matches Ozon UI «Этот вариант»... may be empty while card shows pooled totals'), enumerating sort options, and providing retry logic. This adds real semantic value over the schema descriptions.

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

  Purpose5/5

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

  Description opens with 'Buyer reviews for a product SKU', a specific resource and operation. It also distinguishes itself from sibling tools by detailing variant scoping ('Default variantOnly=true matches Ozon UI «Этот вариант»') and review-specific fields like 'reviewsScope', which no other sibling covers.

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

  Usage Guidelines4/5

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

  Provides explicit parameter-level guidance: 'Pass variantOnly=false for all sibling variants on the same card' and a clear retry instruction when count=0. Context is strong, though it does not explicitly route between tool-level alternatives such as when to use product reviews vs product questions or offers.

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

• ozon_set_cityA
  4.7/5.0
  Behavior5/5

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

  Annotations only provide openWorldHint, so the description carries the behavioral burden. It discloses that this is a session-scoped mutation, that it takes ~20–40s, that it changes downstream delivery results, and it gives the response shape including requestedCity and location.

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

  Conciseness5/5

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

  Three sentences with no filler: prerequisite, parameter usage example, output shape, downstream impact, and latency are all packed efficiently. Key behavior 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.

  Completeness5/5

  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 compensates by stating the return fields. It covers the prerequisite call, parameter semantics, side effects, latency, and affected tools, making it sufficient for an agent to invoke and interpret the result correctly.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3. The description adds value by explaining how address is used to bias PVZ, providing concrete examples, and tying city/lat/lng to ozon_search_cities results, which complements the schema rather than repeating it.

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

  Purpose5/5

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

  States a specific verb and resource: 'Change delivery city for the session' plus 'picks a pickup point via Ozon map'. Clearly distinguishes from siblings like ozon_search_cities and ozon_get_location by framing it as a mutating session-level operation with downstream effects.

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

  Usage Guidelines4/5

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

  Explicitly instructs to call ozon_search_cities first to show valid options, which is strong usage guidance. Also explains how address biases PVZ selection and notes that the change affects ozon_product_details/ozon_product_offers, but stops short of naming alternatives or when-not-to-use cases.

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

• ozon_list_categoriesA
  4.8/5.0
  Behavior4/5

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

  Annotations already cover read-only, idempotent, and open-world behavior, and the description adds useful context: the data is live rather than hardcoded, and the default output is title, slug, and url. It does not mention pagination or rate limits, but the annotations lower the burden and the description materially increases transparency beyond them.

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

  Conciseness5/5

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

  Three dense sentences convey the tool's nature, return shape, invocation modes, and cross-tool usage with no filler. The most important facts are front-loaded, and every clause earns its place.

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

  Completeness5/5

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

  Given no output schema, the description covers the essential return fields and all meaningful invocation modes. The remaining parameter details are already well documented in the schema, and the cross-tool guidance closes the loop on how the result should be consumed.

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

  Parameters5/5

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

  Schema coverage is already strong at 80%, and the description adds meaning by explaining the parent parameter accepts slug, id, or title and that query returns a category facet. It also defines the no-argument default behavior, which is not obvious from the schema alone.

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

  Purpose5/5

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

  The description clearly states it lists Ozon categories with specific output fields (title, slug, url) and explicitly distinguishes itself from a hardcoded map by calling itself a live directory. It also references downstream siblings (ozon_category_browse, ozon_search), reinforcing its role as the category-source tool rather than a product-search tool.

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

  Usage Guidelines5/5

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

  The description gives explicit invocation patterns: no args returns top departments, parent returns children, query returns category facets. It also provides a clear routing instruction — copy the slug into ozon_category_browse or ozon_search.category — and warns not to invent stems, which is concrete and actionable guidance.

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

• ozon_product_detailsA
  4.8/5.0
  Behavior5/5

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

  Annotations already declare readOnly, idempotent, and openWorld behavior, and the description adds value beyond them: default compact=true, auto-loading nutrition for food-like cards, imageDataUri generating a small Data URI thumbnail, and rich mode retaining images[] URLs plus full description. This gives clear behavioral expectations for an agent.

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

  Conciseness5/5

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

  The description is dense yet compact: every clause carries meaningful information, default behavior is front-loaded, and the sibling pointer is placed at the end as a clean escape hatch. No wasted words.

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

  Completeness4/5

  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 does a good job explaining what the agent can expect from both compact and rich payloads, including nutrition and thumbnail behavior. It could still be more complete about error cases or the exact shape of response objects, but for a read-only product-details tool this is sufficient.

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

  Parameters4/5

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

  Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining what compact/rich actually change, what imageDataUri returns, and when nutrition is auto-enriched. It does not add much for imageSize or sku/product alias, but those are already well documented in the schema.

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

  Purpose5/5

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

  The description clearly states the tool returns a product card with specific fields (price, seller, location, delivery, characteristics, nutrition) and explicitly distinguishes it from the all-specs sibling by directing 'For ALL specs: ozon_product_specs.' The title and description together identify a specific verb+resource, so an agent can tell this apart from siblings.

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

  Usage Guidelines5/5

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

  The description gives explicit routing guidance: use this for product-card summaries and ozon_product_specs for all specs. It also explains when to use compact vs rich mode and when to enable imageDataUri and nutrition enrichment, which is actionable usage context.

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