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

The annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false) are consistent with 'Add or update', and the description adds substantial context beyond them: the key is persisted into the chat transcript, a confirmation flag is mandatory, the data is stored locally at ~/.marketplace-mcp/cabinets.json with chmod 600 permissions, and credentials are never echoed. For a security-sensitive credential tool, this behavioral disclosure is exactly what an agent needs. 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 well-structured: a purpose sentence, a critical security warning with the confirmation flag, an Args section with per-parameter detail, and storage info. Every sentence earns its place given the need to compensate for the schema and the security sensitivity. It is longer than minimal, but that length is justified; the only nit is the unresolved '{fields}' template placeholder which is slightly awkward.

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 security-sensitive tool with nested objects and 0% schema coverage, the description covers purpose, security implications, all three parameters with examples, storage location, and permissions. An output schema exists, so return-value documentation is not needed here. The minor gap is the unresolved '{fields}' placeholder and lack of failure-mode guidance (e.g., invalid credential handling), but overall the agent has everything needed 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?

With 0% schema description coverage, the description carries the full burden and delivers: credentials are explained with concrete per-service examples (Ozon: client_id/api_key; WB: token), name is documented with its fallback behavior (real shop name fetched from marketplace, else 'main'), and the confirmation flag's requirement is stated. 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?

The description opens with a specific verb+resource: 'Add or update a cabinet (a named set of API credentials)'. This clearly distinguishes it from siblings like crpt_list_cabinets, crpt_remove_cabinet, and crpt_set_key. The 'from chat' qualifier also contextualizes the operation's environment. No ambiguity about 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?

The description explicitly flags the security-sensitive context (key enters chat transcript) and names a safe alternative ('the installer (install.py / double-click)'), which helps the agent decide when chat-based credential entry is appropriate. It also states the required precondition flag. However, it does not explicitly contrast against sibling tools like crpt_set_key or crpt_use_cabinet to explain when each is preferred, so the routing guidance is good but not exhaustive.

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 aligns with annotations (readOnlyHint=true) and adds value beyond them: it states no confirmation is required, describes the return envelope ({"ok": true, "status", "data"}), and notes that some read endpoints accept a body. No contradictions with annotations are present.

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: purpose first, followed by API target, read-only note, sibling routing, and parameter definitions. It is concise with no fluff, though the repeated 'Reads only' phrasing adds slight redundancy. The argument list is clear and compact.

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's generic nature, the description covers key usage points: how to get operation_id, how to supply path/query/body, and the response format. It references sibling tools for alternatives. It does not mention authentication prerequisites (though crpt_check_auth exists separately), which is a minor omission, but overall it is adequately complete for an agent to invoke 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?

With 0% schema description coverage, the description carries the burden. It explains operation_id as 'id from the catalog', path_values as 'values for {placeholders} in the path', query as 'query-string parameters', and body as 'JSON request body (a few read endpoints take one). These are basic but functional explanations; more concrete examples or format hints would elevate this score.

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 'Execute one READ endpoint from the catalog by operation_id', which is a specific verb+resource. It distinguishes itself from write and delete siblings by explicitly naming crpt_write_method and crpt_delete_method. The mention of the target API and read-only nature further clarifies its role.

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 clear guidance: it is for read endpoints, explicitly excludes write/delete via sibling tool names, and references crpt_search_methods for obtaining operation_id. However, it doesn't differentiate from other read siblings like crpt_get_section or crpt_fetch_all, so the agent may not know when to use this generic caller versus more specific read tools. This is a minor gap.

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?

Although readOnlyHint=true is provided, the description adds important behavioral detail: it does not reveal secret values, only reports which variables are set. It also discloses the exact return JSON shape. This goes beyond the annotations and clarifies safety behavior useful to an agent.

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

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

The description is two sentences plus a compact JSON snippet. It front-loads the core purpose, then adds the critical security caveat, and finally the return format. Every sentence adds value with no 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 check tool, the description covers the essential context: what it checks, what it does not do, and what the response looks like. The presence of an output schema covers return details, and annotations cover safety. Nothing critical is missing for an agent to use this 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?

