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

Even though annotations already flag a non-read-only, idempotent mutation, the description adds substantial context: the key enters the chat transcript, a consent flag is required, the data is persisted to ~/.marketplace-mcp/cabinets.json with chmod 600, and the value is never echoed back. This is rich, non-obvious behavioral disclosure.

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 safety warning is correctly front-loaded, and the structured Args block is easy to scan. It is somewhat verbose and includes a raw template placeholder '({fields})', but for a security-sensitive mutation the length is largely justified.

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

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

An output schema exists so return values need not be spelled out, and the description still covers persistence location, permissions, non-echo behavior, and the consent requirement. Nothing an agent needs to invoke this tool correctly is missing.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does: it documents all three parameters, gives concrete credential shapes per service (Ozon client_id/api_key, WB token), explains the name fallback behavior, and states the consent flag must be true.

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

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

The description states a specific verb and resource and even defines the domain term: 'Add or update a cabinet (a named set of API credentials), from chat.' This is far from tautological. However, it never explicitly distinguishes itself from sibling tools like crpt_set_key or crpt_use_cabinet, so an agent must infer the boundary.

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 a clear when-to-use ('from chat') and names an explicit alternative path (install.py / double-click) with the condition that selects it (the key never enters chat). It does not, however, position itself against the sibling cabinet/key tools, so the in-server routing guidance is incomplete.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the risk profile is known. The description adds genuinely new behavior: read endpoints run immediately with no gate, write/destructive calls are silently no-ops when confirmations are absent, and the success/error envelope shape is disclosed. This is substantive context beyond the annotations.

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

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

Front-loaded with the core action, then the confirmation gating, then parameters, then return shape. Every section earns its place, though the Args list retreads names that also appear in the schema and could be tightened.

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 six-parameter, open-world dispatcher with no schema descriptions, the definition supplies the gate semantics, operation_id provenance, all parameter roles, and the return envelope. An output schema exists, so the brief return note is sufficient.

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

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

Schema coverage is 0%, so the description carries the full burden, and it satisfies it: all six parameters are explained, including the tricky ones (path_values for {placeholders}, query for query-string params, body for the JSON payload) plus the two safety-gate booleans and where operation_id comes from.

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

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

States a specific verb and resource ('Execute one catalog endpoint by operation_id'), which lets an agent distinguish this catalog-dispatch tool from section/cabinet siblings. It does not, however, clarify how it differs from crpt_call_raw or crpt_fetch_all, which appear to occupy adjacent niche.

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

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

Gives explicit, actionable routing for the confirmation flags: write needs confirm_write=true, destructive needs both confirm_write and i_understand_this_modifies_data, and 'nothing is sent otherwise'. It also points to {svc}_search_methods as the source of operation_id. It stops short of naming when to prefer crpt_call_raw or crpt_fetch_all instead.

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, openWorldHint=true and destructiveHint=true; the description reinforces this by mapping HTTP verbs to safety classes (GET=read, DELETE=destructive) and disclosing that confirmations are required. That verb-to-safety mapping and the confirmation requirement are genuine context beyond the annotations, though it stops short of specifying auth or rate-limit behavior.

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

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

Front-loaded with the core purpose, then a sectioned Args/Returns layout that is easy to scan with zero padded sentences. The leftover '{svc}_call_method' template placeholder is a minor structural wart.

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

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

With an output schema present and rich annotations, the description covers the remaining gaps: verb semantics, confirmation behavior, and full parameter meaning. An agent has enough to invoke it correctly; only required-vs-optional parameter status and auth expectations are unaddressed.

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: all seven parameters are documented (method, path, host, query, body, confirm_write, i_understand_this_modifies_data), including a concrete path example. It does not mark which are required/optional, so it falls just short of full compensation.

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

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

States a specific verb (Execute) and resource (ANY endpoint, including ones not in the catalog) with clear scope via '(full API coverage)'. This differentiates it from crpt_call_method, which presumably handles only catalog methods. The differentiation is clear but relies on a templated placeholder sibling name rather than naming crpt_call_method explicitly, keeping it from 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?

Implies usage through 'even ones not in the catalog', suggesting this is the escape hatch when a method isn't catalogued, but it never explicitly says 'use crpt_call_method for known methods, use this for uncatalogued endpoints'. The reference to '{svc}_call_method' is about shared confirmation rules, not routing guidance. Usage is inferable but not spelled out.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description still adds meaningful behavioral context beyond them: it explicitly states no secret values are revealed, only which variables are set, and it documents the return shape. That is real value.

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

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

Three short sentences, front-loaded with the core purpose, then the security guarantee, then the return contract. No filler or redundancy; every sentence 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 preflight check with annotations covering the safety profile and an output schema already defined, the description is complete. It volunteers the return shape and the no-secrets guarantee, leaving nothing an agent would need before invoking it.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing further for the description to disambiguate about inputs.

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

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

