Server Quality Checklist

Tool Scores

• wb_check_authA
  4/5.0
  Behavior4/5

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

  With readOnlyHint=true, the description adds meaningful context beyond the annotation: it explicitly promises not to reveal secret values and clarifies it only reports which variables are set. The documented JSON shape also sets expectations. This is genuinely useful behavioral disclosure, though it does not mention any edge cases like partially configured environments.

  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 verb/resource first, a key safety guarantee second, and the exact return shape third. Every sentence earns its place and the format is easily parseable.

  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 credential check with an output schema, the description is fully sufficient. It says what it checks, what it will not do, and exactly what JSON it returns. An agent can invoke it correctly without additional 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 and an empty input schema, so there is no parameter burden for the description to carry. The baseline of 4 applies; no additional parameter detail is needed.

  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 and resource: 'Check whether the required credentials are present in the environment.' It also clarifies the non-revealing behavior, distinguishing it from a naive credential dump. It does not explicitly name sibling check_auth tools, but the wb_ prefix and title 'WB check credentials' resolve platform ambiguity.

  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 core use case — verifying credentials before API work — is implied but never stated explicitly. There is no guidance about when to call this versus tools like wb_set_key or wb_call_method, nor a comparison to the sibling check_auth tools for other platforms.

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

• wb_describe_methodA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the specific content of the returned record, which is useful context, but it doesn't disclose any additional behavioral traits such as error handling, auth requirements, or side effects. Since annotations cover the read-only nature, 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?

  A single, front-loaded sentence that lists all relevant fields without any filler. Every word earns its place, and the structure is perfectly readable for an agent scanning for a quick purpose.

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

  Completeness4/5

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

  With an output schema present, the description doesn't need to detail return values. It lists the record's fields, which covers the content. It doesn't mention what happens with an invalid operation_id or how to obtain one, but given the read-only nature and the existence of sibling search tools, this is acceptable. The description is complete enough for the tool's simple role.

  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 0%, so the description must compensate. The parameter operation_id is only implicitly defined via 'one endpoint.' It doesn't explicitly state that operation_id is the identifier for the endpoint, nor does it provide format or examples. However, the parameter name is self-explanatory and the description implies its role, so it meets the minimum bar.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Return the full catalog record for one endpoint.' It enumerates the exact fields returned (method, host, path, scope, safety level, pagination style, rate limit, params, doc URL), making it unmistakably distinct from sibling tools like wb_search_methods (search) or wb_call_method (execute). The singular 'one endpoint' clarifies its scope.

  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 implies usage: call this when you have an operation_id and need the full details of a single endpoint. It doesn't explicitly mention alternatives or when not to use it, but the distinction from search/call tools is evident from 'one endpoint' and the listed fields. No exclusions are stated, but the context is clear enough for an agent to infer.

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

• wb_remove_cabinetA
  4/5.0
  Behavior4/5

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

  The annotations already indicate destructiveHint, and the description adds useful behavioral detail beyond that: deleting the active cabinet causes another cabinet to become active. This is valuable state-change information the agent would not infer from annotations alone.

  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 extremely concise, with no filler or redundant content. The core purpose is front-loaded in the first sentence, and the additional behavioral note is short and directly relevant.

  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 complexity, the presence of an output schema, and simple single-parameter signature, this description is adequate. It covers the operation and a key side effect. Missing error cases are not essential 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 description coverage is 0%, but the docstring explicitly defines the single parameter: 'name: the cabinet to remove.' This gives the parameter semantic meaning beyond its type and required status, which is sufficient for this simple 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 action: 'Delete a stored cabinet.' This is a specific verb and resource, distinct from add/list/update operations. It also adds a relevant behavioral detail about active-cabinet state that differentiates it from a generic delete description.

  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 explicit guidance on when to use this tool versus alternatives. It does not mention sibling operations like wb_add_cabinet, wb_set_key, or wb_remove_cabinet, nor does it describe preconditions or situations where this tool should or should not be used.

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