With zero parameters, the baseline is 4 per the rubric. The description cannot add parameter-level meaning because none exist. It does not explicitly state 'takes no arguments,' but the empty input schema already fully documents this, and the description focuses on the behavior instead.

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: 'Check whether the required credentials are present in the environment.' This clearly distinguishes it from sibling tools like crpt_call_method or crpt_set_key, and it is not a tautology. The purpose is 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 implies usage as an environment credential pre-flight check, but it does not explicitly instruct when to use it versus alternatives or recommend calling it before other CRPT tools. There are no exclusions or alternative tool references, so usage context is only implied, not 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 declare destructiveHint=true and readOnlyHint=false, so the description adds value by specifying the mandatory confirm_write and i_understand_this_modifies_data flags and stating that nothing is sent without both. It also describes the return envelope. There is 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 well-structured with a clear intro, an Args list, and a return-format note. Each sentence earns its place, and the destructive nature and required flags are front-loaded. It could be slightly more concise, but the format is effective.

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 destructive nature, six parameters, and an existing output schema, the description covers essential usage aspects: required flags, reference to operation_id source, and a summary of the return format. It does not detail authentication or error handling, but those are likely covered elsewhere, making it sufficient 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?

With 0% schema description coverage, the description compensates well by explaining each parameter: operation_id from the catalog, path_values for placeholders, query for query-string parameters, body as JSON, and the two required boolean flags. This adds meaning beyond the bare schema titles and covers all six parameters.

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

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

The description clearly states the tool executes a DESTRUCTIVE endpoint that deletes or irreversibly changes data, which is a specific verb+resource. It distinguishes from non-destructive siblings via the 'DESTRUCTIVE' qualifier and the explicit 'deletes or irreversibly changes data' clause, though it does not name alternative tools directly.

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 that this tool is for destructive operations and references crpt_search_methods for obtaining operation_id. However, it does not explicitly state when NOT to use this tool or name alternatives like crpt_write_method or crpt_call_method, leaving some inference to the agent.

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 it as destructive (destructiveHint=true) and non-read-only (readOnlyHint=false). The description reinforces this by stating 'DELETE only' and the mandatory confirmation flags, adding the key behavioral trait that it works on any path, including those outside the catalog. It also discloses the return format. This 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 reasonably concise given the tool's complexity. The key purpose is front-loaded, and the parameter list is structured clearly. It is slightly long but every sentence adds necessary information about the API target, method constraint, or parameter semantics. No 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 destructive raw-path delete with multiple safety flags, the description covers the purpose, the required confirmations, the method restriction, parameter details, and the return envelope. It even names the target API. The only minor omission is the exact error envelope structure, but that is standard and likely covered by the output schema (which exists).

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. It explains every parameter: path (full path beginning with '/'), method (DELETE), host (override with default), query, body, and the two confirmation booleans that must be true. This adds meaningful semantics that the schema alone does not convey.

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 ('Delete') and resource ('data at ANY path, including paths not in the catalog'), which is specific and distinguishes it from sibling tools like crpt_delete_method that target catalog entries. The raw-path scope is explicitly called out, making 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 provides clear context that this is a low-level DELETE for any path, and it states the required confirmation flags. However, it does not explicitly mention when to avoid this tool or name alternatives (e.g., crpt_delete_method for catalog paths). The context implies its use for raw/uncataloged paths, but lacks explicit 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 safety is covered. The description adds the content of the record (including safety level and rate limit metadata) but says nothing about behavior when operation_id is unknown, error handling, or auth prerequisites.

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 front-loaded sentence with no filler, packing the verb, resource, and returned fields together. The field enumeration is somewhat redundant with the output schema, which keeps it from being maximally efficient, but it is still scannable.

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

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

