Server Quality Checklist

Tool Scores

• list_store_categoriesC
  2.1/5.0
  Behavior1/5

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

  No annotations are provided, so the description alone must disclose behavior. It only says 'Get the category tree' without mentioning return format, hierarchy, pagination, authentication, or side effects. As a read operation, it likely has no destructive behavior, but that is not stated. This is a significant gap given the lack of annotations.

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

  Conciseness3/5

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

  The description is a single sentence that is efficient and front-loaded, but it is under-specified for a tool with no other documentation. While conciseness is a virtue, here it borders on omission. The structure is minimal but not unnecessarily verbose.

  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?

  Given the low complexity (one parameter, no output schema, no annotations), the description provides the basic action but leaves the agent guessing about the expected response and any hierarchy or filtering details. It does not fully enable an agent to call the tool without further investigation.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description does not elaborate on the store_id parameter. The agent only sees that it's a string, with no guidance on format, validation, or its role in identifying the store. The description adds no meaning beyond the raw schema.

  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 clear verb and resource: getting the category tree for a store. This distinguishes it from siblings like list_category_products, which focus on products within a category, though it doesn't explicitly call out that distinction. It's specific enough for an agent to understand the basic function.

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

  Usage Guidelines1/5

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

  There is no guidance on when to use this tool versus alternatives. Sibling tools like get_store_info or list_category_products exist, but the description provides no context about when to select this one over them. This leaves the agent without routing information.

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

• find_productsC
  2.6/5.0
  Behavior2/5

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

  With no annotations provided, the description must fully disclose behavior. It only mentions that the nearest store is resolved 'when needed', but does not explain what triggers that, how conflicts between store_id and address are handled, pagination behavior, or any side effects. For a tool with 10 parameters, this is a significant transparency gap.

  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 extremely concise – a single sentence that front-loads the primary action and location parameters. It is efficient and to the point, though the brevity comes at the cost of omitting essential details for correct invocation.

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

  Completeness1/5

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

  For a tool with 10 parameters, no output schema, and no annotations, this description is highly inadequate. It fails to explain key behavioral aspects like sorting, filtering, pagination, error handling, or the structure of results. Agents have almost no guidance on how to construct a proper request or interpret the response.

  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 0%, so the description should compensate. It only mentions store_id and address, while other parameters like query, brand, price_min, promo_only, sort, limit, and offset remain unexplained. The description adds minimal semantic value beyond the parameter names themselves and fails to clarify their intended usage.

  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 action ('Find products') and the resource (products), and explicitly mentions the key parameters (store_id or address). It distinguishes itself from siblings like search_products by focusing on store-based lookup, though the phrase 'resolving the nearest store when needed' is somewhat ambiguous about the exact logic.

  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 does not provide guidance on when to use this tool versus alternatives such as search_products or list_category_products. It implies the tool is for store-specific product queries but does not state exclusions, prerequisites, or how to choose between this and sibling tools. Agents are left 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.

• list_stores_in_areaC
  2.6/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action 'List' which implies a read-only operation, but it does not specify whether the operation returns a list of store IDs, full store objects, or any pagination behavior. There is no mention of authentication, rate limits, or side effects. The description is minimal and leaves the agent guessing about the operation's behavior.

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

  Conciseness3/5

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

  The description is a single, concise sentence with no wasted words. However, it is under-specified for a tool with four numeric parameters. While it is not verbose, the lack of additional context makes it feel insufficient rather than appropriately sized. The sentence does earn its place, but more detail is needed to make the tool usable, so it's a middle score.

  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?

  The description is incomplete given the tool's complexity. There is no output schema, no annotations, and no explanation of the return format, coordinate constraints, or any prerequisites. An agent cannot confidently call this tool without knowing what the response looks like or how to correctly construct the rectangle. The description is too sparse to be contextually complete.

  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 schema has 0% description coverage, so the description must explain the parameters. It only mentions 'rectangular map area' but does not clarify how the four coordinates (top_latitude, bottom_latitude, left_longitude, right_longitude) form the rectangle, nor the expected value ranges or ordering. The parameter names are self-evident but the description adds almost no value beyond the names, failing to compensate for the schema's lack of detail.

  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 action ('List'), the resource ('Pyaterochka stores'), and the scope ('inside a rectangular map area'). It distinguishes itself from siblings like find_store and find_nearest_stores by specifying an area-based search rather than a single store or proximity-based search. However, it does not explicitly contrast these alternatives, so it slightly misses the top score.

  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 provides no explicit guidance on when to use this tool versus alternatives like find_nearest_stores or find_store. It only hints at the 'rectangular map area' scope, but doesn't state scenarios (e.g., 'use this when you need all stores in a region rather than the nearest one'). No exclusions or context is provided, leaving the choice to inference.

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