• wb_get_sectionA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true (safe read-only operation), so the description doesn't need to emphasize that. It adds context about the return format (a JSON list with specific fields) and the need to consult list_sections, which is useful but doesn't cover additional nuances like pagination or large sections. Since annotations carry the safety burden, a 3 is appropriate.

  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 extremely concise: three short sentences plus an Args section and a Returns line. It front-loads the core purpose in the first sentence and uses a clear structure for the single argument and return type. No wasted words.

  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?

  The tool has only one parameter)Skip; the description covers its semantics via a reference to list_sections. The output schema is present, so the return format doesn't need elaboration beyond the description's summary. Annotations cover safety and open-world assumptions. This is a simple discovery tool, and the description is complete 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 0%, so the description must compensate for the parameter meaning. It does explain that 'section' is the section name and references the list_sections tool for valid values, which is better than the bare schema. However, it doesn't provide explicit examples except one, which is minimal but sufficient for a single-string parameter.

  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 lists all endpoints in a given section, with a specific verb and resource. It distinguishes from siblings by showing the output structure (operation_id, method, path, safety, summary) and referencing the section naming convention from a sibling tool.

  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 explicitly says the section name should come from the corresponding list_sections tool, providing clear context. However, it does not explicitly say when not to use this tool in favor of alternatives like search_methods or describe_method, though the sibling similarity is implied.

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

• wb_list_sectionsA
  4.1/5.0
  Behavior3/5

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

  Annotations already flag readOnlyHint=true and openWorldHint=false, so the safety profile is handled. The description adds the counting behavior and audited by the 'catalog endpoints' phrase, but provides little beyond what annotations and the tool name convey; it does say it returns a list.

  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?

  One sentence, front-loaded with the verb and resource, and every phrase earns its place. It states what is listed and the added beneficial detail of 'how many catalog endpoints' in two clauses without waste.

  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?

  A zero-parameter read-only listing tool with an output schema. The description contains all the caller needs to know to select it, expect it to be non-mutating, and understand what it returns. The output schema preserves the return details from needing to be described here.

  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 takes zero parameters and has 100% schema coverage, so parameter semantics are the baseline: the description does not need to explain parameters. Nothing is missing; no additional parameter usage context is required.

  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', on a concrete resource, 'API sections', and adds precise output detail: 'how many catalog endpoints each contains.' This clearly differentiates it from siblings like wb_get_section (singular section retrieval) and wb_search_methods (searching for methods).

  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 use case is implied rather than stated: use this tool when you need to enumerate available API sections and see endpoint counts. However, there is no explicit when-to-use guidance, no exclusions, and no mention of alternative tools like wb_get_section or wb_map.

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

• wb_search_methodsA
  4.1/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds that the tool returns a JSON list ordered 'best first' and specifies the limit range (1-50), which is useful behavioral context. However, it does not disclose potential error conditions or rate limits, but given the read-only and simple nature, 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.

  Conciseness5/5

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

  The description is brief and front-loaded: the main purpose appears in the first sentence, followed by an Args section that explains each parameter, and a Returns line. There is zero fluff; every sentence provides actionable information. The structure is clean and easy to scan.

  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 simple search tool, the description covers everything an agent needs: what it does, how to use the parameters, and what to expect in the response (JSON list, sorted by relevance). The output schema is present, so detailed return structure is not required. The bilingual note is a nice extra. Nothing critical is missing.

  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 provides only type and default for both parameters, with no descriptions. The description compensates by explaining that 'query' is free text with concrete examples ('остатки', 'stocks', 'update price') and that 'limit' is capped at 1-50. This adds meaningful semantics beyond the schema, though it does not elaborate on query syntax or matching behavior beyond the examples.

  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 ('Search'), a clear resource ('the endpoint catalog'), and a method ('by keyword'). It also adds a unique feature—bilingual support (Russian and English)—that distinguishes it from generic search tools. The purpose is immediately unambiguous and does not rely on the tool name alone.

  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 does not explicitly mention when to use this tool versus alternatives like wb_map or wb_list_sections. Its usage is implied by its nature as a search tool, but there is no guidance on when to prefer it or what situations it is not suited for. The only implicit context is that it returns matching endpoints, suggesting it is for discovery before calling methods.

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

