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 does add a meaningful side-effect detail: 'Сессия сохраняется на диск' (session is saved to disk), which clarifies persistence. However, it does not mention whether an existing session is replaced, what happens on invalid/expired code, or any security implications beyond the login action.

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

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

The description is extremely concise: two short clauses that front-load the purpose and then add the key behavioral detail about session persistence. Every word contributes meaning, and there is no redundant or boilerplate text.

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

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

For a tool with only two simple parameters and no output schema, the description covers the essential call shape and the persistence side effect. But it leaves out the expected usage sequence relative to auth_send_code, what a successful response looks like, and failure behavior. Given the absence of annotations, this is adequate but not complete.

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

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

The input schema has zero description coverage, so the description must compensate. It does identify both parameters: 'номер' maps to phone and 'код из SMS' explains that code is the SMS verification code. This adds useful meaning, but it omits details like phone number format, country code expectations, or code length/character constraints.

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

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

The description clearly states the action: 'Завершить вход' (complete login) using phone and SMS code, and notes that the session is saved to disk. It identifies the specific resource (authentication/session) and the required inputs, so the tool's purpose is unambiguous. It does not explicitly differentiate from siblings, though 'finish login' implies contrast with auth_send_code.

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

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

The phrase 'Завершить вход' (finish login) implies this should be used after a verification code has been sent, likely by sibling auth_send_code. However, the description does not explicitly state when to use this tool versus alternatives, mention prerequisites, or give any exclusion criteria. Usage context is implied rather than spelled out.

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

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

With no annotations, the description carries the behavioral burden. It explicitly discloses a meaningful side effect: the saved session is erased from disk. This is important destructive context that goes beyond the tool name.

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

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

A single compact sentence says exactly what the tool does and what side effect it has. No filler, and the most important behavioral information is included.

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

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

For a zero-parameter logout tool with no output schema and no annotations, the description is complete. It names the action and the critical persistence side effect, which is all an agent needs to invoke it correctly.

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

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

The tool has zero parameters, so the schema provides no semantic burden. The baseline of 4 applies, and the description correctly focuses on the operation rather than parameter details.

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

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

The description clearly states the action: log out of the account and erase the saved session from disk. This distinguishes it from sibling auth tools like auth_login, auth_send_code, and auth_status.

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

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

Usage context is implied rather than explicit. An agent can infer this tool should be used to end the current authenticated session, but the description does not state when to prefer it over other auth tools or mention any preconditions.

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

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

No annotations are present, so the description carries the behavioral burden. It discloses the side effect (SMS dispatch), one-time code semantics, phone-number normalization, and the fact that no password is needed. It does not mention rate limits, expiration, error cases, or whether the code is returned in the response.

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

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

Two short sentences that front-load the action and accepted input, then give the follow-up step. Every sentence earns its place without repetition or boilerplate.

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

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

For a one-parameter tool with no output schema, the description covers the core invocation details and the next step in the flow. It is slightly incomplete in not explicitly describing the response shape or failure behavior, but the flow instruction implies the code arrives and is passed along.

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

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

The input schema provides only the phone string with no description (0% coverage), so the description must compensate. It does: the accepted phone formats are specified, which is exactly the semantic an agent needs to format the parameter correctly.

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

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

States a specific action (send SMS with one-time code), the target resource (phone number), and the authentication context. The instruction to pass the code to auth_login distinguishes it from sibling auth tools.

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

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

Clearly establishes the phone-verification flow: send a code, then pass it to auth_login, and notes that account password is not needed. It does not explicitly list when not to use this tool or compare it with auth_status/auth_logout, but the intended context is unambiguous.

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

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

With no annotations, the description carries the behavioral burden. It conveys that the tool reports login state and account number, which implies a read-only query, but it does not explicitly confirm side-effect-free behavior or describe the response shape. This is adequate for a zero-parameter status tool but not fully explicit.

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

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

The entire description is one short, front-loaded sentence that states exactly what status information is returned. No filler or repetition.

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

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

For a simple zero-parameter status check, the description is nearly complete: it names the account system (WinLab) and the key outputs (logged in or not; account number). It could be more explicit about the return format when not logged in, but that is a minor gap.

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

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

There are no parameters, so the schema covers everything and the description does not need to add parameter-level meaning. The zero-parameter baseline is 4.

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

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

The description clearly states this is a status check: whether the agent is logged into the WinLab account and, if so, under which account number. This differentiates it from the auth_send_code, auth_login, and auth_logout siblings, which are action-oriented.

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

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