• list_category_productsC
  2.8/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It says 'List products' but doesn't state whether the operation is read-only, what the return format looks like, whether pagination is applied, or any side effects. This is a significant gap for a tool with no output schema.

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

  Conciseness5/5

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

  The description is a single efficient sentence with no redundant phrases. It is front-loaded with the core action and purpose, making it easy to parse quickly. There is zero fluff.

  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?

  For a tool with 9 parameters, no output schema, and no annotations, the description is far too sparse. It omits essential usage details like default sorting, pagination limits, whether filters are optional, and how results are returned. An agent would be under-informed about how to construct a correct call.

  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 schema description coverage is 0%, so the description should compensate by explaining the filters (e.g., price_min, promo_only, sort). Instead, it only says 'apply filters' without enumerating or clarifying any parameter semantics. The description adds negligible value over the raw property names.

  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 verb ('List') and resource ('products in a store category') and mentions 'apply filters,' which distinguishes it from global sibling tools like search_products. It is clear but doesn't explicitly differentiate from similar tools, so it's not a 5.

  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 provides no guidance on when to use this tool versus siblings like search_products or find_products. No context, prerequisites, or exclusion criteria are mentioned. An agent must infer usage solely from the name and category scope.

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

• search_productsC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that it searches and applies filters, but it does not reveal any behavioral traits such as pagination (limit/offset meaning), error handling, authentication requirements, or the shape of the response. It does not mention whether results are store-scoped (though 'in a store' implies store_id). Beyond that, there is no information about rate limits, sorting semantics, or how promotions are filtered. This is a significant gap for a search operation with no annotation support.

  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 a single, concise sentence that front-loads the primary action ('Search products') and lists the filter dimensions. It has no repetition or fluff. It is appropriately sized for the tool's complexity, though it could be slightly longer to include critical parameter context. For a tool with 9 parameters, it may be too terse, but the structure itself is clean and to the point.

  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?

  Given the complexity (9 parameters, no annotations, no output schema), the description is clearly incomplete. It does not explain the two required parameters (store_id and query) beyond a loose implication of 'in a store'. It does not mention limit/offset pagination, enum choices for sort, or how filters interact. The description provides only the high-level purpose and filter names, leaving an agent without enough context to correctly invoke the tool without further schema inspection.

  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 0%, so the description must compensate. It names filter categories (price, brand, promotion, sorting) which loosely map to parameters like price_min/price_max, brand, promo_only, and sort, but it does not explain individual parameters. It omits the meaning of required fields query and store_id (though 'in a store' hints store_id). It does not clarify the enum values for sort, the semantics of limit/offset, or the default behavior. The description provides only a high-level overview, which is insufficient for the 9 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 description states a clear verb ('Search') and resource ('products in a store') and enumerates the filter dimensions (price, brand, promotion, sorting). It is specific enough to suggest this is a filtered search tool, though it does not explicitly differentiate from sibling tools like find_products or list_category_products, which might also involve searching/filtering products. The mention of 'apply ... filters' gives a distinct purpose.

  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 description implies usage: use this when you need to search products with filters. However, it does not provide explicit guidance on when to choose this versus siblings like find_products, list_category_products, or get_product_info. There are no exclusions or alternatives mentioned. The context of filters gives some direction but the usage is only implicit, not explicit.

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

• find_storeB
  3.1/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the core function without revealing any traits such as whether it requires authentication, what happens if no store is found, or any rate limits. For a read-only lookup this is a notable gap.

  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 a single, focused sentence that front-loads the primary purpose and output. It contains no redundant words and is perfectly sized for a simple tool.

  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 one-parameter tool with no output schema and no annotations, the description is minimally adequate. It clarifies the input and output but omits potential edge cases (e.g., invalid address, no nearby store) and any prerequisites. Given the simplicity, a 3 is fair.

  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% and the parameter has a clear example. The tool description does not add extra meaning beyond the schema, but the schema itself is sufficient. Baseline 3 is appropriate; the example helps but does not elevate beyond the schema.

  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 verb ('find'), a resource ('nearest Pyaterochka store'), an input ('full address'), and an output ('store_id'). It is clear on the tool's function. It does not explicitly differentiate from the sibling 'find_nearest_stores', but the singular address input and return of store_id give a distinct purpose.

  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 provides no guidance on when to use this tool versus alternatives like 'find_nearest_stores' or 'list_stores_in_area'. There is no mention of prerequisites, context, or exclusions. The agent is left to infer usage from the tool name and description, which is minimal.

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

