Server Quality Checklist

Tool Scores

• dns_brand_catalogB
  3.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering the safety profile. The description adds only a little behavioral context, such as the 'search fallback' role, but does not explain output shape, pagination, or the effect of compact/rich modes beyond what the schema already provides.

  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 very short and free of filler, and the core point is front-loaded. It is slightly too terse, almost a noun phrase rather than a complete sentence, but it earns its place without redundancy.

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

  Completeness2/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 should explain more about what the returned products look like, especially since the tool supports compact/rich payloads, sorting, and pagination. The current one-liner leaves the agent inferring response structure and behavior from parameter names and hints.

  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?

  Schema description coverage is 50%, and the description does not compensate for the undocumented parameters (page, sort, limit). It only repeats the notion of a brand name, which the schema already documents with examples. No additional meaning is added to the parameter list.

  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 (products for a brand) and the action (browse/list), which is distinct from search or related-product tools. The parenthetical 'brand page or search fallback' adds context but does not explicitly contrast it with sibling tools like dns_search or dns_related_products.

  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 phrase 'brand page or search fallback' gives clear context for when this tool is appropriate: browsing a specific brand's products or as a fallback after a search. However, it does not explicitly state when not to use it or name an alternative, such as using dns_search for non-brand-specific queries.

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

• dns_related_productsB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare the tool read-only, idempotent, and open-world, so the behavioral burden is lower. The description adds the concrete scope (analog vs accessories) but does not describe response shape, pagination, data source behavior, or other runtime traits.

  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 short and front-loaded: it states the resource type, gives endpoint paths, and lists allowed kind values in two sentences. The unlabeled `kind=` syntax and use of the jargon term 'analog' keep it from being perfectly clear.

  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?

  This is adequate for a simple, read-only, parameterless tool, and it names what the tool returns. However, it does not explain how the product is identified, what the response contains beyond 'analogs or accessories', or how to choose between analog and accessories given the empty schema.

  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?

  The input schema has zero properties, so no parameter burden normally exists. The description introduces an implicit `kind=analog|accessories` constraint that is absent from the schema; this is informative but inconsistent with the declared empty parameter list, preventing a higher score.

  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 names a specific resource type ('analogs or accessories for a product') and gives endpoint paths plus allowed `kind` values, making the tool's scope clear. It does not explicitly contrast with sibling product tools, but the wording is specific enough that an agent can distinguish it from details, variants, or specs.

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

  Usage Guidelines3/5

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

  The intended use is implied: call this tool when you need analog or accessory products instead of full details or specs. However, there is no explicit when-not-to-use guidance or comparison with sibling tools such as dns_product_variants or dns_product_details.

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

• dns_product_specsA
  3.5/5.0
  Behavior4/5

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

  Annotations already declare read-only, idempotent, and open-world behavior. The description adds valuable behavioral rules: do not fabricate values when parser_drift or sparse, and compact output is default. This goes beyond the structured hints and is consistent with 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 terse sentences, with the core resource first, followed by the two operational caveats. No filler or restatement. The structure is efficient and scannable.

  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 the data source and important caveats, but it does not explain how the product id is provided given the empty schema, nor what the returned technical characteristics contain. There is no output schema to fill that gap and no usage guidance to disambiguate from sibling tools. For a no-parameter read tool, the lack of product-selection context is a meaningful hole.

  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 zero parameters in the schema, the description has little formal parameter burden, but it references an {id} in the path and a compact default that do not appear in the input schema. This can confuse an agent about whether to supply an id or a compact flag. The description still conveys the endpoint and default behavior, so it is not entirely unhelpful.

  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 as technical characteristics served from /product/characteristics/{id}/, and the title supplies the 'get' verb. It does not explicitly contrast with siblings like dns_product_details or dns_product_variants, but the endpoint and 'specifications' scope make the purpose unambiguous.

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

  Usage Guidelines2/5

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

  The description gives no guidance on when to prefer this tool over the many sibling tools. The only conditional ('When parser_drift or sparse') is a data-quality caveat, not a usage selector. This leaves an agent to infer the appropriate context from the name alone.

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