The phrasing implies it should be used to check the current authentication state, but it does not explicitly say when to prefer it or contrast it with auth_login/auth_logout. No exclusions or alternative conditions are stated.

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

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

Annotations are entirely absent, so the description must carry the burden of disclosing side effects. It says only 'add product to cart' and does not state whether quantities are merged, whether the cart is replaced, whether authentication is required, or what the response contains. The mutation behavior is implied but no operational context is given.

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

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

A single sentence with no filler, front-loading the operation and target. Every word contributes meaning, and the parenthetical adds the two parameters compactly.

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

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

With no annotations, no output schema, and only a terse action statement, an agent lacks information needed to invoke this correctly in a real flow: whether the user must be authenticated, what success or failure looks like, and whether adding is idempotent or appends. The presence of auth_login/auth_status siblings makes this omission salient. The description is not 'complete' for a state-changing tool.

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

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

Schema description coverage is 0%, so the description must compensate for the input schema's bare titles. It does map 'code' to артикул (article number) and 'qty' to количество (quantity), adding domain meaning. However, it adds nothing about the required nature of code, the default qty of 1, or constraints, and does not explain the relationship between the two parameters.

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

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

The description states a specific verb ('add') and resource ('cart'), and clarifies the payload as article number plus quantity. This clearly differentiates it from the sibling cart_view, and the action is unambiguous even without opening the schema.

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

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

The description does not state when to prefer cart_add over alternatives such as cart_view, nor any prerequisites or exclusions. Its usage is only implied by the verb 'add' — the agent must infer that it is for adding items rather than viewing. This meets the 'implied usage' level, with no explicit routing or when-not guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals only that the cart is tied to the current server session, but does not state that the operation is read-only, what the response contains, or whether an active authenticated session is required before calling it.

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

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

The description is extremely compact, with no filler words, and the session-scoping information is front and center. It is slightly too terse to be fully informative, but it is structured efficiently for a no-argument tool.

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

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

For a zero-parameter tool this is minimally functional: an agent can infer it is meant to view the current session's cart. However, the description does not explain the return value, what a successful call produces, or any session/auth prerequisite, so it is not fully complete.

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

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

The input schema is empty with zero parameters, so there is nothing for the description to clarify about parameter meaning. The baseline of 4 applies because no parameter documentation is needed.

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

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

The description names the resource explicitly: the current server session's cart ('Корзина текущей сессии сервера'). The tool name 'cart_view' supplies the view/get operation, so an agent can infer this is a read operation on the session cart. It is clear enough but lacks an explicit verb and does not itself differentiate from sibling cart tools beyond the name.

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

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

There is no guidance on when to use this tool versus alternatives such as cart_add or how it relates to auth/session tools. The description only names a resource and provides no context about prerequisites, exclusions, or preferred conditions.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It adds the useful fact that prices and balances depend on the current store, but it does not disclose side effects, read-only status, or what the tool actually does when invoked. It reads more like a definition than a behavioral specification.

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

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

The description is a single short sentence with no filler or redundant content. Every word contributes meaning about the store's role and its impact on prices and stock, so it earns full marks for conciseness.

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

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

The tool is simple with no parameters, so calling it is trivial, but the description does not explain what the agent will receive in return or how the output is structured. It provides enough context for selection when the current session store is needed, but without an output schema or return-value description, the definition is incomplete for full end-to-end usage.

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

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

The input schema has zero parameters, so there is nothing to document. Per the rubric, a zero-parameter tool receives a baseline score of 4, and the description does not need to compensate for any parameter gaps.

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

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

The description identifies a specific resource (the store attached to the current session) and notes that prices and balances depend on it, but it is phrased as a noun phrase rather than an action like 'returns' or 'gets.' This leaves some ambiguity about whether the tool returns the store or simply represents it, and it does not explicitly differentiate it from siblings like store_details.

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

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

The description gives no guidance on when to use this tool versus alternatives such as store_details or set_region. It does not state 'use this to get the current store' or mention any exclusions, so the agent must infer usage from the name and context.

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

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

With no annotations, the description carries the behavioral burden and does disclose the core behavior: stores of the current region with query matching as a substring of an address/city. It does not disclose pagination behavior, request/response shape, or whether a null query returns all stores, leaving material gaps.

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

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

A single compact sentence front-loads the scope and clarifies the key parameter with examples. No redundant wording; every part earns its place.

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

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

