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

It discloses the key behavior beyond annotations: the key enters the chat transcript, a confirmation flag is required, the data is saved to a local file with chmod 600, and it is never echoed. This is valuable risk context that annotations alone do not convey.

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

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

The description is compact, front-loaded with the security warning, and each sentence carries meaningful information: purpose, risk, parameter details, and storage location. The Args block is scannable and avoids redundant restatement of the 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 three-parameter tool with a nested credentials object and no schema-level descriptions, the description supplies all needed context: what credentials look like, optional naming behavior, the required ack flag, and where the data lands. An agent can invoke the tool correctly without extra inference.

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?

With 0% schema description coverage, the description takes full responsibility for explaining parameters. It provides concrete credential examples for Ozon and WB, explains the name fallback behavior, and clarifies that i_understand_key_goes_to_chat must be true, which is essential for correct invocation.

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 opens with a specific verb and object: "Add or update a cabinet (a named set of API credentials), from chat." It clearly distinguishes this credential-storage tool from siblings like vk_use_cabinet and vk_remove_cabinet by focusing on the add/update semantics and the stored cabinets.json file.

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

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

The description gives clear context: this is the in-chat path for adding a cabinet, and it names the installer as the safe terminal-free alternative. It does not explicitly contrast with sibling tools like vk_set_key, so it falls just short of fully explicit when-to-use versus alternatives.

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=true, so the description's safety-critical addition is modest but real: 'Reads only: nothing here changes data, so it runs without confirmation.' It also discloses the return shape as a JSON success envelope or error envelope. This adds value beyond 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.

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

The description is tightly structured with a front-loaded purpose, a short safety note, explicit sibling routing, and a concise parameter list. Every sentence contributes either to invocation, selection, or behavior — there is no padding.

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 catalog-driven read tool with an output schema already present, this description covers everything needed to invoke it correctly: target API, operation_id source, param usage, read-only behavior, and return shape. It also routes to write/delete alternatives, making the surrounding toolset navigable without further research.

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 semantic weight. It does: operation_id is traced to the catalog, path_values maps to path placeholders, query is identified as query-string parameters, and body is explained as a JSON body used by a few read endpoints. These are generic but correct meanings that the raw schema does not provide.

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 opens with a clear verb and resource: 'Execute one READ endpoint from the catalog by operation_id.' It explicitly contrasts itself with vk_write_method and vk_delete_method, making the tool's scope and read-only purpose unambiguous even before looking at 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?

It explicitly states when to use this tool: for read-only catalog endpoints, and it names concrete alternatives for mutation and deletion ('To change data use vk_write_method, to delete use vk_delete_method'). It also tells the agent where to get operation_id from ('see vk_search_methods'), removing ambiguity about prerequisites.

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 annotation, the description explicitly promises not to reveal secret values and clarifies that it only reports which variables are set. This is valuable safety-relevant context for a credential-checking tool.

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 short, purposeful sentences front-load the main purpose, then add a key limitation and the return contract. There is no filler or redundant content.

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

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

For a no-input, read-only tool, the description is complete: it says what the tool does, what it does not do, and exactly what JSON it returns. 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?

The tool has zero parameters, so there is no input semantics to document. The baseline of 4 applies because parameter meaning is not applicable here.

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

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

States a specific action: check whether required credentials are present in the environment. It clearly distinguishes this readiness check from the sibling operation tools that call, write, or modify VK data.

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 purpose implies an auth preflight check before using credential-requiring VK tools, and it contrasts with credential-management siblings like vk_set_key. It does not explicitly name alternatives or exclusions, but the intended usage context is clear.

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 valuable context: it requires two confirmation flags, sends nothing without both, and returns a JSON envelope. It also warns that the endpoint 'deletes or irreversibly changes data,' which goes beyond the annotation. Minor gap: it doesn't describe error behavior beyond 'error envelope' or mention auth requirements, but the confirmation mechanism is well disclosed.

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

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

The description is compact and front-loaded with the most important fact (destructive). The confirmation requirement is stated early, and the parameter list is terse but complete. Every sentence earns its place; no filler or repetition of schema titles.

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

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

The tool is a generic destructive executor with an output schema, so the description covers the key operational needs: target API, required confirmations, parameter meanings, and return envelope. It could mention that operation_id must be discovered via vk_search_methods (it does) and could clarify error handling, but the output schema and annotations fill some gaps. Overall it is complete enough for an agent to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains each parameter in plain terms: operation_id comes from the catalog, path_values fill {placeholders}, query is query-string parameters, body is JSON, and the two booleans must be true. This adds meaning beyond the bare schema titles. It doesn't give detailed formats for query/body, but for a generic passthrough tool that is acceptable.

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

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

