dictionaries__get_cancel_causes

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful behavioral context beyond that: an MCP-level throttling threshold and an explicit caching directive. It does not describe error behavior or response details, but for a read-only dictionary lookup with this annotation support, the added transparency is solid.

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

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

The description is compact and front-loaded with the core purpose, and the Args/Returns/throttle structure is easy to scan. It loses a point because 'Ответ со списком причин отмены Где взять ID' runs two sentences together without a clean break, and the Args line provides little new 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-only tool, the essential facts are present: what is returned, where the required ID comes from, and the throttle/caching constraint. It omits any mention of the similarly purposed sibling dictionaries__get_cancel_causes_by_organization, which is important selection context given the large sibling list, and there is no output schema to cover return-shape 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?

The single parameter is a nested CancelCausesRequest object, and the description's Args line mostly restates the parameter name and type without adding semantic detail. The only real parameter-level addition is 'Где взять ID: organizationIds → organizations__get_organizations', which tells the agent where to source the required IDs. Given the stated 0% schema coverage, this is meaningful but only partial 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?

The description opens with 'Получить причины отмены доставки' ('Get delivery cancellation causes'), a specific verb-plus-resource statement that clearly identifies what the tool does. It loses the top score because it does not differentiate this tool from the closely named sibling dictionaries__get_cancel_causes_by_organization.

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 operational guidance: organizationIds can be obtained via organizations__get_organizations, and the MCP server throttles to 1 request per 60 seconds so caching is recommended. It does not, however, tell the agent when to choose this tool over the near-identical sibling or any other dictionary lookup, so exclusion/alternative guidance is missing.

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