• wb_use_cabinetA
  4.2/5.0
  Behavior4/5

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

  Annotations already indicate mutation (readOnlyHint=false) and idempotency, and the description adds meaningful behavioral context by stating that the active cabinet is switched and that subsequent calls use its credentials. It does not over-explain return values or edge cases, but the core state change is clear.

  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 extremely concise and front-loaded: one imperative sentence states the action and effect, followed by a single-line argument explanation. Every sentence earns its place 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?

  The description is sufficient for a simple one-parameter state-change tool, especially with an output schema present. It could be marginally more complete by noting the prerequisite that the cabinet must already exist, but the reference to list_cabinets covers the discovery path.

  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 0%, so the description carries the burden for explaining the 'name' parameter. It defines it as 'the cabinet to activate' and directs the agent to {svc}_list_cabinets, which provides both meaning and a retrieval source.

  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 and resource ('Switch the active cabinet') and clearly states the tool's effect. It is readily distinguishable from sibling cabinet tools like wb_list_cabinets, wb_add_cabinet, and wb_remove_cabinet.

  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 when to use it ('Subsequent API calls use its credentials') and points to {svc}_list_cabinets for valid names, but it does not explicitly state alternatives or exclusions, such as 'use this only after adding a cabinet' or 'do not use for auth checks.'

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

• wb_call_methodA
  4.3/5.0
  Behavior4/5

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

  Annotations already indicate destructiveHint=true, but the description adds crucial specifics: it requires confirm_write for write endpoints and both confirm_write and i_understand_this_modifies_data for destructive endpoints. This directly discloses the safety behavior. It also notes that nothing is sent otherwise, which is a clear behavioral contract. The description complements the annotations without contradicting 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?

  The description is efficiently structured: a one-sentence summary, a clear safety warning front-loaded, and a bulleted list of parameters. Each line has a purpose, and the most critical information (safety requirements) is at the top. No fluff.

  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 complex tool with 6 parameters and an output schema, the description covers the core invocation logic and safety requirements. It mentions the return shape ({ok, status, data}) and error envelope, matching the output schema, so no need for further explanation. However, it doesn't cover edge cases like how to obtain operation_ids (though that is delegated to search_methods) or how path_values should be formatted, but given the schema does not provide details either, the agent must infer. This is a minor gap.

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

  Parameters5/5

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

  Schema coverage is 0%, so the description must fully explain each parameter. It does: operation_id is traced to the catalog, path_values corresponds to {placeholders}, query is for query-string parameters, body is the JSON request body, and the two booleans are given explicit names. This compensates perfectly for the lack of schema descriptions.

  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's primary function ('Execute one catalog endpoint by operation_id') and distinguishes it as part of a family of tools. However, it doesn't explicitly differentiate from siblings like wb_call_raw, which might be a conflict; the agent must infer that wb_call_method is the higher-level version that understands the catalog, while wb_call_raw is lower-level. This inference is possible but not spelled out.

  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 states when to use it: for executing a specific catalog endpoint by operation_id. It also implies alternative tools like wb_search_methods for finding operation_ids, and wb_call_raw for raw calls, but does not explicitly say 'use X instead when...'. The differentiator from wb_call_raw is implicit in the description's reference to the catalog.

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

• wb_get_new_ordersA
  4.3/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint and openWorldHint. Description adds the exact JSON response structure and keys (id, rid, etc.), giving the agent expected output format.

  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-sentence description: first sentence states purpose, second shows response structure. No fluff, well front-loaded.

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

  Completeness5/5

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

  Tool has no parameters, output schema implied by example JSON, annotations cover behavior. Description provides all necessary context for a simple list operation.

  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?

  No parameters; schema coverage 100%. Description doesn't need to add param info. Baseline 4 for 0 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?

  Clear verb 'Get', specific resource 'new FBS assembly orders awaiting processing'. Distinct from sibling tools (Ozon products).

  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?

  No explicit when-to-use or alternatives mentioned. However, siblings are unrelated, so guidance is less critical, but still absent.

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

• wb_get_pricesA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint: true and openWorldHint: true, so the safety profile is covered. The description adds valuable behavioral context by specifying the return JSON structure (including 'ok' and 'data.listGoods' with fields like nmID, sizes, discount) and pagination behavior (limit <=1000, offset). This goes beyond the annotations and helps the agent understand the tool's output and constraints. No contradictions 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?

  The description is concise and front-loaded with the primary purpose in the first sentence. It then lists parameters and return format in a structured, scannable way. Every sentence provides useful information without fluff. The format is efficient for an agent to parse and act upon.

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

  Completeness5/5

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

  For a read-only get tool, the description is complete: it states the purpose, lists all parameters with constraints, and describes the return format. The output schema is essentially embedded in the description, covering what the agent needs to know to call and interpret results. No critical information is missing for a straightforward read operation.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must explain parameters. It does so clearly: limit with a max constraint (<=1000), offset as pagination offset, and filter_nm_id as an optional single nmID. This adds meaning beyond the schema, which only provides types and defaults. The description clarifies the purpose and constraints of each parameter, though it doesn't elaborate on what nmID represents, which is a minor gap given domain context.

  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's purpose: 'Get current prices and discounts for products'. It identifies the specific API ('Discounts-Prices API') and the resource (products). This distinguishes it from sibling tools like wb_set_price (which sets prices) and other get tools (e.g., wb_get_sales, wb_get_stocks) that target different resources. The verb 'Get' and resource 'prices and discounts' are specific and unambiguous.

  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 explains how to use the tool via parameters and return format but does not explicitly state when to choose this over alternatives. While the read-only nature and resource scope are clear, there is no direct mention of when not to use it or when a sibling like wb_set_price would be appropriate. The usage context is implied but not stated explicitly, leaving the agent to infer selection based on the tool name and siblings.

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