States a specific verb and resource: 'Check whether the required credentials are present in the environment.' It is clearly distinct from the crpt_* operation tools, but it does not explicitly differentiate itself from siblings (e.g., crpt_set_key / crpt_use_cabinet), which is what a 5 would require.

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 rather than stated – an auth-check tool is self-evidently a preflight step, so an agent can infer it. But there is no explicit 'call this before X' guidance, no mention of when-not to use it, and no reference to any alternative tool for auth-related tasks.

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?

Annotations already cover readOnly and openWorld. The description adds genuine beyond-annotation detail: it auto-handles multiple pagination styles (offset, last_id, cursor, page, WB lastChangeDate), manages cursor fields, and applies a context-protecting max_items cap. That said, it omits auth prerequisites and rate-limit behavior for a potentially heavy paging loop.

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

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

Front-loaded purpose sentence, then a compact helper paragraph and a structured Args/Returns block. Every section earns its place, though the Args list partially restates schema-defined parameter names.

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

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

With an output schema present, the description appropriately names the return fields rather than describing them fully. Given openWorld/readOnly annotations and a non-trivial 7-param tool, the description is largely complete, missing only auth/rate context.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does describe each parameter's role (operation_id, query/body/path_values, items_path override, limit page size, max_items cap). A few params (limit, max_items) still lack format/constraint detail and the override semantics of items_path could be clearer.

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: auto-paginate a read endpoint and return every row. Distinguishes from siblings like crpt_call_method (single call) implicitly by the pagination-aggregation behavior. However, it never explicitly names an alternative tool or contrast, so sibling differentiation is only implicit.

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 (fetching all rows when you need the full dataset across pages), but gives no explicit when-to-use vs crpt_call_method or crpt_call_raw, and no when-not-to-use guidance. An agent can infer the context, but must do the inference itself.

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 concrete return shape ({operation_id, method, path, safety, summary}), which is useful context, but says nothing about ordering, pagination, or behavior when a section name is invalid.

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

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

Two short functional lines plus an Args block — front-loaded with the purpose and no filler. The docstring formatting is slightly verbose relative to the tiny input, but every sentence carries 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 one-parameter read tool with annotations covering safety, the description supplies purpose, parameter provenance, and return fields. An output schema exists, so the return explanation is a bonus rather than a gap; only error/edge-case behavior is unaddressed.

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 is required, so the description carries the burden. It does compensate well by defining the parameter ('section name'), pointing to the tool that produces valid values, and giving a concrete example ('statistics').

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

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

States a specific verb and resource ('List all endpoints in one section'), which clearly separates it from crpt_list_sections (sections) and crpt_describe_method (a single method). Sibling differentiation is implied through the reference to the sections tool rather than stated outright, so it falls just short of a 5.

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

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

Gives practical guidance for the required arg — see {svc}_list_sections to obtain valid section names — and an example value. However, it never says when to prefer this over crpt_search_methods, crpt_map, or crpt_fetch_all, and there are no exclusion 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?

Annotations cover readOnlyHint and openWorldHint, so the safety profile is already declared. The description adds valuable context beyond that: it documents the exact return shape and, critically, states 'Secret values are never returned', which reassures the agent about credential exposure – not something annotations 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?

Three tight sentences/line items: purpose, return shape, and a security note. Front-loaded with the purpose. 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?

An output schema exists, so describing the return JSON in prose is somewhat redundant, but the security caveat and 'active cabinet' framing are additive. For a zero-arg read tool this is complete; only the lack of sibling routing guidance is a small gap.

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

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

Zero parameters, so baseline is 4. Nothing to document, and the description correctly devotes no space to parameter semantics.

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 (configured cabinets) and adds scope ('for this marketplace and which one is active'). Siblings like crpt_add_cabinet/crpt_use_cabinet are clearly differentiated as mutating operations versus this read.

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

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

The description implies this is a discovery step but never states when to use it versus alternatives. It mentions which cabinet is active, loosely hinting at a pairing with crpt_use_cabinet, but no explicit when/when-not guidance is offered.

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?

Annotations declare readOnlyHint=true and openWorldHint=false, so the safety profile is already supplied. The description adds useful behavioral context: no-arg behavior returns the full map, and passing entity returns every method of one entity. This clarifies output shape beyond annotations, though output schema already exists so return structure is partly covered.

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

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

Front-loaded with the big-picture purpose, then the two invocation modes, then a short usage prompt. Every clause earns its place with no filler, and the whole thing is scannable in a few lines.

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-required-param orientation tool with an output schema present, the description is appropriately complete: it explains both call modes and when to reach for it. It doesn't need to explain return values since an output schema exists, only minor gaps like full entity enumeration.

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 so well: it explains that the single optional 'entity' parameter takes values like 'reviews', 'stocks', 'prices', 'orders', and that omitting it returns the whole map. That covers the meaning and usage of the only parameter, though it doesn't enumerate the full valid set.

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

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

States a clear purpose (a capabilities map / orientation tool) with a specific verb-resource framing: it shows business entities and the go-to methods for each. It's distinguishable from siblings like crpt_search_methods or crpt_describe_method, though the tool name 'crpt_map' alone is opaque. Purpose is clear but not fully differentiated by name.

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

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