• dns_product_variantsA
  3.7/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 safety profile is covered. The description adds useful behavioral detail beyond the annotations: each variant has its own 16-hex id and the default response shape is compact=true. This gives the agent extra context about the data and output style without contradicting any annotation.

  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 two short sentences with no filler. The core meaning is front-loaded ('Configuration options on the product card'), and each sentence adds distinct information: examples, id format, and default response behavior.

  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 zero-parameter, read-only tool with annotations and no output schema, the description is largely sufficient: it identifies the resource, gives examples, and notes an important default. The main missing piece is clarifying what 'compact=true' means and how the product card context is established, but this is a minor gap given the simplicity and sibling context.

  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 the input schema is trivially complete and the baseline for parameter semantics is 4. The description adds a minor bonus by mentioning 'Default compact=true,' though this is not formally tied to a schema property since there are no parameters.

  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 title supplies the active verb ('Get') and the description names the resource: 'Configuration options on the product card' with concrete examples like color and memory. This is clearly distinct from sibling tools about reviews, specs, availability, or search, though the description itself is phrased as a noun phrase rather than an explicit action statement.

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

  Usage Guidelines2/5

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

  There is no explicit guidance about when to use this tool or when to prefer a sibling such as dns_product_details, dns_product_specs, or dns_compare_products. The description implies it is for variant configuration lookups, but it never states conditions, exclusions, or alternatives, leaving the agent to infer usage context.

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

• dns_category_browseA
  4/5.0
  Behavior4/5

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

  Annotations already mark the operation as read-only, idempotent, and open-world. The description adds useful behavioral details beyond that: slug resolution through a fallback search and category-scoped sort behavior. It does not mention every behavioral nuance such as pagination or response shape, but the annotations carry the safety profile.

  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, each earning its place: the core purpose, the slug guidance with aliases, and the category-scoped sort warning. The most important information is front-loaded, with no filler or redundancy.

  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 category browsing tool with no output schema, the description supplies the essential invocation context: how to reference a category correctly, that aliases may be resolved, and that sort is scoped to the category. It leans on the schema for pagination and filtering fields; those are legible enough. It is not a 5 because the response payload is never characterized, leaving some uncertainty despite the compact/rich schema hints.

  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 low (38%), and the description does partially compensate by clarifying the category parameter format and the meaning of sort=price_desc within a category. However, page, limit, priceMin, and priceMax still lack meaningful semantic guidance beyond their names and schema defaults, so it does not fully cover the parameter space.

  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 opens with 'Products inside a category,' which clearly identifies the resource and scope. It references dns_list_categories for slug sourcing, making the tool's role distinct enough without an explicit comparison to every sibling. It stops short of a 5 because it does not explicitly differentiate from related browsing tools like dns_brand_catalog or dns_search.

  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 practical guidance: prefer the slug returned by dns_list_categories, know that short aliases resolve through search fallback, and understand that sort=price_desc is category-scoped. This is clear contextual usage advice, though it does not state when not to use this tool or name alternatives explicitly.

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

• dns_product_availabilityA
  4/5.0
  Behavior5/5

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

  Beyond the readOnly/openWorld/idempotent annotations, the description discloses the exact stock enum values, the fallback to city shop addresses when SKU-level lists are empty, and the effect of toggling includeStores. This is rich behavioral context that helps an agent predict responses.

  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 dense, front-loaded sentences cover purpose, when to use, return enum, fallback behavior, and an option. No filler or redundancy.

  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 tool with no declared parameters and no output schema, the description does a good job of explaining return values and fallback behavior. It loses a point because it references an includeStores parameter that is absent from the schema, leaving an agent uncertain how to actually apply that instruction.

  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 input schema declares zero parameters, yet the description says 'Set includeStores=false', implying a parameter that the schema does not expose. This is misleading for invocation because an agent cannot legitimately pass includeStores according to the schema. The 0-parameter baseline of 4 is therefore not met.

  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 reports stock/pickup availability for the current city and will return a specific stock enum, which makes its core function evident. It does not explicitly differentiate from sibling tools such as dns_product_details or dns_list_stores, though it does say to prefer it over marketplace offers.

  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 clear context: use for current-city DNS availability and prefer over marketplace offers because DNS is a single retailer. It also provides a conditional usage instruction (includeStores=false), but it does not name sibling alternatives or spell out when not to use the tool.

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

