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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuine context the annotations lack: the valid state preconditions (created / awaiting_retry) and the consequence of misuse on processed requests. It stops short of describing what happens to already-prepared files or the response shape.

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 front-loaded sentences with zero waste: purpose and precondition first, then positive usage, then the exclusion with the alternative. Every sentence earns its place.

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 two-parameter, no-output-schema tool, the description covers purpose, applicability, and routing to a sibling. It would be fully complete with a note on what happens to any partially prepared files, but nothing essential to correct invocation 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% and both parameters (counter_id, request_id) are documented in the schema itself. The description adds no syntax, format, or ID-source guidance beyond the schema, so the 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?

Names a specific verb (Cancel) and resource (Yandex Metrica Logs API export) and narrows scope to requests in status created or awaiting_retry. It also implicitly distinguishes itself from yandex_metrica_clean_logs_request, which handles processed 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 ('user wants to stop an export that has not been processed yet') and when not to ('Do not use this on a processed request'), naming the sibling to use instead. Nothing is left to inference.

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

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

Annotations already declare destructive=true, idempotent=true, readOnly=false, so safety is covered structurally. The description adds genuine value beyond that: what is destroyed (prepared files), that quota is freed, and the precondition that status must be 'processed'. It does not cover auth requirements, but that is a minor omission given the annotation coverage.

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 tightly written sentences with zero waste; the destructive action and its precondition are front-loaded before the routing guidance.

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 destructive two-parameter tool, the annotations carry the safety profile, the schema carries the parameters, and the description carries the when/when-not routing. There are no output-schema concerns since the action is a side-effecting deletion with no meaningful return payload.

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 coverage is 100%, so both counter_id and request_id are fully documented in the schema. The description adds no syntax or format detail beyond the state precondition implied by 'processed', so the baseline 3 is appropriate.

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 (delete), resource (prepared files of a processed Logs API export), and side effect (free the export quota). It is immediately distinguishable from siblings like cancel_logs_request and download_logs_part.

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 ('finished downloading and the request status is processed'), when not to use it ('still pending'), and names the alternative tool by name. Nothing is left to inference.

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

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

Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=true), so the safety burden is largely covered. The description adds return-payload behavior (id and tracking code), which is not in the structured fields, but it says nothing about auth/permission requirements or that repeated calls create duplicate counters.

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 tight sentences: the action first, then the trigger, then the exclusion with alternatives. No filler and every sentence earns its place.

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 create tool with full schema coverage and annotations covering the mutation profile, the description covers purpose, trigger, exclusion, and return shape despite there being no output schema. Only auth/permission prerequisites and duplicate-creation implications are absent.

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% for all five parameters (name, site, mirrors, time_zone_name, gdpr_agreement_accepted), so the schema carries the semantics. The description adds no parameter-level detail beyond that, making the baseline 3 appropriate.

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 (create a Yandex Metrica counter for a site) and adds the outcome (returns its id and tracking code). It also names the siblings it is not (list_counters/get_counter), so an agent can distinguish it without opening any schema.

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?

Explicit when-to-use ('user asks to add a website or start tracking a new property') plus an explicit when-not ('to find a counter that already exists') with two named alternatives. This is exactly the routing information an agent needs.

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

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

Annotations declare it is a non-read-only, non-idempotent, open-world call, but the description adds the genuinely useful behavioral traits: the operation is asynchronous, must be polled via get_logs_request until status is 'processed', and date2 cannot be today. It does not discuss lifecycle cleanup/cancellation (cancel/clean siblings exist), so it falls just short of a 5.

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 sentences, each carrying distinct information with the purpose front-loaded. It is dense but every sentence (scope, preconditions, exclusions, polling, field prefixes) earns its place, though the length edges toward a wall of text.

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?

There is no output schema, so the description correctly compensates by describing the async lifecycle and the polling step needed to obtain results. Combined with full parameter coverage, an agent has everything needed to invoke and follow through on the call.

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 coverage is 100%, so the baseline is 3, but the description adds field-naming syntax not present in the schema: fields must use the ym:s: prefix for visits and ym:pv: for hits. This ties the fields parameter to the source choice, which is meaningful beyond the structured data.

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 (create) and resource (asynchronous Yandex Metrica Logs API export of raw visits or hits), plus scope (one counter and date range). It explicitly distinguishes itself from yandex_metrica_get_report (aggregated totals), so the agent can route without opening the schema.

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?