Gives explicit usage context: 'Use this before guessing — it orients you fast,' which tells the agent when this tool is appropriate (early exploration). It doesn't name a specific alternative tool to use instead when you already know the entity, but the 'before guessing' framing implies the alternative is to call a more specific method.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely non-structured context: if the removed cabinet was active, another becomes active — a cascade behavior an agent could not infer from the schema.

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

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

Two short, front-loaded sentences with no filler; the cascade note follows the core action. The 'Args:' block is slightly redundant against the tiny schema but costs little.

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

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

An output schema exists so return values need not be described, and annotations cover destructiveness. The cascade note fills the main behavioral gap; only permanence/irreversibility and permission needs remain unstated.

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?

One required param with 0% schema description coverage, so the description must carry the load. It gives 'the cabinet to remove', identifying the parameter's meaning but adding no format, source, or lookup guidance.

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 ('Delete a stored cabinet'), which clearly separates it from crpt_add_cabinet, crpt_list_cabinets, and crpt_use_cabinet. It does not explicitly name sibling alternatives, but the operation 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?

No guidance on when to use this versus crpt_use_cabinet or crpt_list_cabinets, and no prerequisites or confirmation steps. The only extra sentence describes a side effect, not selection criteria.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful context beyond that: multilingual matching (Russian and English), best-first result ordering, and the limit bound. It doesn't mention pagination or total-count behavior, keeping it short of a 5.

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

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

Front-loaded with the core action, then an Args block and a one-line return note; every sentence carries information. The Args/Returns formatting is slightly verbose for only two parameters but not wasteful.

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 the return values needn't be explained in depth, and the brief 'JSON list of matching endpoints (best first)' is sufficient. With annotations covering safety and both parameters documented, the only untold detail is the limit default.

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 does the documenting: query is described as free text with three concrete examples, and limit as max results (1-50). It omits the schema's default of 15, a minor gap on an otherwise solid compensation for zero 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?

States a specific verb (search) and resource (endpoint catalog) with a keyword-based mechanism, which is clear on its own. It implicitly separates itself from siblings like crpt_list_sections and crpt_describe_method (list vs. describe vs. search), but never names an alternative to sharpen the distinction.

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

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

Usage is only implied: an agent can infer you use this to find endpoints when you don't already know their name. There is no explicit when-to-use, when-not-to-use, or pointer to crpt_describe_method / crpt_call_method as the follow-up step.

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?

Goes well beyond annotations: discloses that the key enters the chat transcript, requires a hard acknowledgment, validates against the marketplace, and is stored chmod 600 and never echoed. Annotations say only idempotent/non-destructive. Some borderline tension between key-entry-into-chat and 'destructiveHint: false', but the description clarifies it is non-destructive rotation.

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

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

Front-loaded action and a clear warning, with Args and return behavior in a predictable structure. Slightly loose with the {fields} placeholder and parenthetical examples, but no real waste for a security-sensitive tool.

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

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

Covers urgency, safety alternative, parameter behavior, validation, storage permissions, response handling, and rotation advice. With an output schema present, it correctly does not belabor return values, so nothing an agent needs to call it safely 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% and default-empty cabinet/boolean, so the description does the heavy lifting: it explains cabinet defaulting logic (active cabinet, else shop name, else 'main'), what credentials must contain (via the {fields} placeholder), and the exact semantics of the acknowledgment flag. Only the credential field list is a runtime placeholder, capping it below 5.

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 ('Change / rotate the API key'), gives concrete triggers (expired or leaked), and the chat-context framing makes it unmistakable against the auth/cabinet siblings like crpt_check_auth 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?

Explicit about when to use it here vs the installer alternative (safe, terminal-free), and warns about scoped keys and rotation in the seller cabinet. No explicit exclusions vs the other 13 siblings, but the alternative routing 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 say openWorldHint=false and idempotentHint=true but do not explain the global side effect; the description supplies that key behavioral context — credential switching for subsequent calls. It doesn't state auth requirements or error behavior if the name is invalid, so not a 5.

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

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

Two short sentences: effect first, then the single parameter with a pointer to the discovery tool. Zero waste, fully front-loaded.

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

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

With an output schema present and only one parameter, the description covers what an agent needs to call it correctly, including the crucial cross-call side effect. Minor gaps (error cases, auth scope) remain but output schema covers the return side.

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 burden, and it does define 'name' as the cabinet to activate and routes to the list tool for valid values. However, it gives no format/syntax detail beyond that, so only baseline-plus value.

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

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

States a specific verb and resource ('Switch the active cabinet') and immediately names the resulting effect ('Subsequent API calls use its credentials'). It is clearly distinguishable from siblings like crpt_add_cabinet or crpt_remove_cabinet, which mutate the cabinet list rather than the active selection.

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

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

Clearly indicates when to use it (to change which cabinet subsequent calls run against) and points to crpt_list_cabinets for discovering valid names. No explicit when-not or exclusions are given, keeping it below a 5.

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