employees__get_couriers

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

Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description discloses a critical behavioral constraint: 'Троттлинг MCP-сервера... не чаще 1 запрос(ов) за 60 с — кэшируйте результат в диалоге.' This rate-limit and caching instruction is exactly the kind of behavioral context that adds value beyond structured data.

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 with no fluff: purpose first, then ID source, then throttling/caching. Every sentence carries operational value, and the most important scoping information is 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?

For a simple read-only list tool with one parameter, the description covers purpose, input sourcing, and a critical rate limit. It lacks explicit differentiation from employees__get_couriers_by_role and has no output schema, but nothing essential about invoking it correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate. It does add meaning by explaining where organizationIds come from ('organizationIds → organizations__get_organizations'), but it does not explain the request wrapper structure or the array semantics beyond what the schema already shows. This is partial compensation, not full.

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 the resource clearly: 'Сотрудники-курьеры организаций' (organization courier employees), and the tool name supplies the get verb. It is clear this returns couriers for given organization IDs, but it does not differentiate from the sibling employees__get_couriers_by_role, 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 gives a concrete prerequisite: 'Где взять ID: organizationIds → organizations__get_organizations' tells the agent exactly how to obtain the required organizationIds. It also adds operational guidance to cache results due to throttling. However, it does not explicitly state when to prefer this tool over alternatives like get_couriers_by_role.

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