The description states a specific verb ('Execute one DESTRUCTIVE endpoint: deletes or irreversibly changes data') and names the target API. It clearly distinguishes this from sibling tools like vk_call_method and vk_write_method by emphasizing destructive operations. The title and annotations reinforce the destructive nature, so an agent can tell this tool apart without opening schemas.

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

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

The description explicitly states the required confirmation flags and says 'nothing is sent without both,' giving clear conditions for use. It does not explicitly name alternatives or say when not to use this tool, but the destructive framing and sibling names (vk_call_method, vk_write_method) imply the distinction. It could be stronger with an explicit 'use vk_call_method for non-destructive calls' note.

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 mark this as destructive (destructiveHint=true, readOnlyHint=false), so the description's job is lighter. It adds useful behavioral context beyond the annotations: both confirmation flags are mandatory, the method must be DELETE, and it returns either a success JSON envelope or an error envelope. It could mention irreversibility or auth requirements, but the confirmation flags and destructive hint cover the main safety concern.

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 front-loaded with the core purpose, then immediately gives the key constraint ('DELETE only') and required safety flags. The Args section is terse, organized, and maps cleanly to the schema. No sentence is wasted, and the return envelope is stated at the end without unnecessary elaboration.

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

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

The description covers all invocation essentials: path format, method, host, query, body, mandatory confirmation flags, and expected return shape. The output schema exists, so return values need no further detail. It falls just short of full completeness because it does not explicitly route an agent to vk_delete_method for catalog-managed paths, nor does it state auth prerequisites or irreversibility beyond the confirmation flags.

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 full burden for parameter semantics. It successfully explains all seven parameters: path format, method constraint, host default behavior, query/body purpose, and the mandatory truthiness of both confirmation flags. This is especially valuable because the schema defaults both confirm flags to false, and the description overrides that by marking them required.

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

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

The description states a specific verb and resource: 'Delete data at ANY path, including paths not in the catalog.' This clearly distinguishes the raw delete tool from sibling tools like vk_delete_method, and explicitly constrains the method to DELETE. An agent can immediately understand what operation this tool performs and how broad its scope is.

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

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

The description gives explicit invocation constraints: DELETE only, confirm_write=true, and i_understand_this_modifies_data=true. It also clarifies that the tool works outside the catalog, implying it is for raw or non-catalog paths. It does not explicitly name alternatives or state when not to use it, but the scope is clear enough from the ANY-path wording.

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 that the full catalog record is returned (method, host, path, scope, safety level, pagination, rate limit), but says nothing about whether an unknown operation_id errors or what happens for non-catalog endpoints.

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

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

A single dense sentence front-loads the purpose and the returned field list. It is efficient, though the long comma-separated field list is slightly list-heavy.

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-value detail is not required, and the field enumeration gives a useful preview. The main gap is guidance on selecting this tool over its siblings and the operation_id's provenance.

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

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

Schema coverage is 0% and the single operation_id parameter is undocumented, so the description could have compensated but does not explain where an operation_id comes from or its format. Baseline 3 for a one-param tool.

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?

Clear verb+resource: 'Return the full catalog record for one endpoint', and the enumerated fields make its scope concrete. It does not explicitly distinguish itself from vk_get_section or vk_search_methods, so it falls short of a 5.

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

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

Usage is implied by being the per-endpoint detail lookup against siblings like vk_list_sections and vk_search_methods, but there is no explicit when-to-use, when-not-to-use, or named alternative.

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 annotations (readOnlyHint, openWorldHint), the description discloses meaningful behavior: it handles multiple pagination styles, manages cursor fields, reads array paths from the catalog, enforces a configurable max_items cap, and returns a structured JSON with a truncated flag. This is rich context for an agent selecting or invoking the tool.

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 well-organized: a one-sentence high-level summary, a compact explanation of supported pagination styles, and a terse Args list followed by the return shape. Every sentence adds useful information with 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 7-parameter tool with no schema descriptions, the description is complete enough for correct invocation: it covers operation selection, parameter roles, the automatic catalog lookup, pagination behavior, the safety cap, and the exact return format. The output schema being present further reduces the need for more detail.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: every parameter is explained in the Args section, with added semantics such as 'cursor fields are managed', 'override the array path', 'page size to request', and 'hard cap to protect context'. 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.

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