• wb_get_workflowA
  4.3/5.0
  Behavior3/5

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

  Annotations already include readOnlyHint=true, so the safety profile is covered. The description adds useful detail about the returned content, such as ordered steps and common mistakes, but does not disclose things like auth requirements, error behavior, or rate limits. This is acceptable for a simple read-only getter, but not exceptional.

  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 dense sentences: the first states what is returned, the second documents the argument. There is no filler or repetition, and the most important information is front-loaded.

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

  Completeness5/5

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

  With one required string parameter, an output schema, and a readOnly annotation, the description provides everything needed to invoke the tool: it explains the return contents and tells the agent where to get the workflow name. No additional context is missing.

  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 schema provides only a string 'name' with no description, so the 0% schema coverage means the description must compensate. It does so by explaining that 'name' is a workflow name and pointing to {svc}_list_workflows for valid values. This is sufficient for a single simple parameter, though no format or example is given.

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

  Purpose5/5

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

  The description states a specific verb and resource: 'Return the full plan for one workflow' and enumerates the contents (ordered steps, operation_id, why, interpretation guidance, mistakes). This clearly distinguishes it from sibling tools like wb_list_workflows, which list workflows rather than retrieve one plan.

  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 implies the right usage context: use it when you need the full plan for a single workflow, not a list. The Args note 'see {svc}_list_workflows' tells the agent where to obtain a valid name. It could more explicitly contrast with alternatives, 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.

• wb_call_rawA
  4.4/5.0
  Behavior4/5

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

  Annotations already mark this as destructive-capable, but the description adds useful context: safety is determined per-call by HTTP verb, DELETE is destructive, and confirmation flags are required. It also discloses the return envelope. 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?

  The description is compact and well-organized: purpose first, safety rule second, then a clean Args list, and return format last. Every sentence adds necessary information with no fluff 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?

  For a raw arbitrary-endpoint tool with 7 parameters and high complexity, the description covers all major invocation concerns: path format, method verb, host, query, body, confirmations, and response shape. Minor ambiguity remains around exactly when each confirmation flag is required, but the reference to wb_call_method's rules mitigates this.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description carries full parameter-documentation burden. It compensates by explaining method, path format with an example, host default, query, body, and confirmation flags, adding meaning beyond bare schema titles.

  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 'Execute ANY endpoint, even ones not in the catalog', which is a specific verb-plus-resource statement and immediately distinguishes this tool from catalog-scoped siblings like wb_call_method. The 'full API coverage' phrase reinforces its unique role.

  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 clearly implies the tool is for endpoints outside the catalog and explains safety based on HTTP verb. It references wb_call_method's confirmation rules, giving a link to sibling behavior, though it does not explicitly state 'use wb_call_method for catalogued endpoints'.

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

• wb_get_salesA
  4.4/5.0
  Behavior4/5

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

  Annotations already mark readOnlyHint and openWorldHint, so read-only status is covered. The description adds meaningful behavioral context: a rate limit of 1 req/min, the JSON success/error envelope shape, and the row-level fields returned. This goes beyond the annotations and helps set expectations for callers.

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

  Conciseness5/5

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

  The description is compact and front-loaded: one sentence states the core purpose and API context, then Args and Returns are clearly sectioned. There is no filler; each line contributes useful information for invoking the tool.

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

  Completeness5/5

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

  Given the tool's simplicity (2 parameters, one required) and the presence of an output schema, the description covers everything an agent needs: purpose, parameter formats, flag behavior, rate limiting, and return envelope. No critical gap is evident.

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

  Parameters5/5

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

  Schema description coverage is 0%, so the description carries full responsibility for parameter meaning. It defines date_from with RFC3339/MSK format and concrete examples, and explains flag values 0 and 1 with their exact behavioral distinction. This is essential and well done.

  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: 'Get Wildberries sales and returns since a date.' This clearly distinguishes it from sibling tools like wb_get_new_orders or wb_get_stocks, even without comparing schemas. The purpose is immediately identifiable.

  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 — fetching sales and returns relative to a date — and explains the flag semantics for incremental vs dated retrieval. However, it does not explicitly state when to choose this tool over siblings such as wb_get_new_orders or wb_get_prices, nor does it mention exclusions or prerequisites.

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

