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

Adds substantial context beyond the annotations: the security warning about the key entering the chat transcript, the persistence location (~/.marketplace-mcp/cabinets.json, chmod 600, never echoed), and the add-or-update semantics that align with idempotentHint=true. It does not restate the safety profile already covered by annotations, which is the right call.

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?

Front-loaded with the security warning, then the alternative, then structured Args. Dense and mostly waste-free, though the literal '({fields})' and doubled-brace '{{"token": "..."}}' templates read as unfilled formatting artifacts that add slight noise.

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 mutating, nested-object tool with an output schema present, the description covers everything the agent needs: the write target, the security tradeoff, the required consent flag, per-service credential shapes, and naming fallback. Return values are correctly left to the output schema.

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 carry the load, and it does: credentials is explained with per-service concrete examples (Ozon client_id/api_key, WB token), name documents its default-naming fallback behavior, and the flag's required value is spelled out. This fully compensates for the empty schema descriptions.

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 verb+resource and defines the resource inline ('a named set of API credentials'), which disambiguates it from the credential-related siblings like sbis_set_key and sbis_use_cabinet. The 'from chat' qualifier and the installer contrast make the tool's identity unambiguous.

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?

Explicitly frames when to use this (chat-based add/update) versus the recommended alternative (install.py / double-click, where the key never enters chat). It also states the precondition (i_understand_key_goes_to_chat=true) required to proceed, so routing and gating are both covered.

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 already declare destructiveHint=true and openWorldHint=true, so the burden is lighter, and the description still adds real context: the two-stage confirmation gate and the fact that an unconfirmed call sends nothing. The returned envelope shape ({ok, status, data} or error) is also disclosed. It does not cover auth requirements or rate limits.

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?

Front-loads the core action and conditional requirements in three short lines, then an Args block. The Args block partially restates the schema property names, which is mild redundancy, but nothing is padded and ordering is logical.

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 generic, high-blast-radius dispatcher this covers the essentials: what it calls, how to supply arguments, the write/destructive gate, and the return envelope (the output schema exists, so detailed return documentation is unnecessary). Auth/permission prerequisites are the remaining 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?

Schema description coverage is 0%, so the description must carry the load and it does: it explains all six params, including that path_values fill {placeholders} and that body is a JSON request body. Minor ambiguity remains (e.g. exact accepted shape of query/body, how required path_values are discovered).

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 verb+resource: 'Execute one catalog endpoint by operation_id'. This clearly differentiates it from sibling discovery tools (sbis_search_methods, sbis_describe_method) and the raw escape hatch (sbis_call_raw), so an agent can place it in the workflow 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?

Gives explicit gating conditions: write endpoints need confirm_write=true; destructive endpoints need that plus i_understand_this_modifies_data=true, and 'nothing is sent otherwise'. It also points to {svc}_search_methods for obtaining operation_id. It does not explicitly contrast with sbis_call_raw or sbis_fetch_all, so it stops short of full alternative routing.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, openWorldHint=true, but the description adds non-obvious semantics: safety is inferred from the HTTP verb (GET=read, POST/PUT/PATCH=write, DELETE=destructive) and that confirmations gate writes/destructive calls. It also discloses the return envelope. It stops short of auth requirements, rate limits, or what a host override actually permits.

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?

Front-loaded with the key capability, then a structured per-argument list and the return shape; almost every line earns its place. The '{svc}_call_method' placeholder is a small readability wart and the return-shape sentence duplicates the output schema.

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 7-parameter, destructive, open-world tool this covers the essentials: verb-based safety mapping, confirmation gating, all parameters, and the response envelope. Since an output schema exists, the return description is redundant, and auth/prerequisite details are absent, but nothing needed to invoke it 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?

Schema description coverage is 0% across 7 parameters, so the description carries the full burden – and it documents every one (method, path, host, query, body, and both confirmation flags), even giving a concrete path example. The two confirmation flags are named but their exact required values/semantics ('confirmations') remain thin.

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 verb (Execute) and resource (ANY endpoint), and immediately scopes it against the catalog: 'even ones not in the catalog (full API coverage)'. This lets an agent distinguish it from sbis_call_method without opening either 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 phrase 'even ones not in the catalog' implies this is the fallback when the endpoint is not covered by the catalog tool, and it cross-references 'Same confirmation rules as {svc}_call_method'. That gives clear context and an implicit alternative, but it never states the positive rule ('use this only when the catalog lacks the endpoint') nor any exclusions.

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 already cover readOnlyHint=true and openWorldHint=false, so the safety profile is known. The description adds genuinely useful context beyond that: it guarantees secrets are never leaked and documents the return payload shape, though it says nothing about failure modes or side effects.

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?

