yandex_metrica_download_logs_part

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds real behavioral context: preview returns ~50KB, full mode should only be used for parts under 10MB, and the request must already be processed. Some of this overlaps the schema's mode description, but the 10MB constraint and processed-status precondition are unique 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?

Five compact sentences, each carrying distinct information (purpose, positive trigger, negative trigger, mode limits, part numbering). The purpose and the routing advice are front-loaded with 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 read-only download tool with no output schema, the description covers purpose, preconditions, mode behavior, and size limits well enough to invoke correctly. It could say slightly more about what the TSV preview metadata looks like, but nothing critical 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 100%, so every parameter is already documented, including the mode enum and its semantics. The description reinforces part_number's 0-based origin from the parts list, but adds no format or syntax detail beyond the schema, so baseline 3 applies.

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 ('Download one processed part of a Yandex Metrica Logs API export as TSV text'), including the return format. It is clearly distinguishable from siblings like yandex_metrica_get_logs_request, which it explicitly names.

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 an explicit positive condition ('when the user wants the rows of a request whose status is already processed'), an explicit exclusion ('Do not use this to check whether the export is ready'), and names the alternative tool to call instead. It also explains where part numbers come from and that they are 0-based.

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