• wb_list_cabinetsA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, and the description reinforces this by stating secret values are never returned. It also discloses the exact JSON return shape, which adds behavioral context beyond the annotations. 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?

  The description is compact: two sentences, front-loaded with the core purpose, followed by a precise return-format note and a security guarantee. Every sentence earns its place.

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

  Completeness5/5

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

  For a zero-parameter read-only tool with an output schema, the description is complete. It explains the purpose, the return shape, and the security behavior. Nothing an agent needs to call it correctly is missing.

  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 there is no parameter semantics burden. The description still adds value by explaining what the returned fields mean (active, cabinets, fields_needed), which is useful for interpreting the output.

  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 lists configured cabinets for a marketplace and identifies which one is active. It uses a specific verb ('List') and resource ('cabinets'), and the mention of 'active' distinguishes it from related cabinet-management siblings like wb_add_cabinet or wb_use_cabinet.

  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 implies this is the read-only inspection tool for cabinet configuration, and the sibling list shows many cabinet-mutating tools (add/remove/use/set_key) that this is not. It doesn't explicitly state when to use it versus alternatives, but the context is clear enough for an agent to select it for listing/status purposes.

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

• wb_mapA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the key behavioral trait: the tool changes output based on whether an entity argument is provided, showing the whole map vs. one entity's methods. It does not describe return formatting, but an output schema exists, so that burden is already lifted.

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

  Conciseness5/5

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

  Three sentences, each earning its place: first states the purpose, second explains the two invocation modes, third tells the agent when to use it. The 'you are here' and 'orients you fast' flourishes are brief and serve the orientation concept without bloat. Front-loaded and readable.

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

  Completeness5/5

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

  For a read-only map tool with one optional parameter and an output schema, this description is complete. It tells the agent how to get the big picture, how to drill into a specific entity, and when to reach for it. The ellipsis in the entity examples invites calling the tool itself to discover valid values, which is exactly how such a map tool should be used.

  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 schema only says 'entity' is an optional string with a default of '', which is nearly meaningless. The description compensates by explaining that omitting it yields the full map and that values like 'reviews', 'stocks', 'prices', or 'orders' filter to one entity's methods. It gives useful examples, though it doesn't enumerate all valid values.

  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 defines a specific purpose: an orientation map of the API's business entities with their go-to methods. It distinguishes this tool from sibling lookup tools like wb_search_methods and wb_describe_method by positioning it as the high-level 'you are here' overview. The verb-plus-resource structure ('Call with no args to see the whole map'; 'pass entity=... to list every method') leaves no ambiguity.

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

  Usage Guidelines4/5

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

  The description explicitly tells the agent when to call it: 'Use this before guessing — it orients you fast.' It also gives two concrete usage modes: no args for the full map, and an entity value to focus on one entity. It does not name alternative tools or state when not to use it, so it just misses a 5.

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

• wb_list_workflowsA
  4.6/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value by specifying the return format (JSON array with objects containing name, category, when_to_use) and that it returns only ready-made recipes, which is useful context for agents deciding whether to use this or another 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 concise, with three sentences that each carry weight: what it does, what it returns, and how to proceed to get details. It is front-loaded with the core purpose and immediately points to the sibling tool.

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

  Completeness5/5

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

  Given zero parameters (no schema complexity) and the presence of an output schema, the description is complete. It tells the agent what the output looks like (JSON with name, category, when_to_use) and directs them to wb_get_workflow for details, covering all necessary information for correct invocation and usage.

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

  Parameters5/5

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

  The tool has zero parametersanding schema coverage is 100% (n/a), the description clearly explains the return structure and the purpose. Even though there are no parameters to document, the description compensates by clarifying what the returned JSON contains, which is essential for the agent to use the output.

  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 lists ready-made analytical workflows (recipes) for the marketplace, with a specific verb ('List') and resource ('workflows'). It distinguishes itself from the sibling wb_get_workflow by noting that get_workflow fetches the full plan for one workflow, so the agent can tell them apart.

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

  Usage Guidelines4/5

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

  The description explicitly says to use {svc}_get_workflow to fetch the full step-by-step plan for one workflow, providing clear routing to the alternative. It does not mention when not to use this tool (e.g., when a specific workflow is needed), but the context is clear enough for a listing tool.

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