• dns_product_reviewsA
  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 safety profile is established. The description adds valuable behavioral context: it falls back to opinion page HTML and 'does not hang on product scrape', plus it names the underlying mechanism (restapi opinions). 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?

  Two concise sentences: the first front-loads purpose and payload fields, the second adds a resilience guarantee. Every word earns its place; 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?

  For a zero-parameter, read-only tool with annotations covering safety, the description provides enough: it names the data source, lists the return fields, and explains fallback behavior. Since there is no output schema, including the return fields in the description is necessary and well-handled.

  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 input schema has zero parameters, so the parameter-documentation burden is minimal and the baseline is 4. Mentioning the product GUID is helpful context even though no schema parameter exists; it clarifies what the review data is scoped to.

  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 states a specific action and resource: 'Buyer reviews via restapi opinions (product GUID)' and lists the returned fields (score, comment, pros, cons, date). It is clear and unambiguous, though it does not explicitly contrast with any sibling tool; no sibling appears to cover product reviews directly.

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

  Usage Guidelines3/5

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

  The intended use is implied by the title and description: use when buyer reviews for a product are needed. There is no explicit guidance on when to prefer this over siblings or any exclusions. The fallback note is about reliability, not routing.

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

• dns_search_citiesA
  4/5.0
  Behavior3/5

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

  Annotations already mark the tool readOnly, openWorld, and idempotent, so safety is covered. The description adds the workflow trait of returning selectable options, but does not disclose output shape or any pagination/edge behavior; with annotations present this is adequate but not rich.

  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?

  Two short sentences, front-loaded with the core purpose, with the second adding the essential follow-up action. No filler and no 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?

  For a simple read-only two-parameter lookup with no output schema, it conveys purpose, user interaction, and the next tool to call. It could specify exactly what data is returned (e.g., city IDs for dns_set_city), but the workflow is clear enough to invoke.

  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?

  The schema covers query with an example and limit with bounds/default, so the schema carries most of the meaning. The description adds no parameter-specific detail beyond calling it a city lookup; 50% coverage is not compensated, but the undocumented limit is self-explanatory.

  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 ('lookup') and resource ('city'), ties it to delivery/store region, and names the follow-up sibling dns_set_city, so it is easy to distinguish from siblings like dns_get_location or dns_list_stores.

  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 says to show options to the user and then call dns_set_city, which establishes when to invoke it in the city-selection workflow. It doesn't explicitly list exclusions or compare with alternative lookup tools, but the context is clear.

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

• dns_list_categoriesA
  4.2/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 description's safety burden is low. It adds the 'live' data-source context and the top-level/parent/query behavior, but does not disclose response shape, pagination, rate limits, or dynamic source variability beyond 'live'.

  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 clauses convey the essential invocation modes with no filler and are front-loaded with the data source. Every sentence earns its place at roughly 24 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 the low parameter complexity, strong safety annotations, and schema coverage for the remaining arguments, the description is mostly sufficient for correct invocation. The main gap is not disambiguating from dns_category_browse and leaving limit behavior implicit.

  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 description adds practical meaning beyond the schema by explaining parent=slug selects children and query=text finds related categories, and clarifies the no-args default. However, limit has no description in the schema and is not addressed in the description, leaving one parameter semantically under-documented.

  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 resource (live category directory from dns-shop.ru) and enumerates behavior per argument mode: no args returns top-level, parent returns children, query returns related categories. This clearly distinguishes its behavior from generic list tools despite the similarity to dns_category_browse.

  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 clear invocation contexts: no args for top-level, parent=slug for children, query=text for related categories. It does not explicitly mention when not to use it or compare it to the sibling dns_category_browse, so it falls short of full alternative routing.

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