The description opens with a specific action: 'Auto-paginate a read endpoint and return every row in one response.' This clearly identifies the verb, resource type and scope and distinguishes it from siblings like vk_call_method or vk_get_raw, which are not auto-paginating or are write-capable.

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 gives clear context by requiring operation_id to be 'a read endpoint from the catalog' and explicitly states the auto-pagination behavior, so an agent knows to use it when all rows from a read endpoint are needed. It does not name alternatives or provide an explicit 'when-not-to-use, but the read-only, all-rows purpose is well scoped.

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 provide readOnlyHint and openWorldHint, so the burden is lower. The description adds concrete behavioral details: only GET/HEAD/OPTIONS, host override behavior, body rarity on reads, and the success/error response envelope. It does not detail auth failures or rate limits, but those are not critical given the output schema and annotation context.

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 information-dense but well organized: purpose first, usage routing second, then a compact parameter list followed by return format. Every line serves a purpose and nothing is redundant.

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 raw HTTP read tool, this covers all necessary call decisions: target API, path construction, allowed methods, host override, query/body usage, and return shape. Combined with annotations and the provided output schema, the agent has what it needs to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must fully compensate. It does: path must begin with '/', method defaults to GET and must be safe, host is an override, query is for query-string parameters, and body is a rare JSON request body on reads. This adds real meaning far beyond the bare schema titles.

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?

Description states a specific verb/resource/scope: 'Read ANY endpoint by path, including ones missing from the catalog.' It also distinguishes itself from raw write/delete siblings by explicitly naming vk_write_raw and vk_delete_raw. This makes the tool's purpose 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?

The description explicitly says to use this for safe read-only operations and gives alternatives for changes ('To change data use vk_write_raw, to delete use vk_delete_raw'). The phrase 'including ones missing from the catalog' also clarifies when this raw escape hatch is appropriate.

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 the description adds the return format (JSON list of {operation_id, method, path, safety, summary}) and the read-only behavior of listing endpoints. It does not mention auth or error handling, but for a simple read operation the core behavior is transparent and consistent 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.

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

The description is compact and well-structured: a one-line purpose, a clearly labeled argument with example, and a return type specification. Every sentence earns its place with no redundancy or 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?

Given that an output schema exists, the description doesn't need to detail the return structure beyond mentioning the fields, which it does. It also covers the prerequisite (section names) and the parameter meaning. It omits edge cases like empty sections, but for a simple listing tool this is adequate.

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

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

The schema has zero description coverage for the section parameter, so the description fully compensates by explaining its meaning ('section name'), providing an example ('statistics'), and directing the user to vk_list_sections for valid values. This is exactly what an agent needs to supply the correct argument.

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

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

The description states a specific verb ('List') and resource ('endpoints') with a clear scope ('one section'), and it references vk_list_sections for valid section names, distinguishing it from sibling tools that list sections or search methods. It unambiguously conveys the tool's function.

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 provides a prerequisite by pointing to vk_list_sections for section names, which implies a usage step, but it does not explicitly contrast with alternatives like vk_search_methods or explain when to prefer this tool over others. The guidance is implied rather than explicit.

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 provide readOnlyHint=true and openWorldHint=false. The description adds the exact JSON return shape and the security behavior that secret values are never returned, which goes beyond 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.

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

The description is compact and front-loaded: the first sentence states the purpose, the second gives the return shape and safety caveat. There is no filler or redundant restating of annotations.

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 listing tool with an output schema and supporting annotations, the description covers the purpose, return values, and the secret-safety guarantee. Nothing material needed for correct invocation is missing.

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

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

The input schema has zero properties, so the 0-parameter baseline applies. The description usefully tells the agent what the no-argument call returns, so parameter semantics require no further clarification.

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

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

The description states a specific verb ('List'), a specific resource ('configured cabinets'), and the scope ('for this marketplace'), while also noting which cabinet is active. This clearly distinguishes it from sibling tools like vk_add_cabinet or vk_use_cabinet.

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 framing as a read-only listing operation gives clear context for when to call it: to inspect configured cabinets and the active selection. It does not explicitly name alternatives or exclusions, but the purpose and sibling set make the usage obvious.

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 a useful behavioral detail — that each section is returned with an endpoint count — but says nothing about ordering, pagination, scope, or authentication needs, which for a discovery tool would be worth mentioning.

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

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

A single clause with zero waste, front-loading the verb and resource and appending the one piece of return-shape context that matters. Nothing could be cut without losing information.

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?

A no-argument read tool with an output schema, so return values need not be described. The description is sufficient to invoke correctly, though it omits how this sections list relates to the sibling vk_get_section and vk_search_methods in the discovery workflow.

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 and schema coverage is 100%, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-level claims are made or needed.

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

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