• wb_fetch_allA
  4.8/5.0
  Behavior5/5

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

  The description goes well beyond the readOnlyHint/openWorldHint annotations by disclosing automatic cursor/offset/last_id handling, catalog-derived array paths, the max_items hard cap, default 10000, and the exact JSON return shape. This gives the agent a strong behavioral model without any 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?

  The description is dense but every sentence earns its place: purpose, handled styles, parameter semantics, and return shape are organized in a clear, front-loaded structure. No filler or redundant repetition of schema information.

  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 7-parameter tool with an output schema, the description is complete: it explains all parameters, defaults, behavioral safeguards, and the response envelope. The agent has enough to select and invoke the tool correctly, and the output schema covers return field details.

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

  Parameters5/5

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

  Input schema coverage is 0%, but the description's Args section documents all seven parameters: operation_id is a read endpoint from the catalog, cursor fields are managed, items_path overrides the array path, limit sets page size, and max_items caps output. This fully compensates for the schema's lack of 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 opens with a precise verb+object: 'Auto-paginate a read endpoint and return every row in one response.' It clearly distinguishes this from one-shot call tools by emphasizing full pagination, and it names the handled pagination styles and the catalog-driven array path so an agent knows what the tool is for.

  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 first sentence gives clear context: use this when you want every row from a read endpoint, not just a single page. It does not explicitly name alternatives like wb_call_method or state when not to use it, but the auto-pagination framing makes the primary use case unmistakable.

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

• wb_get_stocksA
  4.8/5.0
  Behavior5/5

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

  Annotations already mark readOnlyHint and openWorldHint, but the description adds valuable behavioral context beyond those: it explicitly states the rate limit (1 req/min), clarifies that stocks are a point-in-time snapshot with no history, and describes the return envelope. This is rich, non-contradictory detail that helps the agent set expectations.

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

  Conciseness5/5

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

  The description is compact and well-structured: a one-line purpose, a note on snapshot semantics, then Args and Returns sections. It front-loads the core purpose and rate limit, and every sentence adds value—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?

  Given the tool's simplicity (one optional parameter, no required fields) and that an output schema exists, the description covers all essential operational aspects: purpose, rate limit, parameter semantics, and return format. Nothing an agent needs to call it correctly is missing.

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

  Parameters5/5

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

  The schema only declares a default value with zero description coverage, so the description fully compensates. It explains the parameter format (RFC3339 date), its default, and its effect ('returns everything in stock now'). This gives the agent clear, actionable meaning beyond the bare 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 opens with a specific verb and resource: 'Get the current Wildberries stock snapshot.' It clearly identifies the platform (Wildberries) and the data (stock). While it doesn't name sibling tools, the resource is unambiguous and the tool name aligns, so an agent can easily distinguish it from tools like wb_get_sales or wb_get_prices.

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

  Usage Guidelines4/5

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

  The description provides a concrete usage hint: 'Use an early date_from to get the full current set.' This guides parameter selection effectively. However, it does not explicitly state when to use this tool over alternatives (e.g., avito_get_stocks or ozon_get_stocks), though the platform is implied by the name. The hint is useful but not a full when/when-not breakdown.

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