• dns_list_storesA
  4.2/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 the endpoint and the session-city default behavior, but does not disclose response shape or the effects of rich/compact options. This is acceptable given the annotations, but not especially rich.

  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?

  Two short sentences with no filler. The resource and endpoint are front-loaded, and the default behavior is stated efficiently. Every sentence adds value.

  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 simple read-only list tool with four parameters and no output schema, the description covers the key facts: what is returned, the endpoint, and the default city behavior. Minor gaps remain around the response payload and behavior when no session city is set, but these are not critical for basic 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 high (75%), and the description adds meaningful semantic value beyond the schema by stating that city can be a name or slug and that omitting it defaults to the session city. The limit parameter lacks schema description, but its default is captured 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 uses a specific verb ('List') with a clear resource ('physical stores') and an explicit endpoint ('/shops/{city}/'). This clearly distinguishes it from sibling tools that focus on products, search, or location management.

  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 explains how to call the tool: pass a city name or slug, or omit it to default to the session city. It gives clear invocation context, though it does not explicitly mention when to avoid this tool or compare it to sibling alternatives.

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

• dns_search_filtersA
  4.2/5.0
  Behavior4/5

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

  Annotations already establish read-only, idempotent behavior. The description adds useful non-obvious behavior: it does not return products and requires at least one of query/category. It does not disclose response shape or error conditions, but these are not 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?

  Three tight sentences with no filler. The key scoping statement ('Does not return products') is placed early, and the usage constraint is front-loaded.

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

  Completeness2/5

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

  Despite the simple surface, the description conflicts with the empty input schema: it demands a query/category argument the schema does not declare, so an agent cannot reliably construct a valid invocation. No output schema, pagination, or error behavior is described, which further reduces completeness.

  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 input schema is empty, so the description is the only source of input semantics; mentioning 'query or category (one required)' adds meaning beyond the schema. However, it stops short of giving explicit parameter names or types, leaving some patchiness in how to actually invoke the tool.

  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 exposes available filters and sort options for a search query or category, which is a specific resource distinct from product-returning search endpoints. 'Does not return products' actively differentiates it from sibling search tools.

  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 clear context: use this for filter/sort metadata rather than products, and states that one of query or category is required. It does not explicitly name sibling alternatives, so agents must infer which sibling to use when products are needed.

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

• dns_search_multiA
  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 the safety profile is covered. The description adds meaningful behavioral context beyond annotations: a shared browser session, the SESSION_DROP risk from parallel calls, and the per-result layout (query, count, items with stock enum).

  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 tight sentences, with the most important usage guidance front-loaded. Every sentence adds value: what it does, when to use it, and what the result blocks look like.

  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?

  There is no output schema, so the description carries the burden of explaining return shape, but it only sketches 'query, count, items with stock enum'. Given 9 parameters and low schema coverage, an agent would benefit from more detail about filtering, sorting, pagination, and item fields before confidently using the full capability.

  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?

  Schema description coverage is only 44%, and the description does not compensate for the undocumented parameters (page, sort, inStock, priceMax, priceMin). It mentions the 1–10 query range but provides no additional semantics for the filtering, sorting, or pagination parameters.

  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 action ('run 1–10 search queries in one call') and resource ('DNS product search'), and differentiates it from the single-query sibling dns_search by emphasizing batch behavior. The title and first sentence together leave no ambiguity about what this tool does.

  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?

  Explicitly states when it is preferred ('PC builds / price scans') and why it beats the alternative ('Avoids parallel dns_search bursts that cause SESSION_DROP'). This gives the agent concrete routing guidance and names the sibling it protects against.

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