For a one-parameter read tool this is adequate but not complete: an agent still does not know how to source a valid operation_id or what a failed lookup yields. The output schema carries the return-value burden, so the missing pieces are mainly the identifier's provenance and error behavior.

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 single parameter (operation_id) is undefined in the schema. The description only obliquely implies a one-endpoint selector ('for one endpoint') without naming operation_id, its format, or where to obtain it (e.g., from crpt_search_methods or crpt_map). This is weak compensation for the coverage 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: 'Return the full catalog record for one endpoint,' then enumerates exactly what that record contains (method, host, path, scope, safety level, pagination style, rate limit, params, doc URL). An agent can distinguish it from crpt_search_methods or crpt_call_method by intent, 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?

Use for metadata lookup rather than invocation is implied by 'catalog record' and the read-only field list, but the description never states when to reach for this versus crpt_search_methods, crpt_get_section, or crpt_call_method. No exclusions or prerequisites are given.

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 discloses that cursor fields are managed, the array path is selected from the catalog automatically, a configurable max_items hard cap protects context, and the response includes total_fetched, pages_fetched, and truncated. This gives the agent an accurate model of runtime behavior.

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

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

The definition is compact and well-organized: a one-sentence purpose, a short pagination-style line, an Args list covering all seven parameters, and a return-shape line. There is no filler or 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?

The description is complete enough for correct invocation: it explains how to identify the endpoint, which parameters are base vs managed, how to override the array path, and what the response looks like. The output schema and annotations cover the remaining structured details.

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 carries the full burden and succeeds: every parameter is explained semantically (operation_id, query/body/path_values, items_path override, limit, max_items), including the important caveat that cursor fields are managed automatically.

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 and outcome: 'Auto-paginate a read endpoint and return every row in one response.' It clearly distinguishes this from siblings like crpt_call_method or crpt_get_raw by emphasizing multi-page read aggregation, automatic array-path handling, and support for multiple pagination styles.

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 context is clear: use this when a catalog read endpoint needs to be fully paginated and all rows are wanted. It does not explicitly name alternatives or state 'when not to use,' so it stops short of full 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 description discloses the return JSON envelope, notes that body requests are rare but possible on reads, and lists host override behavior. It complements the readOnlyHint and openWorldHint annotations without contradiction, adding concrete behavioral detail.

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 covers target API, safety, and parameters in a compact, logically ordered list. Every sentence contributes necessary information with no 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?

Given the tool's complexity (5 parameters, open-world path access) and the presence of an output schema, the description covers all invocation details, return format, error envelope, and safety constraints. An agent can call it correctly without further 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?

Despite 0% schema coverage, the description explains each parameter: path must start with '/', method defaults to GET, host overrides the default, query holds query-string parameters, and body is a rare JSON request body. This fully compensates for the schema's lack of descriptions.

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

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: 'Read ANY endpoint by path', and explicitly distinguishes itself from sibling write and delete tools by naming crpt_write_raw and crpt_delete_raw. It also names the target API, making the purpose unambiguous.

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

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

It explicitly states which verbs are safe (GET, HEAD, OPTIONS) and directs the agent to use crpt_write_raw for data changes and crpt_delete_raw for deletions. This is clear when-to-use and when-not-to-use guidance with named 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=false, so the safety profile is covered. The description adds the exact scope ('List all endpoints') and the returned JSON field shape, which is useful but does not go into behavioral detail like pagination, error handling, or auth requirements. This matches the lower bar set by the annotations with modest added 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 purpose is front-loaded, parameters are formatted clearly, and the return type is stated in one line. Every sentence earns its place, with no fluff or repetition.

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

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

For a simple read-only tool with one parameter and an output schema, the description is largely complete: it explains the input, how to obtain a valid input, and the return shape. It could be slightly more explicit about invalid or empty sections, but the low complexity makes this a minor omission.

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. It fully compensates by explaining that section is a section name, tells the agent to look up valid values via crpt_list_sections, and supplies a concrete example. This is more than enough for a single parameter.

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 first sentence, 'List all endpoints in one section,' names a specific verb and resource and clearly scopes the operation to a section. It is immediately distinguishable from siblings like crpt_list_sections (sections, not endpoints) and crpt_search_methods (search, not list-all).

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

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