Gives explicit when-to-use ('when the user wants row-level data' after evaluate_logs_request confirms feasibility), explicit when-not-to-use ('not to test feasibility', 'not for aggregated totals; call get_report'), and a named follow-up (poll get_logs_request). The alternative and its selection condition are both stated.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds real consequence detail beyond that: the counter stops collecting data and its statistics become unavailable via the API, plus a user-confirmation gate. It does not state whether deletion is reversible or what the response returns, so it falls just short of a 5.

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, front-loaded with the action and its consequence, then the precondition, then the sibling exclusion. Every sentence carries distinct, necessary information with no repetition.

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 single-parameter destructive tool with no output schema, the description supplies the action, its irreversible consequence, the confirmation precondition, and the alternative tool. Nothing an agent needs in order to call 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?

Only one parameter (counter_id) and schema description coverage is 100%, so the schema already documents it fully. The description adds no syntax or format guidance beyond the schema, making the baseline 3 appropriate.

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 ('Delete one Yandex Metrica counter') and immediately names the sibling it must not be confused with ('Do not use this to inspect a counter; call yandex_metrica_get_counter instead'). An agent can distinguish it from get_counter, list_counters, and create_counter without opening any schema.

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?

Gives an explicit precondition ('when the user explicitly asks to remove a counter and has confirmed the deletion') and an explicit exclusion routing to the alternative tool for inspection. 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.

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.

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

Annotations already declare the safe read-only, idempotent, non-destructive profile, but the description adds a trait they do not capture: this is a dry-run that performs no request creation. It also hints at output content ('how many days fit the quota'), useful given there is no output schema. It stops short of describing error behavior or quota thresholds, keeping it at 4 rather than 5.

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 tight sentences with zero filler: the dry-run clarification is front-loaded, then the positive trigger, then the explicit exclusion. Every sentence carries routing or behavioral 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?

With no output schema, the description needs to signal what comes back, and it does via 'how many days fit the quota' and the feasibility verdict. Combined with annotations that cover the safety profile and a fully documented schema, the definition is nearly complete; only the precise response shape remains implicit.

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 the schema already documents all five parameters, including enum values for source and field formats. The description only restates 'dates, source, and fields' without adding format or constraint detail beyond the schema, so the baseline 3 is appropriate; counter_id is not mentioned at all.

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 gives a specific verb (check/evaluate) and resource (Yandex Metrica Logs API export) plus the exact scope ('given dates, source, and fields, without creating a request'). It explicitly distinguishes itself from the sibling yandex_metrica_create_logs_request, so an agent can route between them without opening either schema.

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 states the positive trigger ('user wants to know if a raw export is possible and how many days fit the quota') and an explicit exclusion ('Do not use this to start the export'), naming the alternative to call instead. Both when-to-use and when-not-to-use are covered with the fallback path spelled out.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds the useful behavioral detail that this returns a configuration snapshot (settings, status, owner, timezone, site) rather than time-series data. It does not mention auth requirements or error behavior for a missing counter, so it stops short of a 5.

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?

Two sentences, zero filler, with the purpose and returned fields front-loaded before the routing exclusion. Every clause earns its place.

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 single-parameter read tool with no output schema, the description compensates by naming what the response contains and by routing ambiguous discovery requests to the correct sibling. Nothing an agent needs to call this 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 coverage is 100% and the single counter_id param is documented in-schema as the Yandex Metrica counter (tag) ID. The description only restates 'by id' without adding format, range, or resolution guidance. Baseline 3 is correct when the schema carries the parameter detail.

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 one Yandex Metrica counter by id') and enumerates the returned surface (settings, status, owner, timezone, site). It is immediately distinguishable from the sibling list_counters, which serves a different lookup mode.

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?