The description states a specific verb and resource ('List API sections') plus the payload ('how many catalog endpoints each contains'), which is more informative than the bare tool name. It does not, however, differentiate itself from the closely named sibling vk_get_section or explain the catalog/section model, so an agent must infer the relationship.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as vk_get_section for drilling into a single section or vk_search_methods for finding endpoints. The agent is left to infer the intended first-step role of this tool.

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 the description adds behavioral details: the 'you are here' metaphor, the two modes, and the entity filtering behavior. It doesn't contradict annotations. It could mention that output is a list/overview, but the output schema exists, and the read-only nature is covered. The description adds meaningful context beyond the annotation.

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 sentences, no fluff. The core purpose is front-loaded ('The big picture'), then usage is explained with examples. Every word adds value; it's well-structured and immediately actionable.

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

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

For a tool with one optional parameter, an output schema, and read-only annotations, the description covers everything an agent needs: how to invoke it in both modes, what it returns, and when to use it. 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 must explain the entity parameter. It does: it's optional ('call with no args'), takes values like 'reviews', 'stocks', 'prices', 'orders', and filters the map to one entity's methods. This goes well beyond the bare schema definition of a string with a default.

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

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

The description clearly states the tool's purpose: providing the big picture of business entities and go-to methods. It explicitly distinguishes itself from siblings by being a map/orientation tool, with specific behavior described. Not a tautology; it adds concrete detail.

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 explicitly says 'Use this before guessing' and describes two call modes: no args for the whole map, and entity='...' for listing methods of one entity. This gives clear when-to-use guidance and implicitly tells when not to use it (when you already know the method). It also provides examples of entity values.

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, and the description does not contradict them. It adds genuine value beyond the annotations by disclosing the post-deletion behavior: if the removed cabinet was active, another one becomes active automatically. This is useful state-change context an agent would not otherwise know.

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 crisp sentences plus a one-line Args block. The main action is front-loaded and the side-effect follows immediately. The Args section is mildly redundant with the input schema's 'name' property, but it is the sole source of parameter meaning, so it earns its place.

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

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

For a single-parameter tool with an output schema, the essentials are covered: the delete action and the active-cabinet failover consequence. The main gap is unspecified edge-case behavior (deleting the last cabinet or a non-existent name), but nothing required to invoke the tool correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It does clarify the lone parameter ('name: the cabinet to remove'), which is simple but adequate for a single string identifier. However, it does not specify where the name comes from (e.g., values returned by vk_list_cabinets) or the expected format.

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 ('Delete') and a specific resource ('a stored cabinet'), clearly distinct from siblings like vk_add_cabinet, vk_use_cabinet, and vk_list_cabinets. The added side-effect clause ('If it was active, another becomes active') further pins down what the tool does.

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

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

No guidance on when to use this tool versus alternatives, no prerequisites, and no mention of edge cases such as what happens when deleting a non-existent or the last remaining cabinet. The semantic difference from siblings is inferable but never stated.

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

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

Annotations already provide readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context: it works in Russian and English, returns a JSON list, and orders results best-first. 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.

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

The description is compact and well-structured: a one-sentence purpose followed by a short Args block and a return-format note. There is no filler or repetition of schema information.

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

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

For a simple search tool with two parameters, read-only annotations, and an output schema, the description is complete. It covers what the tool searches, query language support, argument meaning, result limit, and return format.

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 fully compensate. It does: 'query' is explained as free text with concrete examples, and 'limit' is documented as 'max results (1-50).' Both parameters receive meaningful semantics beyond the bare schema types.

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 opens with a specific verb and resource: 'Search the endpoint catalog by keyword.' This directly conveys what the tool does and distinguishes it from sibling tools that list sections or describe individual methods, even without naming them.

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 clearly establishes the tool's use case: finding endpoints by keyword, with examples like 'остатки' and 'update price.' It does not explicitly state when not to use it or name alternatives, but the search context is clear enough for an agent to route appropriately.

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 description discloses critical side effects beyond the annotations: the key enters the chat transcript, it is saved locally with chmod 600, never echoed back, and validated against the marketplace. This goes well beyond the readOnly/idempotent/destructive hints.

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 front-loaded with the purpose and the critical warning, then uses a compact Args section followed by success behavior. Every sentence contributes operational guidance without padding.

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

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

The description covers purpose, side effects, parameter behavior, and success reporting, and an output schema exists so return-value documentation is not required. It is incomplete in one critical spot: the credentials argument's required fields are left as an unresolved placeholder, making it hard for an agent to construct a valid call.

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?