The definition is minimally sufficient for a simple filtered store lookup: scope and query semantics are clear. But with no output schema and no annotations, the missing pagination and response-shape information leave the description adequate rather than complete.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for the query parameter with examples, but page and limit are left to their names/defaults and are not described, making the compensation partial.

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

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

The description clearly identifies the tool as returning stores in the current region and explains that query filters by part of an address or city, with examples. It is unambiguous, but it does not explicitly name sibling tools or contrast with alternatives, so it falls short of a 5.

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

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

The description implies when to use the tool, i.e., to look up stores in the current region, optionally filtered by a query string, and gives concrete query syntax/examples. However, it provides no explicit guidance about when not to use it or which sibling tools, such as store_details, list_regions, or search_products, would be preferable.

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

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

With no annotations, the description carries the burden of explaining behavior. It states that the tool returns facets for a request and that outputs feed into search_products, which implies a read-only lookup. However, it does not explicitly disclose side-effect-free behavior, authentication requirements, or limitations such as how the top parameter affects results.

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

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

The description is two concise sentences with no redundancy. The core meaning is front-loaded, and the integration hint about search_products is a valuable, non-repeating addition.

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

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

For a simple two-parameter tool with no output schema, this description provides the essential purpose and the product workflow context. It is missing parameter-level detail for top and does not state that query is required, making it minimally adequate but not complete.

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

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

Schema description coverage is 0%, so the description must explain parameters itself. It indirectly maps query to the request, but it says nothing about the top parameter, its default, or its effect on the facet list. This leaves an agent guessing about a key part of the call.

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

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

The description identifies a specific resource—available facets (brand, country, type, volume, aging, discounts)—and ties it to a query. It clearly communicates what the tool returns, and the resource is distinct from siblings like search_products or suggest, though the differentiation is implicit rather than explicit.

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

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

The description gives clear usage context: the returned facet values can be passed to search_products. This tells an agent where this tool fits in a workflow, but it does not mention when not to use it or name alternative tools, so it stops short of a 5.

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

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

With no annotations provided, the description carries the behavioral burden. It discloses that the tool returns region codes and names and implies a read-only listing operation because it takes no parameters and is named 'list'. It does not mention authentication or edge cases, but for a simple list tool this is adequate.

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

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

The description is two short Russian sentences with no filler. The output content and the downstream use are both stated directly and efficiently.

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

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

For a zero-parameter listing tool with no output schema, the description is complete: it states what is returned and why the agent would need it. Nothing essential for invoking this tool correctly is missing.

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

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

The input schema has zero parameters and 100% coverage, so the description does not need to explain parameters. It instead clarifies the meaning of the output code, which is more relevant for the agent.

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

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

The description clearly identifies the resource (regions of network presence) and the returned fields (code + name), and it links the tool to set_region by explaining that the code is required there. This distinguishes list_regions from its sibling tools.

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

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

The description gives clear contextual guidance: list_regions is the source for region codes needed by set_region. It does not explicitly list exclusions or alternatives, but no alternative region-listing tool exists among the siblings.

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

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

With no annotations, the description carries the behavioral disclosure burden. It usefully reveals that data is sourced from search results because the direct product page is protected by an anti-bot mechanism. However, it does not mention possible limitations of search-sourced data or error/not-found behavior.

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

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

The description is two compact sentences with no filler. The core purpose and example are front-loaded, followed by a concise note on the data source workaround.

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

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

For a one-parameter lookup tool, the description is reasonably complete: it states what the tool returns and why the data source differs from the obvious page. It lacks an explicit return schema or field list, but 'full product card' sufficiently communicates the output type.

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

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

Schema description coverage is 0%, so the description compensates by defining 'code' as an article number and giving a concrete example. This adds real semantic meaning beyond the bare schema object, though it does not specify format constraints beyond the example.

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

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

The description clearly states the tool returns the full product card for a given article code, with a concrete example ('1019872'). This distinguishes it from the search-oriented sibling tools by focusing on a single product lookup by exact code.

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

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

The description implies when to use this tool: when you need complete product details for a known article code. It explains the workaround for the blocked product page, but it does not explicitly name alternative tools or state when not to use it.

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

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

With no annotations available, the description carries the behavioral burden and reveals important non-obvious facts: the server ignores sort and price-range parameters, so these must be applied client-side to pages × 21 items. It also explains in_stock_only as inventory in the current store. It lacks return-format and error/rate-limit detail, but the main caveats are disclosed.

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

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