Three tight sentences, each earning its place: purpose first, the security guarantee second, and the return contract third. No filler or redundancy.

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, read-only readiness check, the definition covers purpose, security behavior, and return shape. Even though an output schema exists, the inline JSON summary makes the contract self-contained.

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 takes zero parameters, which is the baseline-4 case. There is nothing for the description to document or compensate for, and it correctly stays silent on inputs.

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 specific verb ('Check') and resource ('required credentials ... in the environment'), so an agent immediately knows the outcome. It is inherently distinct from siblings focused on calling methods or managing cabinets, but it never explicitly contrasts itself with them, keeping it just 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?

Usage is only implied: an agent can infer this is a pre-flight readiness check, but the description never states when to call it (e.g., before other sbis_* tools) or whether any alternative exists. It gives no explicit when/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?

The annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds the composition of the returned catalog record, which is useful context, but does not disclose any additional behavioral traits such as authentication requirements or source of the operation_id. A 3 reflects that annotations carry the main behavioral burden.

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 front-loaded sentence that lists the record fields without filler. Every clause earns its place by telling the agent what the tool returns.

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?

Because an output schema exists, the description need not explain return values, though it does list them. It still omits how to obtain the required operation_id and any usage context relative to sibling tools, leaving gaps for a read-only metadata lookup.

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% and the description never names the required 'operation_id' parameter or explains its format or source. The phrase 'for one endpoint' loosely implies that the parameter identifies an endpoint, but this is not sufficient compensation for the missing parameter documentation.

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 specific verb ('Return') and a clear resource ('full catalog record for one endpoint'), then enumerates the record's fields. It does not name or explicitly contrast with siblings like sbis_search_methods or sbis_call_method, so it falls short of full sibling differentiation.

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 states what is returned but gives no guidance on when to use this tool versus alternatives such as sbis_search_methods, sbis_call_method, or sbis_get_section. It implies the tool is for a known single endpoint, but offers no conditions, prerequisites, or exclusions.

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?

Beyond the readOnlyHint already declared, the description adds meaningful traits: cursor/offset/last_id/page styles are handled automatically, cursor fields are managed on the caller's behalf, and max_items enforces a context-protecting cap with a truncation signal. These are behavioral facts not derivable from 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.

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

Front-loaded with the core behavior, then pagination styles, then a compact Args list and return shape. Almost every line earns its place; only the explicit return-shape summary is arguably redundant given the output schema exists.

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 7-parameter auto-pagination wrapper, the description covers the operation contract, the managed pagination behavior, the safety cap, and the truncation semantics. An output schema exists, so the added return-shape line is supplementary rather than necessary, but nothing critical 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?

Schema coverage is 0%, so the description carries the full burden, and it largely succeeds: it explains operation_id (a catalog read endpoint), query/body/path_values (base params with cursor fields managed), items_path (override of the auto-derived array path), and the limit/max_items roles with defaults. Minor gaps remain around units/format details, but the intent of every parameter is conveyed.

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 verb and outcome ('Auto-paginate a read endpoint and return every row in one response'), which clearly distinguishes it from single-call siblings like sbis_call_method. It does not, however, name those siblings directly, so the differentiation is inferable 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?