With 0% schema description coverage, the description must compensate, and it explains cabinet's defaulting logic and i_understand_key_goes_to_chat's requirement. However, the only required parameter, credentials, is described only as 'dict with the required fields ({fields})', a placeholder that does not enumerate the actual fields an agent needs.

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 action and resource: 'Change / rotate the API key from chat', and includes concrete scenarios like an expired or leaked key. It does not explicitly contrast itself with a sibling tool, though the API-key resource is unique among the sibling names.

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 gives explicit when-to-use triggers ('old one expired or leaked'), an explicit safer alternative (installer), and a follow-up recommendation (rotate in seller cabinet if exposed). The default-cabinet behavior also explains the common 'my key expired' case.

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 annotations (readOnlyHint=false, idempotentHint=true), the description discloses that switching changes the active cabinet and that credentials from the selected cabinet are used by future calls. This is useful behavioral context about persistent session state.

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 minimal and front-loaded: it states the core action and consequence in the first sentence, then documents the only argument. Every sentence earns its place with no redundant content.

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

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

For a simple one-parameter state-switch tool with an output schema, the description covers the essential behavior, the meaning of the parameter, and where to find valid inputs. Nothing critical is missing for correct invocation.

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

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

The schema has zero description coverage, but the description compensates by defining 'name' as 'the cabinet to activate' and directing the agent to vk_list_cabinets for valid values. For a single-parameter tool this is sufficient, though more detail about name format would be stronger.

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 and resource: 'Switch the active cabinet.' It clearly states the state-changing effect and that 'subsequent API calls use its credentials.' This distinguishes it from sibling tools like vk_list_cabinets or vk_add_cabinet.

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 implicitly tells the agent when to use it: before subsequent cabinet-specific API calls, and it points to vk_list_cabinets as the source for valid names. It does not explicitly name alternatives or exclusions, but the context is clear enough for correct selection.

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 and destructiveHint=false, so the description need not repeat those. It adds value by disclosing the confirm_write safety gate and the return JSON shape (ok/status/data or error envelope). It does not discuss rate limits or auth beyond what's implied, but the annotation coverage plus the added confirm_write detail puts it above baseline.

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 well-structured: a one-line purpose, a target API reference, a critical requirement, sibling differentiation, a compact args list, and a return contract. Every sentence earns its place; no fluff or redundancy. It is front-loaded with the core action and safety condition.

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

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

Given the tool has 5 parameters, an output schema, and no nested objects, the description covers all needed call details: prerequisites, parameter semantics, return format, and how to find operation IDs. It also mentions the error envelope, which is helpful. 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 carries full responsibility for explaining parameters. It does so for all five: operation_id (from catalog), path_values (for placeholders), query (query-string), body (JSON body), and confirm_write (must be true). This fully compensates for the missing 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?

The description states a clear verb ('Execute'), resource ('one WRITE endpoint from the catalog'), and scope ('create or update data'). It also differentiates from siblings by explicitly naming vk_delete_method for irreversible ops and vk_call_method for reads, leaving no ambiguity about what this tool does.

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

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

It provides explicit usage conditions: requires confirm_write=true and nothing is sent without it. It also gives when-not-to-use guidance by pointing to vk_delete_method for irreversible operations and vk_call_method for reads, and directs the agent to vk_search_methods for operation_id lookup. This is comprehensive.

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 annotations (readOnlyHint false, openWorldHint true, destructiveHint false), the description adds that it requires confirm_write=true as a safety gate and restricts allowed HTTP methods (POST, PUT, PATCH). It also discloses the return format ({"ok": true, "status", "data"} or error envelope), providing operational context not present in 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?

The description is compact and front-loaded with the core purpose, followed by the API target, method constraints, and a clear bulleted args list. Every sentence adds value without redundancy or fluff.

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

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

For a tool with 6 parameters but relatively low complexity, the description covers the API target, method constraints, parameter semantics, and return format. It does not mention authentication prerequisites, but sibling tools like vk_check_auth exist and the system likely provides context. The error envelope description is brief but sufficient for an agent to expect standard error handling.

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 description maps each parameter to its meaning and constraints: method (POST/PUT/PATCH), path (full path beginning with '/'), host (override), query (query-string parameters), body (JSON request body), and confirm_write (must be true). Since the input schema has no parameter descriptions (coverage 0%), this is essential clarification and goes well beyond the bare schema titles.

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

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

The description clearly states 'Create or update data at ANY path, including paths not in the catalog', specifying the verb and resource scope. It distinguishes itself from sibling tools that operate on catalogued paths, making its purpose 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?

The description provides no explicit guidance on when to use this tool versus alternatives. It mentions constraints like POST/PUT/PATCH and confirm_write=true, but does not explain scenarios where this raw write is preferred over siblings such as vk_write_method or vk_call_method. Missing when-to-use and when-not-to-use instructions.

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