• get_product_promotionB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description must convey behavioral traits. It only says 'Get', implying a read operation, but does not disclose any side effects, error handling, or whether the tool might return null if no promotion exists. It also does not mention any required permissions or rate limits, leaving the agent with minimal insight beyond the action itself.

  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 a single concise sentence that is easy to parse and front-loads the core purpose. There is no unnecessary detail or redundancy, making it appropriately brief for a simple retrieval tool.

  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?

  Given no output schema and sparse annotations, the description is incomplete. It does not explain what 'promotion details' includes, how to interpret the response, or any edge cases like missing promotions. For a tool with two parameters and no output schema, more context is needed to ensure correct usage.

  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 schema has no parameter descriptions (0% coverage), so the description needs to explain the parameters. It mentions 'product PLU' and 'store', which maps to the plu and store_id parameters, but adds no format, constraints, or examples. The description essentially restates the parameter names without providing additional 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 clearly states the tool retrieves promotion details for a product PLU in a store, specifying both the resource (promotion) and the scope (product and store). It distinguishes from siblings like get_product_info which presumably returns general product details, making 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?

  No guidance is provided on when to use this tool versus alternatives such as get_product_info or search_products. The description does not mention any conditions, prerequisites, or exclusions, leaving the agent to infer 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.

• get_store_infoB
  3.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what is returned, which is essentially the purpose. It does not mention any side effects, permissions, rate limits, or reversibility. For a read-like 'get' operation, the lack of confirmation that it is non-destructive or safe is a gap, though the name suggests read-only. The description adds little beyond the obvious.

  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 a single, efficient sentence that front-loads the action and resource, then lists expected fields. There is no unnecessary verbosity or duplication. Every word contributes to understanding the tool's purpose.

  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?

  Given the simple schema (one parameter) and no output schema, the description covers the basic return values. However, it does not address potential ambiguity with sibling tools (e.g., get_store_hours) or how the user might need to use the store_id (e.g., from where it comes). It is adequate for a simple getter but lacks guidance on when to choose it over alternatives.

  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 has 0% description coverage for the sole parameter store_id. The description compensates by saying 'by store_id', which indicates the parameter is the identifier used to look up the store. However, it does not explain the format, any constraints, or how to obtain a valid store_id. This is a minimal but useful clarification that the schema lacks.

  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 action (Get) and resource (store details) and lists specific fields (address, opening hours, metro, coordinates). It distinguishes from siblings like get_store_hours by implying a broader set of details, though it doesn't explicitly name alternatives. The verb and resource are unambiguous, so it clearly communicates what the 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 Guidelines2/5

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

  No guidance is provided on when to use this tool versus siblings. For example, it doesn't mention that get_store_hours may be better if only hours are needed, or that find_store might be used when the ID is unknown. The agent is left to infer the appropriate context from the description alone, which is insufficient given the variety of similar tools.

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

• refresh_sessionB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full responsibility for behavioral disclosure. It mentions 'refresh' which implies a state change, but does not indicate whether this is destructive, requires special permissions, or has side effects on the session state. There is no mention of what happens if cookies are invalid or if the operation can fail. This is a significant gap for a mutation-like operation.

  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 a single, efficient sentence with no filler. It states the action and target clearly. Every word contributes to meaning, and there is no redundancy.

  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?

  Given the tool has no parameters, no output schema, and no annotations, the description is minimal but borderline acceptable. However, it lacks critical context such as when this tool should be invoked (e.g., after long idle periods, before high-stakes requests), what 'protective cookies' protect against, and whether there are any errors or side effects. For a session-management tool, an agent would benefit from knowing typical use cases and limitations.

  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 100% and there is nothing to explain. The description correctly omits parameter details. It would be unreasonable to expect parameter-level semantic information when no parameters exist.

  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 a specific verb ('refresh') and resource ('protective cookies') for the current web session. This is distinct from all sibling tools which focus on store/product operations, so an agent can easily differentiate it. It could be slightly more explicit about what 'protective cookies' are, but the action is 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?

  There is no guidance on when to use this tool versus alternatives, nor any prerequisites or conditions that would warrant calling it. The description implies it maintains session integrity but does not state under what circumstances a refresh is needed (e.g., after authentication expiry, before sensitive operations). This leaves the agent to infer usage.

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