• wb_set_priceA
  4.8/5.0
  Behavior5/5

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

  Beyond annotations (readOnlyHint=false, openWorldHint=true), the description adds important behavioral detail: confirm_write gates the live update, prices 3x below the old one trigger WB quarantine, and the endpoint returns an upload ID to poll via wb_prices_history_tasks. This meaningfully enriches the agent's understanding of side effects and follow-up.

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

  Conciseness5/5

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

  The description is compact and well structured: a one-line purpose, a crucial warning, an args list, and the return contract. No sentence is wasted; the quarantine caveat and polling instruction each carry operational value.

  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 write operation with side effects, the description covers the required confirmation flag, a domain-specific risk (quarantine), all parameter semantics, and the asynchronous response pattern. An agent has everything needed to invoke it correctly and know what happens next.

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

  Parameters5/5

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

  Schema description coverage is 0%, but the description compensates fully: nm_id is defined as the product nmID, price as new base price in rubles (integer), discount as percent 0-99, and confirm_write as the flag that must be true. Units, ranges, and meaning are all supplied, exceeding the bare schema types.

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

  Purpose5/5

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

  Description names a precise action—'Set price and discount for ONE product'—and scopes it to the Discounts-Prices API. The explicit 'WRITE' marker plus 'live price' makes the tool's mutating nature unmistakable, distinguishing it from read-only siblings like wb_get_prices.

  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?

  Description clearly states the mandatory precondition: 'Requires confirm_write=true' and 'must be true to actually send the change.' It gives a concrete consequence (price quarantine) but does not explicitly name an alternative sibling or state when not to use it, so it stops short of full when-vs-alternative guidance.

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

• wb_set_keyA
  4.9/5.0
  Behavior5/5

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

  The description thoroughly discloses behavioral traits beyond annotations. It warns that the key enters the chat transcript, requires explicit acknowledgment, explains the validation against the marketplace, local storage with chmod 600 permissions, and states that the key is never echoed back. These details add significant security-context and operational behavior that annotations alone do not provide. No contradiction with annotations is present.

  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 concise and well-structured. It leads with the purpose, then the critical warning and prerequisite, followed by parameter explanations and outcome. Each sentence adds distinct value; no filler or redundancy. The use of a warning emoji and clear sections makes it easy for an agent to parse quickly.

  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?

  The description covers all key aspects: the action, prerequisites, default behavior for `cabinet`, security consequences, expected outcome (validation and shop name reporting), and local persistence details. For a tool of this complexity (3 params, nested objects, output schema), the description is comprehensive and leaves no critical ambiguity for the agent to call it 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?

  The description adds useful meaning to parameters: it explains the `cabinet` default logic (active cabinet, fallback to shop name, else 'main') and the `i_understand_key_goes_to_chat` requirement. However, the `credentials` parameter is only described as 'dict with the required fields ({fields})' – the '{fields}' placeholder is not resolved, so the actual required fields are not enumerated. Given the schema has 0% description coverage, the description partially compensates but leaves a gap for the credentials structure.

  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's purpose: 'Change / rotate the API key from chat (e.g. the old one expired or leaked).' It specifies the exact action (change/rotate) on a specific resource (API key) and gives a concrete use case. It is easily distinguished from sibling tools like wb_add_cabinet or wb_list_cabinets, and from marketplace-specific variants like ozon_set_key.

  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 explicitly states when to use the tool (key expired or leaked) and provides a clear warning about key exposure in chat, requiring the i_understand_key_goes_to_chat flag. It also names an alternative approach (the installer) for cases where the user wants to avoid key exposure in chat, and recommends using scoped keys and rotation in the seller cabinet. This fully guides the agent on when to use this tool versus alternatives.

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

• wb_add_cabinetA
  5/5.0
  Behavior5/5

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

  The description discloses the key risk ('puts the key into the chat transcript'), the required confirmation flag, the storage location and permissions ('Saved to ~/.marketplace-mcp/cabinets.json (local, chmod 600)'), and that it's never echoed. This adds substantial context beyond the annotations, which only provide idempotentHint=true and destructiveHint=false. No contradictions 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?

  The description is compact yet information-dense, with a clear warning upfront and a structured argument list. Every sentence contributes to understanding or safe usage. The format is easy to scan and front-loads the most critical caution.

  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?

  The tool is a write operation with security implications. The description covers the action, prerequisites, parameter details, side effects, and alternatives. With an output schema present (has output schema: true), return value details are already structured, so nothing essential is missing.

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

  Parameters5/5

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

  Schema coverage is 0%, so the description carries full weight. It explains every parameter: credentials dict with required fields and examples for Ozon and WB, name with fallback behavior, and the mandatory flag. This goes well beyond the bare 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?

  States a specific verb and resource: 'Add or update a cabinet (a named set of API credentials)'. It clearly distinguishes from the many sibling add_cabinet tools for other platforms by specifying WB in the credentials example and the tool name. It also mentions the 'from chat' context, which sets it apart from installer alternatives.

  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 points out a safer alternative: 'The terminal-free safe alternative is the installer (install.py / double-click), where the key never enters chat.' This tells the agent when not to use the tool and what to use instead. It also states the required flag for the risky action.

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