yandex_metrica_get_logs_request

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

Annotations already declare readOnly, idempotent, open-world, non-destructive, so the safety profile is covered. The description adds the workflow-relevant behavioral fact that this is a polling-style status check that must report 'processed' before download, and discloses the return content (status plus prepared parts), which matters because there is no output 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?

Three short sentences that are front-loaded with the primary purpose, then the usage condition, then the two exclusions. No filler and no repetition of the schema or annotations.

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?

Given no output schema, the description helpfully characterizes what comes back (status and prepared parts) and places the tool in the export workflow. It omits how unprocessed/failed states are represented or whether partial part lists change over time, which is a minor gap for a polling endpoint.

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?

Both parameters (counter_id, request_id) already have full schema descriptions at 100% coverage, and the description adds no syntax, format, or constraint detail beyond them. Baseline 3 is appropriate when the schema carries the parameter burden entirely.

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 ('Get the status and prepared parts of one Yandex Metrica Logs API export request') and scopes it to a single request. This is clearly separable from the sibling tools that create, list, download, or cancel requests.

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?

Explicitly states when to use it (while waiting for a created export to reach 'processed' before downloading) and names two alternatives with conditions: yandex_metrica_download_logs_part for TSV rows and yandex_metrica_list_logs_requests for listing. Both when-to-use and when-not-to-use are covered.

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