Gives an explicit use condition ('when the user already has a counter id and wants that counter's configuration'), an explicit exclusion ('Do not use this to discover unknown ids'), and names the alternative tool (yandex_metrica_list_counters) to use instead. Nothing is left to inference.

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

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.

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and openWorld. The description adds context beyond them: the switch to the comparison endpoint when date1_b/date2_b are supplied, the returned statistic families, and the ym:s:/ym:pv: prefix convention. It does not mention rate limits or quota behavior, so it is strong but not exhaustive.

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?

Four sentences, purpose front-loaded, followed by usage, exclusion, and a technical prefix note. Mostly waste-free, though the closing prefix sentence feels appended rather than integrated with the flow.

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 19-parameter query tool with no output schema, the description covers domain, usage, exclusions, and metric naming conventions, and it sketches the returned aggregates. An agent has enough to call it correctly, though return shape (row structure, comparison-mode dual metric sets) is only lightly implied.

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 baseline is 3, but the description adds genuine semantic value by explaining the ym:s: vs ym:pv: metric prefix families and the comparison-mode trigger (date1_b/date2_b), which helps construct valid metrics/filters. It does not restate the parameter table.

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+resource ('Run a Yandex Metrica Reporting API query and return aggregated statistics') with concrete outputs (visits, users, bounce rate, traffic sources). It explicitly contrasts itself with the Logs API siblings (yandex_metrica_evaluate_logs_request), so an agent can distinguish it without opening any schema.

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?

Gives explicit when-to-use ('summary, breakdown, or comparison of two periods via date1_b and date2_b') and a clear when-not ('Do not use this for row-level visits or pageviews') naming the alternative tools. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds value beyond them by disclosing the access scope (token-limited visibility) and the shape of each returned item (id, name, site). It stops short of describing paging behavior even though page/per_page exist.

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 tight sentences with zero filler: purpose and scope first, then the triggering condition, then the exclusion and handoff. Every sentence earns its place and the routing 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?

There is no output schema, so the description usefully names the returned fields (id, name, site) and the visibility scope. Pagination and total-count behavior are left entirely to the schema, which is a minor gap for a paged list tool but not a blocking one.

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% with six fully documented parameters, three carrying enums, so the schema does the heavy lifting. The description mentions only the returned fields and adds no filtering, sorting, or paging semantics beyond the schema; baseline 3 is appropriate.

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 (list counters) plus the access scope (those the configured token can reach) and the returned fields (id, name, site). It explicitly contrasts with the sibling yandex_metrica_get_counter, so an agent can distinguish the two without opening either schema.

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?

Gives a positive trigger ("use when the user needs a counter id before any other query") and an explicit exclusion with the named alternative ("do not use this to read one counter's settings; call yandex_metrica_get_counter"). When-to-use, when-not-to-use, and the replacement tool are all present.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered. The description usefully adds what the payload contains (goal id and type), but says nothing about pagination, count limits, or permission requirements on the counter.

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?

Two sentences, zero filler, with the purpose stated first and the routing constraint second. Every clause earns its place.

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 single-parameter read-only list tool with a complete annotation set and no output schema, the description covers purpose, trigger, exclusion, alternative, and return fields. Nothing needed for correct invocation 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 coverage is 100% and the single counter_id parameter is fully documented in the schema as the 'Yandex Metrica counter (tag) ID'. The description's phrase 'one Yandex Metrica counter' merely confirms the unit of scope rather than adding format or constraint detail, 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?

States a specific verb (list) and resource (conversion goals on one counter) and even names the returned fields (goal id and type). An agent can distinguish this from yandex_metrica_list_counters or yandex_metrica_get_counter without opening any schema.

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?

Gives both a positive trigger ('when the user asks which goals exist on a counter before building a report') and an explicit exclusion ('Do not use this for conversion counts or rates'), routing the agent to the named alternative yandex_metrica_get_report. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered by structured data. The description adds a genuine scoping detail — that results span every lifecycle status from created to cleaned — but says nothing about pagination, ordering, or result size. Useful incremental context, not rich behavioral disclosure.

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?

Two sentences, zero filler, and the purpose plus scope is front-loaded before the routing instruction. Every clause earns its place.

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?

A simple read-only list tool with full annotation coverage, a fully described single parameter, and no output schema to explain. The description covers what it returns conceptually (all export requests across all statuses) and routes the agent to the sibling for single-request polling, leaving no blocking gap.

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?

Only one parameter, and the schema documents counter_id at 100% coverage ('Yandex Metrica counter (tag) ID'). The description's phrase 'on a Yandex Metrica counter' restates the schema without adding format, range, or lookup guidance, so the 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?

States a specific verb and resource ('List every Logs API export request on a Yandex Metrica counter') and adds the scope of statuses covered, from created through cleaned. An agent can distinguish this from yandex_metrica_get_logs_request and the other logs siblings without opening any schema.

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?

Gives an explicit positive trigger ('when the user wants to see existing exports or find a request id') and an explicit exclusion ('Do not use this to poll a single request') that names the correct alternative tool and the key it needs. Nothing about tool selection is left to inference.

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