Usage is implied by 'a read endpoint from the catalog' and the auto-pagination framing, which suggests this is for endpoints that would otherwise need manual paging. But there is no explicit when-to-use/when-not guidance and no reference to alternatives such as sbis_call_method or sbis_call_raw.

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 already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the shape of the returned records, but since an output schema already exists, that adds limited new behavioral context (no pagination, ordering, or scope limits 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?

Two compact statements with the core action front-loaded; the Args/Returns docstring format is slightly mechanical but contains no filler.

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 single-parameter read tool with an output schema, the description covers the action, the parameter source, and the return shape. What an agent needs to invoke it correctly is present, with only routing guidance against siblings left 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?

Schema coverage for 'section' is 0%, so the description must compensate, and it does: it explains the parameter is a section name, points to the listing tool that yields valid values, and gives a concrete example ('statistics'). That is meaningfully more than the bare string type in the schema.

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 verb and resource: 'List all endpoints in one section', which is more precise than a bare name restatement. It implicitly distinguishes itself from sbis_list_sections (which lists sections) by referring the caller to that tool for section names, though the contrast is not made fully 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?

It tells the agent where to get a section name ({svc}_list_sections), which is implied usage guidance, but it does not say when to prefer this over sbis_search_methods or sbis_describe_method, nor state any exclusions.

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 already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered elsewhere. The description still adds real behavioral value by disclosing the return shape (active/cabinets/fields_needed) and the security guarantee that 'Secret values are never returned'.

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 lines, front-loaded with the purpose and the active-cabinet detail. The explicit 'Returns JSON: {...}' line is slightly redundant given an output schema exists, which is the only minor waste.

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-argument read tool with an output schema and clear annotations, the description supplies everything critical, including the marketplace scoping and the secret-exposure guarantee. It omits any note about auth prerequisites, which is a minor gap given the presence of sbis_check_auth and sbis_set_key siblings.

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 takes zero parameters, so there is no parameter semantics burden; baseline is 4. Nothing in the description misdefines or implies hidden inputs.

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 verb and resource ('List configured cabinets') scoped to 'this marketplace', and adds the distinguishing detail of reporting which cabinet is active. It does not explicitly name the siblings it is not (e.g., sbis_use_cabinet / sbis_add_cabinet), but the purpose is unambiguous on its face.

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: an agent can infer this is a discovery step before sbis_use_cabinet, sbis_remove_cabinet, or any cabinet-scoped call. There is no explicit when-to-use statement, no prerequisites (e.g., auth state), and no stated exclusions.

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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the per-section count but doesn't mention pagination, response format, or ordering – marginal added context beyond structured fields.

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?

One sentence, front-loaded with the verb and resource, and includes the key extra detail (endpoint counts) without waste.

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 an output schema present, the description needn't explain return values, and the tool has no inputs. The definition is adequate for a simple list operation, though it could mention whether sections are nested or if counts are exact.

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?

Zero parameters, so no parameter semantics to convey. Baseline for a parameterless tool is 4; nothing misleading or missing on this dimension.

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 clear verb+resource ('List API sections') and adds that it returns endpoint counts per section. However, it does not explicitly distinguish from siblings like sbis_get_section, which likely retrieves a single section, leaving some differentiation to inference.

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?

No guidance on when to use this versus alternatives. An agent must infer that this is for a top-level overview before drilling into a specific section with sbis_get_section.

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 already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: it discloses both the zero-arg and entity-arg modes and characterizes the returned content ('whole map', 'list every method'). No info on ordering or size limits, but this is solid additional value.

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?

Front-loaded with the core purpose, then the two invocation modes, then a routing directive. Parenthetical asides are minor; every sentence carries weight. Slightly informal but efficient.

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?

An output schema exists, so return values need not be explained. For a simple one-param, read-only orientation tool, the description covers purpose, both modes, and when to use it. Nothing an agent needs to invoke it 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?

Schema description coverage is 0%, so the description must carry the single entity parameter, and it does: it explains the empty/default case and gives concrete example values (reviews, stocks, prices, orders). It doesn't enumerate the full valid set, but it compensates well for the undocumented schema.

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: mapping the business entities the API covers and the go-to methods for each. An agent can tell this is an orientation/discovery tool. It doesn't explicitly contrast itself with sibling discovery tools like sbis_search_methods or sbis_list_sections, so it stops 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?

Clear invocation guidance: call with no args for the full map, or pass entity="reviews" (etc.) to list one entity's methods. 'Use this before guessing — it orients you fast' gives when-to-use context. It lacks an explicit comparison to the other lookup siblings (search_methods, describe_method), so not 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new behavior beyond the annotations: deleting the currently active cabinet promotes another to active. It stops short of saying whether the deletion is recoverable or what permissions are required.

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, front-loaded with the action and then the key side effect. The 'Args: name' block is somewhat redundant against an already-documented single required parameter, but it costs little.

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?

An output schema exists, so return values need not be described, and the annotations cover the destructive nature. For a one-parameter mutation tool the description covers the essential action and side effect; only reversibility and permission requirements are left 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?

Schema description coverage is 0%, so the description carries the burden for the single parameter, and it does define it as 'the cabinet to remove'. However it gives no format hints (exact name string, case sensitivity) or a pointer to where valid names come from (sbis_list_cabinets), so it only partly compensates.

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 verb and resource (delete a stored cabinet), and the sibling set (add_cabinet, list_cabinets, use_cabinet) makes the scope unambiguous by naming convention. It does not explicitly contrast itself with a sibling, but the operation is unmistakable.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as use_cabinet or list_cabinets for looking up valid names. The only context given is a side-effect note, which is behavioral rather than usage-oriented.

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 already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful context (bilingual RU/EN search, best-first ranking) but says nothing about auth requirements, result caps, or empty-result 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?

Front-loads the core action in the first sentence and keeps the Args block tight. Slight redundancy in listing both the parameter names and their schema titles, but no wasted prose.

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 an output schema present, return values need not be detailed, and annotations cover safety, so the description is nearly complete for a two-param discovery tool. Only auth/precondition context is absent.

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%, so the description must compensate, and it does: 'query' is explained as free text with bilingual examples, and 'limit' is given a 1-50 range that the schema lacks. It omits the default (15) present in the schema, a minor gap.

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 verb+resource: searching the endpoint catalog by keyword. It contrasts clearly with the call/describe siblings by nature of being a discovery tool, but it never names any sibling to route the agent 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?

Implies its usage (keyword lookup of endpoints) but gives no explicit when-to-use, no mention that it precedes sbis_describe_method or sbis_call_method, and no exclusions. Usage is inferred rather than guided.

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 only declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false); the description adds the materially important behavior: the key is written into the chat transcript, requires an explicit consent flag, is validated against the marketplace, saved with chmod 600, and never echoed back. This is exactly the extra context annotations cannot carry.

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?