The description is compact, front-loaded with the core purpose, and organized by parameter groups. Every sentence adds operational value, such as examples of acceptable query and facet values.

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

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

For a complex 11-parameter tool with no annotations or output schema, the description provides most needed context: how to form queries, how to pass facets, current-store semantics, and server-side parameter behavior. The main gaps are the undocumented 'limit' parameter and the absence of any return-value description, which would be useful since no output schema is provided.

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

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

Schema coverage is 0%, and the description compensates by explaining query as free text or article, the source and exact format of facet values, and the ignored effect of sort and price range. However, the 'limit' parameter is not described, leaving one of eleven parameters semantically uncovered.

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

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

The description clearly states the tool searches products in the WinLab catalog and defines query as free text or article number, so the core operation is unambiguous. It does not explicitly contrast itself with sibling tools like suggest or product_details, though the action is evident.

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

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

The description implies when to use the tool for product search and points to list_filters as the source of exact facet values. It does not explicitly state when not to use it, nor does it name alternatives such as suggest or product_details for related lookup needs.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond a simple 'change region' by warning that it affects prices, stock, and the store list, which is valuable side-effect information for an agent.

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

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

The description is two short sentences with no filler. The action and example are front-loaded, and the side-effect warning earns its place.

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

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

For a simple one-parameter setter with no output schema, the description is largely complete: it says what the tool does, what input to supply, and what consequences follow. It could mention auth requirements or whether the change is persisted, 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.

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

The schema provides no description for the required 'code' parameter, so the description must compensate. It offers a concrete example ('RU-SPE'), which helps the agent infer the expected format, though it does not enumerate valid values or explain why some codes may be invalid.

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

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

The description uses a clear imperative verb ('Сменить') and names the resource ('регион'), making the tool's purpose obvious. It also includes an example value and states downstream effects, but it does not explicitly distinguish itself from sibling tools such as list_regions or current_store.

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

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

The description implies this tool is for changing the current region, which is a reasonable usage signal. However, it provides no explicit guidance about when to prefer it over alternatives, nor does it mention any prerequisites such as authentication or the need to call list_regions first.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does make the read-only lookup nature inferable and specifies the returned data fields, but it does not explicitly state that no state is modified or describe what happens for invalid or unknown store codes.

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

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

The description is a single concise sentence that front-loads the core purpose and immediately gives relevant output details. There is no redundant or filler content.

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

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

Given the low complexity of this tool — one required string parameter and no output schema — the description covers the input key, gives an example, and names the expected output fields. It is adequate, though it leaves error behavior and alternative-tool routing implicit.

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

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

The schema provides only a property name and type for store_code, with 0% description coverage. The tool description compensates by identifying the store code as the lookup key and providing an example format ('M735'), which adds practical meaning for the agent.

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

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

The description clearly identifies the tool as a store-details lookup by store code and enumerates the returned fields: address, opening hours, and metro. However, it uses a noun phrase rather than an explicit verb and does not explicitly differentiate itself from sibling tools like find_stores or current_store.

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

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

The phrase 'по коду' implies that the tool should be used when the caller already has a store code, but no explicit when-to-use or when-not-to-use guidance is given. It does not mention alternatives such as find_stores for cases where the code is unknown.

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

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

Annotations are absent, so the description bears the full burden of behavioral disclosure. It reveals the output type (similar products and clarifying queries) but says nothing about whether the call is read-only, whether authentication is required, side effects, or error behavior. For a tool with zero annotation coverage, this is a significant gap.

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

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

A single short sentence with the core idea front-loaded and no filler words. It is efficient, though the brevity trades away substantive guidance.

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

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

With no output schema and no annotations, the description must supply return semantics, parameter meaning, and usage context on its own. It provides a one-line summary of the return content but omits parameter semantics and any operational conditions, leaving an agent to guess at a correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate by explaining the parameters. It does not mention 'term' or 'limit' at all; 'поиска' (search) weakly implies term is a search query, but limit's meaning, default, and range are entirely undocumented.

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

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

The description states a specific function: producing search hints in the form of similar products and clarifying queries. It implicitly distinguishes from search_products (actual results vs. suggestions), though it never names the sibling or the boundary explicitly.

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

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

Usage is only implied: the agent can infer this tool is for autocomplete/suggestion scenarios rather than full search. There is no explicit when-to-use, when-not-to-use, or named alternative such as search_products, so the routing decision is left to inference.

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