The description gives clear usage context by directing the agent to crpt_list_sections for valid section names and provides a concrete example ('statistics'). It does not explicitly state when not to use this tool or name alternatives, but the guidance is sufficient for this simple 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?

Annotations already declare readOnlyHint=true, and the description adds useful behavioral details beyond that: the exact JSON shape and the guarantee that 'Secret values are never returned.' This adds meaningful context without contradicting 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?

Two sentences with no filler. The main purpose is front-loaded, the output shape is compactly specified, and the security note is one valuable sentence that 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 zero-parameter read-only listing tool, the description is complete: it states scope, active-cabinet detail, output format, and a security guarantee. 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?

The tool has zero parameters, so the baseline of 4 applies. There are no parameter semantics to document, and the description appropriately focuses on return shape instead.

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: 'List configured cabinets for this marketplace' and adds the distinct detail of reporting which cabinet is active. This clearly separates it from sibling tools like crpt_add_cabinet, crpt_remove_cabinet, and crpt_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 intended use is clear: inspect all configured cabinets and the active selection before operating on cabinets. It does not explicitly name alternatives or exclusions, but the context is strong enough for an agent to select this tool over mutation or selection siblings.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful behavioral detail that each section is reported with its endpoint count, but says nothing about ordering, paging, or whether access requires auth.

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

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

A single compact sentence with the resource and its payload front-loaded. Nothing extraneous.

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-param listing tool with an output schema present and safety hints in annotations, the description is sufficient. It tells the agent what the list contains without needing to explain return shape, which the output schema handles.

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 the baseline is 4. The description correctly implies no inputs are needed and adds no misleading parameter claims.

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 (List) and resource (API sections) plus scope (endpoint counts per section). It is distinguishable from siblings like crpt_get_section and crpt_search_methods, though it doesn't name them 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?

No guidance on when to use this versus alternatives. An agent must infer that this is an exploratory listing tool for discovering sections, but the description never states prerequisites or routing conditions.

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

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

The description discloses the tool's read-only, exploratory behavior through the map metaphor, which complements the readOnlyHint annotation. It adds that calling with an entity filters the map, providing behavioral context beyond the annotation. No contradiction exists.

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, starting with the core purpose. The metaphor 'you are here' adds a slight flourish but doesn't bloat it. Each sentence earns its place; it's efficient without being terse.

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 read-only map tool with an output schema, the description covers both invocation modes and the type of output (map or method list). It doesn't need to enumerate all entities since examples are given. The presence of an output schema means the return format is already specified elsewhere.

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 only defines an optional 'entity' parameter with a default empty string. The description enriches it by explaining the parameter accepts entity names (e.g., 'reviews', 'stocks') and that passing it lists all methods for that entity. This fully compensates for the 0% schema description coverage.

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: it maps business entities to their go-to methods, acting as an orientation aid. It distinguishes itself from sibling tools by positioning itself as the 'map' versus specific method actions. The usage examples ('entity=reviews') and the 'you are here' metaphor make the purpose 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?

It explicitly advises to use this tool 'before guessing' and explains two usage modes: no args for the whole map, or an entity argument to list methods of that entity. While it doesn't name specific alternative tools, the guidance to use it first is clear. It could be more explicit about when not to use it, but the context suffices.

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 mark the tool as destructive (destructiveHint=true), and the description adds a non-obvious behavioral consequence: 'If it was active, another becomes active.' This goes beyond the structured data and helps an agent anticipate side effects. It does not mention error conditions or irreversibility, but the destructive hint covers the core 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 extremely concise: two sentences plus a single parameter explanation. It is front-loaded with the action ('Delete') and resource ('stored cabinet'), and every sentence carries necessary information. 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?