• dns_compare_productsA
  4.4/5.0
  Behavior4/5

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

  Annotations already cover read-only, open-world, and idempotence. The description adds useful behavioral context beyond that: the output is a comparison matrix with slim rows, and prices depend on the session city. No contradictions 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.

  Conciseness5/5

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

  Three short, information-dense sentences. The core action and scope are front-loaded, and the alternative-tool guidance and price behavior are each given their own concise sentence with no filler.

  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 annotations already declare safety and idempotence, and the schema fully documents parameters, the description covers the essential remaining context: output shape, product count, preference over a sibling, and session-city-dependent pricing. It is sufficient for correct invocation.

  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 100%, so the schema already fully documents 'products', 'compact', and 'rich'. The description adds little beyond restating the 2–8 product constraint, which is acceptable since the schema carries the parameter semantics.

  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 ('Compare') and a bounded resource scope ('2–8 products'), and describes the result shape ('matrix of shared characteristics + slim product rows'). It is clearly distinguishable from sibling tools like dns_product_specs and dns_product_details.

  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?

  Explicitly directs the agent to prefer this tool over running parallel dns_product_specs calls. This gives clear when-to-use guidance and names the alternative, which is exactly what an agent needs for tool selection.

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

• dns_products_batchA
  4.4/5.0
  Behavior4/5

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

  Annotations already cover read-only, open-world, and idempotent behavior. The description adds meaningful information beyond that by stating that each returned row includes location and stock, which is especially valuable given there is no output schema. It doesn't detail error behavior for invalid IDs, but the annotation coverage lowers the burden.

  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?

  Two compact sentences, front-loaded with the action and differentiator. Every clause earns its place; there is no filler or repetition.

  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?

  The description supplies the batch size, the preferred-use case, and key return fields, while the schema fully documents the parameters. It could be more explicit about partial failure behavior when one ID in a batch is invalid, but for selecting and invoking the tool it is largely complete.

  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 100%, so all three parameters are already documented. The description mostly restates the 1–40 cardinality that the schema already declares, and it adds no new parameter-level meaning beyond that.

  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 ('Fetch'), a clear resource ('product cards'), and a precise range ('1–40'). It also distinguishes itself from dns_product_details, which is the relevant sibling for single-product lookups.

  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?

  It explicitly says this tool is 'preferred over parallel dns_product_details', telling the agent when to choose the batch tool over the obvious alternative. The implication to use dns_product_details for a single product is clear.

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

• dns_set_cityA
  4.4/5.0
  Behavior5/5

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

  Beyond the sparse openWorldHint annotation, the description discloses the session/cookie side effect, the global impact on later tools, and an explicit latency range of 15–40 seconds. These behavioral details are meaningful and not derivable from the annotations or 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?

  Three short sentences deliver purpose, prerequisite, side effects, and latency with no filler. The main purpose 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.

  Completeness4/5

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

  For a state-changing tool with one required parameter and clear schema coverage, the description covers the key practical concerns: prerequisite, global effect, and timing. It does not describe what the response contains, but there is no output schema and this is a setter, so the main usage context is adequately complete.

  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?

  The input schema already fully describes all three parameters, including the city name origin and optional cityId/citySlug semantics. The description adds a prerequisite link to dns_search_cities, but does not go further in explaining parameter selection or precedence, so it sits at the baseline for high schema coverage.

  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 a specific verb and resource: 'Change city for the session'. It clearly separates this setter from sibling search/get tools by defining its stateful scope and by instructing the agent to call dns_search_cities first, which differentiates the operation from city lookup.

  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 clear prerequisite ('Call dns_search_cities first') and warns that the change 'affects prices and stock in all subsequent tools', which tells the agent when and why this tool should be invoked. It does not enumerate exclusions or alternatives, but the usage context is clear enough.

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