Front-loads the verb and the warning, then per-argument notes. Well organized and mostly tight, though the placeholder '{fields}' and the multi-clause cabinet default add a little noise.

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?

An output schema exists, so return values need not be documented, yet the description still covers the success path (marketplace validation, shop name reported) plus storage and consent requirements. Nothing an agent needs before invoking 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?

Schema coverage is 0%, so the description carries the load: cabinet defaulting behavior (active cabinet, else shop name, else 'main') and the meaning/requirement of i_understand_key_goes_to_chat are both explained. The credentials parameter is only described as 'dict with the required fields ({fields})', an unresolved placeholder that leaves the nested contract opaque despite additionalProperties: true.

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 verb+resource+channel ('Change / rotate the API key from chat'), which is unambiguous and separable from sibling cabinet tools like sbis_add_cabinet or sbis_use_cabinet. An agent can identify exactly what this does 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?

Gives a concrete trigger ('the old one expired or leaked') and names the preferred alternative (the installer, where the key never enters chat). It does not, however, relate this tool to the sibling cabinet/key-management tools, so the routing picture is incomplete.

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 already declare readOnlyHint=false, idempotentHint=true, and openWorldHint=false. The description adds meaningful context beyond them by disclosing the session-level side effect that all later calls adopt the activated credentials, which is the key behavioral trait an agent needs.

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, front-loaded sentences with no filler; the core effect ('Switch the active cabinet') leads. The 'Args:' block is slightly formulaic but efficient and not padded.

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 single-parameter state-switching tool with an output schema present, the description covers the action, its effect, and the source of valid input. Return values need not be explained given the output schema.

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 carries the burden. It states that 'name' is the cabinet to activate and points to {svc}_list_cabinets for valid values, which meaningfully compensates for the undocumented schema field.

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 verb and resource ('Switch the active cabinet') that immediately distinguishes it from siblings like sbis_add_cabinet, sbis_remove_cabinet, and sbis_list_cabinets. The purpose is unambiguous, though no sibling is named 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?

Implicitly conveys when to use it ('subsequent API calls use its credentials') and routes the agent to a companion tool for valid values (see {svc}_list_cabinets). However, there is no explicit when-to-use vs when-not guidance, and alternatives such as set_key are not contrasted.

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