Given the low complexity (one required parameter, no enums, output schema present), the description covers the core action, the side effect about active cabinets, and the parameter meaning. It doesn't discuss error handling, permissions, or what happens if the cabinet doesn't exist, but for a simple delete operation with an output schema, these are not critical gaps. Completeness is strong but not exhaustive.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It explicitly explains `name` as 'the cabinet to remove,' which adds crucial semantic meaning beyond the schema's bare string type. This is sufficient for a single-parameter tool, though it doesn't specify constraints like existing-cabinet requirements or naming 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 clearly states a specific verb and resource ('Delete a stored cabinet') and is clearly distinct from sibling tools like crpt_add_cabinet, crpt_list_cabinets, and crpt_use_cabinet. The added side effect about activation further disambiguates its specific role among cabinet-management operations.

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 the wording 'Delete a stored cabinet,' and the parameter list makes the target explicit. However, it provides no explicit guidance on when to choose this tool over alternatives such as crpt_delete_method or crpt_delete_raw, nor any 'when not to use' conditions. The context is sufficient for a simple tool, but not 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 indicate a safe read-only operation, lowering the baseline. The description adds useful behavioral context beyond annotations: bilingual keyword support, result ordering, JSON list return format, and the 1-50 limit constraint. This is meaningful incremental information.

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 summary followed by clearly formatted args and return behavior. Every sentence earns its place, with no filler or redundant restating of schema fields.

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

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

For a simple two-parameter search tool with an output schema available, the description covers everything needed: purpose, parameter semantics, language behavior, result ordering, and limits. Nothing essential 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 descriptions are 0%, so the description carries the full burden for parameters. It does so excellently: 'query' is explained as free text with concrete bilingual examples, and 'limit' is given a range and default behavior. This adds real meaning beyond the raw 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 clearly states a specific verb and resource: 'Search the endpoint catalog by keyword.' It also adds meaningful scope details (Russian/English support, best-first ordering). It does not explicitly differentiate from sibling tools, but its core action is unambiguous.

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

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

The description implies when to use this tool: whenever you need to find endpoints by keyword. It gives concrete query examples and a limit range, but it does not mention alternatives or when not to use it, so usage context is clear but not explicit about 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 annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description discloses the security-relevant behavior that the key goes into the chat transcript and requires explicit acknowledgment. It details post-execution behavior: 'On success the key is validated against the marketplace and the shop name is reported. Saved locally (chmod 600), never echoed back.' This adds significant context about file permissions and privacy.

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, front-loaded with the purpose, then a critical warning, alternative guidance, and parameter details. Each sentence serves a distinct function (purpose, safety, defaults, success behavior). The use of a warning emoji and bullet-like args formatting improves scannability without excessive length.

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 is thorough overall, covering safety, defaults, validation, and local persistence. An output schema exists, so return values are not required, but the description mentions the reported shop name. The only notable gap is the placeholder for required credential fields, which leaves an agent uncertain about what exactly to pass. Given that this is a security-sensitive operation, more specificity would improve completeness.

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. It thoroughly explains 'cabinet' (default behavior, fallback logic) and 'i_understand_key_goes_to_chat' (must be true). However, 'credentials' is only described as 'dict with the required fields ({fields})' – a placeholder that does not actually enumerate the required fields. This leaves the key parameter underspecified, though the description adds value by indicating a dict and implicit requirements.

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: 'Change / rotate the API key from chat (e.g. the old one expired or leaked).' It clearly differentiates this tool from sibling tools like crpt_list_cabinets or crpt_add_cabinet by its unique purpose of managing keys. The title 'CRPT set / rotate key' reinforces this, and the description adds the chat context.

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 provides when-not-to-use guidance: 'The safe, terminal-free alternative is the installer, where the key never enters chat.' It also advises on post-exposure handling: 'Use a scoped key and rotate it in the seller cabinet if it was exposed.' The description of the default cabinet behavior ('Default: the active one (so "my key expired" just works)') clarifies how to invoke it in a common scenario.

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 that the tool changes the active-cabinet state and that this affects credentials for later calls, going beyond the annotations. It does not describe error behavior for unknown cabinet names, but the core stateful behavior is transparent.

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 short and front-loaded: two imperative sentences state purpose and effect, followed by a single Args line. Every sentence adds necessary information and there is 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 state switch with an output schema and annotations covering idempotency, the description is complete. It explains what the tool does, what changes, and where to find valid input values, so an agent has enough to invoke it correctly.

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

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