• get_product_infoB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of disclosing behavior. It mentions the output contents but does not state whether the operation is read-only, what happens if the product is not found, any permission requirements, rate limits, or other side effects. The word 'Get' implies read-only, but it is not explicit.

  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 a single sentence that front-loads the primary action and result, with no filler. It is concise and to the point, though it could briefly mention the store_id parameter to improve completeness without adding much length.

  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 simple two-parameter lookup with no output schema or annotations, the description provides the core purpose and some return fields, but omits clarification on why store_id is needed, the semantic difference from search tools, and any error/edge-case behavior. It is barely adequate for an agent to call it correctly without additional assumptions.

  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 0%, so the description must explain both parameters. It explains 'PLU' as the product identifier, but does not mention 'store_id' at all, nor explain its purpose or required format. This leaves an entire required parameter undocumented.

  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 ('Get'), a specific resource ('product details'), and a specific lookup key ('by PLU'), and lists the data returned (ingredients, calories, nutrients, URL). This clearly differentiates it from sibling tools like search_products or find_products, which are for finding by query rather than direct lookup.

  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 description implies the tool is used when you have a PLU (product code) to retrieve details, but it does not explicitly state when to prefer this over search_products or find_products, nor does it mention when not to use it. The 'by PLU' hint gives context but no explicit exclusions or alternatives.

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

• get_store_hoursB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden. It states what data is returned but does not disclose behavior for invalid store_id, error handling, or whether the store must be open. No extra context beyond the basic function.

  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, concise sentence with no redundancy. The information is front-loaded and directly addresses the tool's purpose without any 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 simple single-parameter getter, the description covers the essential purpose but omits any mention of return format, error cases, or prerequisites. Given no output schema and no annotations, a more complete description would include what the response looks like or what happens for nonexistent stores.

  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 0%, so the description must clarify the parameter. It mentions 'by store_id', which identifies the parameter as an identifier, but does not specify format (numeric vs string), source, or validation rules. Minimal compensation for the lack of 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?

  The description clearly states the verb 'Get', the resource 'opening hours and 24-hour status', and the identifying parameter 'store_id'. It distinguishes from siblings like find_store (search) and get_store_info (general info) by specifying the exact data returned.

  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?

  No guidance on when to use this tool over alternatives. It doesn't mention situations where this is preferred over get_store_info or list_stores_in_area, nor any prerequisites like needing a valid store_id.

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

• find_nearest_storesB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full responsibility for behavioral disclosure. It clearly states the distance sorting, but it does not disclose what information is returned (store full details, hours, etc.), whether a default limit applies when 'limit' is omitted, or any potential rate limiting or error conditions. Without annotations, this is a notable gap in transparency for a query tool.

  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 a single, information-dense sentence. Every word contributes value: 'Find', 'nearby', 'Pyaterochka stores', 'by coordinates', 'sorted by distance'. There is no redundant phrasing or filler, and the core intent is front-loaded. This is an exemplary example of conciseness without under-specification.

  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 simple list tool with only three parameters and no output schema, the description covers the fundamental purpose and ordering. However, it omits practical details an agent would need for reliable invocation: the meaning of 'limit' (whether it's a count or a distance radius), the nature of the returned data (store IDs, names, hours), and any default or edge-case behavior. It is sufficient for a basic call but not comprehensive enough to avoid guesswork.

  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 0% and the schema itself contains no property descriptions. The description mentions 'coordinates' but does not explicitly map latitude and longitude, nor does it explain the semantics of 'limit' (e.g., maximum number of results). An agent would have to infer that latitude/longitude are the coordinates and that limit controls result count, which is not fully explicit. The description adds little beyond the 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 states a specific verb ('find'), a clear resource ('Pyaterochka stores'), the input method ('by coordinates'), and the output ordering ('sorted by distance'). It is immediately distinguishable from siblings like 'find_store' (singular) and 'list_stores_in_area' (area-based), which serve different use cases. No ambiguity remains about the tool's core function.

  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 description implies usage context: when the agent has coordinates and wants nearby stores sorted by distance. However, it does not explicitly state when to prefer this over 'find_store' or 'list_stores_in_area', nor does it mention any exclusions (e.g., 'use this only when a center point is available'). The 'by coordinates' phrase gives some directional guidance, but no concrete comparison to alternatives is provided.

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