• dns_get_locationA
  4.5/5.0
  Behavior4/5

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

  The annotations already mark the operation read-only and idempotent; the description adds useful behavioral context: the value comes from the current_path cookie, anonymous sessions default to Moscow, and the result influences prices and availability. 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.

  Conciseness5/5

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

  Three short sentences with the main fact front-loaded, followed by the source, default, and practical impact. Every clause earns its place and there is no filler.

  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 with no output schema, the description is complete: it states what is returned, where it comes from, what happens for anonymous users, and why the value matters. An agent has enough information to invoke it correctly and interpret the result.

  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 input schema has zero properties, so the baseline for a no-parameter tool is 4. The description correctly avoids inventing parameter guidance and instead focuses on what the returned value means.

  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 title supplies the verb ('Get') and resource ('DNS session city'), and the description clearly reports the current city for the browser session, including its cookie source. This distinguishes it from siblings like dns_set_city and dns_search_cities, which modify or search cities rather than return the active session city.

  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 clear context: this is the city currently in effect for the session and it affects prices and availability, so an agent should call it before price/availability-sensitive lookups. It does not explicitly name alternatives or exclusions, but the current-session framing implies when setting or searching cities is not the goal.

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

• dns_product_detailsA
  4.5/5.0
  Behavior4/5

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

  Annotations already convey readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds value beyond those annotations by disclosing the return-shape composition (a card with price/images/availability fields) and the 16-hex product id format. It does not cover failure modes or how the product id is supplied, but with strong annotations the lowered bar is met.

  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 zero filler: the return fields are front-loaded, the product-id format follows, and the sibling routing closes it out. Every sentence earns its place and the whole description is under 40 words.

  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 low-complexity lookup with strong annotations and no output schema, the field list and routing cover much of what an agent needs. The notable gap is that the schema declares zero parameters while the description references a product id in 16-hex format, leaving the invocation mechanism implicit. An agent cannot determine from this definition how to target the desired product.

  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 input schema is empty (0 params), which sets a baseline of 4. The description adds meaning by stating 'Product id is 16-hex', giving a format constraint the schema does not contain. However, it never explains how to pass the id given that the schema declares no parameters, so it does not fully close the gap.

  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 title states the verb+resource ('Get DNS product details') and the description enumerates the exact return payload (price, oldPrice, rating, article, availability, stock enum, images, imageDataUri, delivery hints, location), making it unmistakable what this tool produces. It also explicitly differentiates itself from dns_product_specs and dns_products_batch, so an agent can separate it from 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 Guidelines5/5

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

  The description gives explicit routing conditions: 'For full specs use dns_product_specs' and 'For 2+ cards prefer dns_products_batch.' This tells the agent both when to use this tool (single product summary card) and when to choose an alternative, which fully satisfies the when/when-not/alternatives criterion.

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

• dns_searchA
  4.8/5.0
  Behavior5/5

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

  Annotations already declare readOnly/openWorld/idempotent, and the description adds useful behavioral context beyond those: results depend on the session city, compact defaults to true, and stock is returned as a fixed enum. The description also surfaces the SESSION_DROP concern without contradicting any annotation.

  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 dense but not wasteful; every sentence contributes either purpose, a caveat, or routing guidance. It could be improved with more visual structure or bullets, but the front-loaded purpose and compact phrasing keep it scannable.

  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?

  There is no output schema, so the description appropriately explains the return contract (id format, stock enum, key fields) and important contextual behavior like session-city dependence and sort scoping. Combined with the schema and annotations, nothing critical is missing for an agent to call this 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?

  Since the schema covers 100% of the 9 parameters, the baseline is 3. The description adds meaning by explaining the compact default, the preferred limit range, and the query-scoped behavior of sort=price_desc, which is not obvious from the schema alone. It does not add nuance for every parameter, but the schema already documents those.

  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 ('Search products on dns-shop.ru') and enumerates the exact return fields, so it is immediately distinguishable from the many dns_* sibling tools. The description makes the tool's role as the product-search entry point clear.

  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?

  Explicitly tells the agent to use dns_search_multi for 3+ queries to avoid SESSION_DROP, and names likely follow-ups (dns_product_details, dns_compare_products, dns_products_batch). It also gives operational guidance like preferring limit 5–8 and clarifies that sort=price_desc applies only to the current query results, not the full catalog.

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