Schema description coverage is 0%, so the description carries full responsibility for the 'name' parameter. It explains that name is the cabinet to activate and points the agent to crpt_list_cabinets for valid values, which fully compensates for the schema 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?

The description states a specific verb and resource: 'Switch the active cabinet,' and clarifies the consequence: subsequent API calls use its credentials. This distinguishes it clearly from sibling cabinet tools such as crpt_list_cabinets, crpt_add_cabinet, and crpt_remove_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?

It provides clear usage context: use this tool to change which cabinet's credentials subsequent API calls will use. It does not explicitly state when not to use it or name alternatives, but the invocation scenario is unambiguous.

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

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

The description adds meaningful behavior beyond the annotations: it requires confirm_write=true and states that nothing is sent without it, and it documents the success/error return envelope. It does not contradict the annotations, and while it could add more about auth or partial failure behavior, it gives a solid safety-oriented picture.

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 with a clear lead sentence, safety warning, routing note, compact argument list, and return format. Every sentence adds necessary operational or contextual information 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?

For a generic catalog-driven write tool, the description covers the API target, the mandatory confirmation flag, argument semantics, return format, and sibling routing. With an existing output schema, the description does not need to explain result structures further, and the catalog reference closes the remaining gap for operation-specific details.

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?

Since the schema has 0% description coverage, the description carries the burden of explaining parameters, and it does: operation_id comes from the catalog, path_values fill placeholders, query is query-string parameters, body is JSON, and confirm_write must be true. It explains each argument at a useful level for invoking the tool, though it keeps the details intentionally generic because operation-specific shapes live in the catalog.

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 executes one WRITE endpoint from the catalog to create or update data, naming the specific verb and resource. It also distinguishes itself from the read and delete siblings by name, so an agent can tell them 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?

It explicitly explains where other operations belong: irreversible operations live in crpt_delete_method and reads in crpt_call_method. It also directs the agent to crpt_search_methods for operation_id lookup, giving clear routing guidance and an alternative path for finding the right operation.

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 flag readOnlyHint=false and openWorldHint=true, but the description adds valuable specifics: method restrictions (POST, PUT, PATCH), the mandatory confirm_write flag, and the JSON return envelope. These details are not in annotations and help the agent understand safety and outcome.

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 with the core purpose front-loaded, followed by API target, method constraints, an Args list, and return format. Each line serves a clear function; only the Args list makes it a bit longer, but it is necessary given zero schema coverage.

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 write tool with 6 parameters and an output schema, the description covers all parameters, return format, and method restrictions. It omits details on error handling beyond 'error envelope' and does not mention permissions, but those are not critical given the tool's scope and annotations.

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%, yet the description explicitly documents all six parameters with constraints (e.g., 'path: full path beginning with /', 'confirm_write: must be true', 'host: host override'). This fully compensates for the lack of schema descriptions and leaves no ambiguity.

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 ('Create or update data') and a clear resource ('at ANY path, including paths not in the catalog'). It distinguishes itself from sibling tools like crpt_write_method or crpt_get_raw by emphasizing arbitrary paths, making 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 gives operational constraints (POST/PUT/PATCH only, requires confirm_write=true) but does not explicitly contrast with alternatives. It implies usage for arbitrary paths but never names sibling tools or says 'use X for catalog paths', leaving the agent to infer routing from the tool name.

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