menu__get_stop_lists

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond the annotations by disclosing MCP-server throttling ('не чаще 10 запрос(ов) за 60 с') and explicitly advising to cache results in the dialog, which helps an agent plan calls safely.

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 action, followed by structured Args/Returns and two concise, high-value guidance sentences about ID sources and rate limiting. A small amount of redundancy exists ('Ответ со стоп-листами' is somewhat generic), but overall it is well-organized and free of 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?

The description covers ID sourcing, rate limiting, and a minimal return statement, which are useful given the lack of an output schema. However, it does not mention the closely related sibling menu__get_stop_lists_by_organization, leaving an important usage ambiguity unresolved, and the return description is too vague to fully compensate for the missing output schema.

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

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

The only direct parameter, 'request', is described tautologically as 'Параметры запроса StopListsRequest', adding little meaning. However, the description adds cross-tool ID sourcing for organizationIds and terminalGroupsIds, which goes beyond the schema. It does not mention the returnSize parameter, though the nested schema definition does document it.

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 stop-lists'), clearly stating the verb and resource. It does not, however, distinguish itself from the sibling tool menu__get_stop_lists_by_organization, so it stops short of a 5.

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

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

The description provides ID sourcing guidance ('organizationIds → organizations__get_organizations; terminalGroupsIds → terminal_groups__get_terminal_groups') and a throttling instruction, but it never says when to choose this tool over menu__get_stop_lists_by_organization or any other alternative. There is no explicit when-to-use vs. when-not-to-use guidance.

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