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

With no annotations, the description carries the full burden, and it does disclose two real behavioral traits: the operation is read-only ('только чтение') and it returns error code 58 before API access is approved. However, it omits pagination behavior, how 'limit' interacts with the result, and the shape of the returned campaign list.

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 compact sentences, front-loaded with the primary purpose and followed by the precondition/error behavior. No filler, though the secondary API-balance mention slightly muddies the single-tool purpose.

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 and no annotations, so the description is the only behavioral source; it covers read-only status and the code-58 gate, which is helpful, but leaves result shape, pagination, and the 'limit' parameter unexplained for a list tool.

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 50%: 'client_login' is documented in the schema but 'limit' is bare. The description adds no parameter-level meaning for either field, so it fails to compensate for the undocumented 'limit' and its interaction with the campaign list.

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 names a specific verb (список/list) and resource (кампании Яндекс Директа) and adds a secondary output (остаток баллов API), which is clear and concrete. It does not explicitly contrast itself with the sibling direct_report, so it stops short of full sibling differentiation.

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 a precondition (returns code 58 until API access is granted), which is useful, but gives no guidance on when to choose this tool over the sibling direct_report or when listing is preferable to reporting. Usage context is only weakly implied.

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?

With no annotations, the description carries the burden and does disclose a critical behavioral trait: the report may be generated asynchronously, with the tool polling and retrying for up to several minutes. It also flags that relative dates (e.g. 30daysAgo) are unsupported. It omits auth/permission requirements and error behavior.

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?

Front-loaded with purpose, then period semantics, then async behavior, in three dense sentences with little waste. The middle sentence is long, but every clause carries needed 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?

For a 7-parameter reporting tool with no output schema, it covers purpose, period formats, report types, and async latency well. Missing only auth/quota details and error/return expectations, which are minor given the schema documents all parameters.

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 baseline is 3, but the description adds real meaning: it explains the date_range-vs-date1/date2 choice, the LAST_30_DAYS default, and that relative date strings are rejected. This clarifies parameter interaction beyond the schema's per-field notes.

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 (a Direct spend/impressions/clicks report via Reports API v5) and explicitly distinguishes itself from the sibling direct_campaigns by noting it provides the real performance numbers that tool lacks. An agent can immediately tell what it returns.

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?

Names the sibling it complements (direct_campaigns) and clarifies it delivers effectiveness metrics by campaign/ad/group/search query, giving clear context for selection. It stops short of an explicit 'use this instead of X when Y' rule or stated prerequisites.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses the default period-B behavior (auto-derived as an equal-length window immediately preceding period A) and the two output modes driven by dimensions, but says nothing about auth requirements, result format, or limits beyond what the schema states.

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 sentences, front-loaded with purpose, then default period behavior, then the dimensions conditional. No filler and each sentence carries distinct 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?

For a read-only comparison tool with no output schema and no annotations, the description covers purpose, defaults, and conditional behavior adequately. It could be more complete by hinting at the returned comparison structure or auth needs, 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 89%, so the baseline is 3 and the schema already documents most parameters including the prev_date1 default. The description adds meaning for the dimensions parameter (row-level comparison vs totals) and reinforces the period-B default, but does not add syntax or format detail beyond the schema.

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 operation (comparing metrics between two periods) with a concrete example question, which distinguishes it in spirit from the single-period metrika_report/metrika_summary siblings. However, it never names or contrasts those siblings explicitly, so the differentiation is left to inference.

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 clear when-to-use context ('how did traffic change over the last month') and explains the conditional path when dimensions is set. It stops short of naming alternatives (e.g. use metrika_report for single-period data) or stating when not to use it.

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?

No annotations are provided, so the description carries the full burden. It does disclose the payload shape (counters plus their sites and status), which implies a safe read, but it says nothing about auth requirements, result size, or whether counters are scoped to the authenticated user.

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?

A single front-loaded sentence with no filler. It is efficient, though the brevity comes at the cost of the usage context an agent would benefit from.

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 no-param, no-output-schema discovery tool, the description covers what is returned but omits the counter identifier that downstream tools like metrika_report presumably need, and gives no auth context. Adequate but with a clear gap for chaining.

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 tool takes zero parameters, so per the rubric the baseline is 4. The description adds no parameter information because none exists to add.

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 resource (Metrika counters) and states exactly what the listing contains: sites and status. It is distinguishable from metrika_summary/report/compare by being a plain enumeration, though it never names those siblings to sharpen the contrast.

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?

There is no when-to-use guidance, no mention of prerequisites such as authentication, and no routing to the sibling tools (metrika_report, metrika_summary) that consume a counter. The agent must infer that this is a discovery step.

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?

With no annotations, the description carries the full behavioral burden, yet it discloses almost nothing about behavior: no auth/permission requirements, no pagination or rate-limit notes, no statement of what the response contains. The only behavioral hint is the implicit 'up to 200' limit, which lives in the schema, not the description.

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?

Purpose is front-loaded in the first sentence, followed by value catalogs that earn their place by telling the agent exactly which tokens are legal. It is somewhat list-heavy, but the lists are functional rather than 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?

An 8-parameter tool with no annotations, no output schema, and only 50% schema description coverage needs a much richer description. The metric/dimension catalogs help, but date-range formats, sort syntax, counter_id provenance, and the shape of the returned report are all absent, leaving the agent under-equipped to call it correctly.

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?

At 50% schema coverage, the description compensates by enumerating the valid metric and dimension values, which meaningfully clarifies the two most important parameters beyond the bare schema. It still leaves sort, date1/date2 format, and counter_id sourcing unexplained in both places, so the gap is only partly filled.

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 names the resource (Reporting API Metrika report) and its nature as an arbitrary/flexible report, then catalogs the exact metrics and dimensions it accepts. It is clearly distinguishable from metrika_summary, which it references for goal IDs, though it does not explicitly differentiate from metrika_compare or metrika_counters.

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 one concrete routing hint ('look up goal IDs via metrika_summary'), which is genuinely useful. However, it never states when to choose this arbitrary-report tool over the sibling metrika_compare or metrika_summary for reporting tasks, leaving the primary selection decision implied.

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?

With no annotations provided, the description carries the full burden, and it does disclose the read-only, aggregate nature of the output and the metric set returned. It says nothing about authentication requirements, the default counter fallback (left to the schema), rate limits, or whether data is pre-aggregated/sampled — gaps that matter for a metrics tool.

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?

A single dense sentence that front-loads the resource and then lists the payload, with no filler. It is efficient, though the metric enumeration makes it slightly list-heavy rather than optimally structured.

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 compensates by enumerating the returned metrics, which is the key information an agent needs. It stops short of describing the response shape or per-goal breakdown format, but for a 3-parameter read tool with sensible defaults it is largely sufficient.

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 date1, date2, and counter_id including the '30daysAgo'/'yesterday' syntax and the default-counter behavior. The description adds no parameter meaning beyond that, so the baseline 3 is correct.

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 resource ('Сводка Яндекс Метрики за период') and enumerates the exact metrics returned (visits, visitors, bounces, duration, depth, all goals), so an agent knows precisely what this tool produces. It does not, however, differentiate itself from siblings like metrika_report or metrika_compare, leaving the agent to guess which one to pick for a summary vs. a detailed report.

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?

There is no guidance on when to use this tool rather than metrika_report or metrika_compare, nor any statement of prerequisites or exclusions. The phrase 'за период' only loosely implies a date-bounded aggregate query, which is inferred rather than 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?

With no annotations, the description carries the full burden. It does disclose that this is a GET (read-only) query and that the return is a time series of indexed page counts, which adds useful behavioral context. However, it says nothing about authentication requirements, rate limits, or default behavior when dates are omitted.

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?

A single sentence that front-loads the core resource (page-count dynamics in Yandex search) before the endpoint and the growth/decline framing. No wasted words. It is dense but readable, with only a minor parenthetical endpoint that could be considered redundant.

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 tool with 2 optional parameters and no output schema, the description explains what data comes back, so return values need not be clarified. The notable gap is that both parameters are optional yet the description never says what date range is used by default when they are omitted, which matters for correct invocation.

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 both date parameters with their YYYY-MM-DD format and optionality. The description's 'по датам' merely aligns with the date parameters and adds no format, default-range, or 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?

The description gives a specific verb+resource: page-count dynamics over time in Yandex search, sourced from the search-urls history endpoint, and even quotes the GET path. The agent understands this is a historical indexing-trend tool distinctly different from webmaster_queries or webmaster_sitemaps. It stops short of explicitly naming a sibling to contrast against, so it is clear but not fully differentiated.

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?

Usage is only implied through the resource semantics (tracking indexing growth/decline by date). There is no explicit statement of when to choose this over webmaster_summary or webmaster_queries, and no prerequisites or exclusions. Adequate but leaves routing 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?

No annotations are provided, so the description carries the full behavioral burden. It reveals only the metric set; it omits authentication needs, data freshness, default time range, ordering, and whether results are paginated or capped. For a read tool with zero annotation coverage, this is a considerable gap.

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?

A single front-loaded sentence with no wasted words. It efficiently communicates the resource and the key returned metrics.

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 conveys what data is returned, which partially compensates for the absence of an output schema. However, it leaves open the timeframe covered, result ordering, and whether the default limit of 25 is the only cap, so an agent cannot fully anticipate the behavior or response scope.

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 'limit' parameter is fully documented in the schema. The description adds no parameter detail, which is acceptable at high coverage, so the baseline of 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 names a specific resource (search queries where the site appears in Yandex) and enumerates the returned metrics (impressions, clicks, average position). This clearly distinguishes it from siblings like webmaster_summary or wordstat_phrases, though it does not explicitly contrast itself with them.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The agent must infer that this is for site-specific query data rather than keyword research (wordstat_phrases) or a general summary (webmaster_summary).

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?

With no annotations, the description carries the full burden and does so well: POST mutating call, irreversible, requires confirm: true, hard rate limit (150/day), and batch cap. It even specifies the pre-condition that the user must see the URL list first. Side effects and limits are fully disclosed.

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, front-loaded with the action, then the constraints and the safety requirement. No filler; every clause conveys a distinct operational fact.

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 mutating submission tool with no output schema and no annotations, the definition supplies everything needed to call it correctly: quota, batch size, irreversible confirmation flow, and user-visible prerequisite. Return format is not needed for a queue-submission operation.

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 both parameters are already documented (urls up to 20, confirm must be true). The description reinforces the 20-URL cap and the meaning of confirm but adds little beyond what the schema already states, consistent with the baseline for full coverage.

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 ('ставит URL в очередь на переобход Яндексом') and names the HTTP method. It also distinguishes itself from siblings by declaring it is the only mutating call in the server, so an agent can separate it from the read-only webmaster_* tools.

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?

Provides concrete operating context: batch limit of 20 URLs, a 150/day site-wide quota, and the requirement to show the URL list to the user before confirming. It does not name an alternative tool or spell out when not to use it, but the quota and confirmation constraints give clear usage framing.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the shape of the returned data (URL, address count, error count, last crawl date), which is real context. It does not state that this is a read-only listing, nor anything about pagination or rate limits beyond the limit parameter.

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?

A single well-formed sentence that front-loads the resource and then lists the relevant fields. No filler, no redundancy; a slightly more explicit verb ('список'/'возвращает') would make it sharper.

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 one-parameter read tool with no output schema, the description adequately documents what comes back and is sufficient to invoke correctly. The only real gap is the absence of any when-to-use guidance relative to its siblings.

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% — the single 'limit' parameter already documents its range and default in the schema. The description adds nothing about parameters, 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?

The description names a specific resource — the sitemap files Yandex sees for the site — and enumerates the returned fields (URL, адресов, ошибок, дата обращения), so an agent knows what it gets back. It doesn't explicitly contrast itself with the closest siblings (webmaster_indexing, webmaster_recrawl), but the resource is distinct enough to separate it from the other webmaster_* tools.

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?

There is no statement of when to use this versus webmaster_indexing or webmaster_recrawl, and no prerequisites or exclusions. The agent must infer usage purely from the resource name.

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?

With no annotations, the description carries full behavioral disclosure burden. It only states the returned data fields; it does not mention authentication, rate limits, data freshness, or other operational traits. The read-only nature is implied but not stated.

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?

A single, front-loaded sentence that lists the key metrics with no wasted words. It is appropriately sized for a summary tool.

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 zero-parameter tool with no output schema, the description adequately enumerates the summary contents (ИКС, indexed pages, excluded pages, active diagnostic problems). It could be more complete by specifying whether the summary covers all sites or requires selection, but it is largely sufficient.

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 tool has zero parameters, so the baseline score is 4. The description does not need to explain parameter meaning, and the empty schema is appropriately handled.

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 names the resource and lists the specific metrics returned (ИКС, pages in search, excluded, diagnostic problems), making the tool's purpose clear. It does not explicitly contrast with siblings like webmaster_queries or webmaster_indexing, but the content distinguishes it from those focused tools.

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?

No guidance is given on when to use this tool versus alternatives such as webmaster_queries, webmaster_indexing, or other summary tools. The description states what it does but not the conditions or context for selecting it.

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?

Without annotations, the description carries the full behavioral burden. It discloses asynchronous behavior (~3 min prep), the retry/idempotency pattern, auth mechanism (Live v4 API with same token), and implied rate/size limits (up to 10 phrases). Missing: what the output contains, whether calls are cached, error semantics.

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, front-loaded with what the tool does, then operational behaviour (async + retry). No filler; every clause is actionable.

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 3-param tool with no output schema, the description covers purpose, async timing, retry behaviour, and auth. It does not explain the shape of results or constraints on combining phrases, but the essential operational knowledge is present.

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 all three parameters are documented there (top, geo_id with default [225], phrases limit 10). The description adds no parameter-level detail beyond what the schema provides, 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 specific resource (Yandex Wordstat frequency data) and two clear functions (monthly search volume + co-occurring queries), distinguishing it from Metrika/Webmaster siblings. Sibling differentiation is implicit by data source rather than explicit routing.

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?

Provides one important usage rule: if the call returns 'still preparing', retry with the same phrases. But no guidance on when to use this vs other tools, no prerequisites, no mention of limits beyond those in schema, and no when-not-to-use conditions.

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?

No annotations exist, so the description carries the burden, and it delivers a key behavioral fact: the token itself is never shown, only a fingerprint. That is genuinely useful disclosure beyond the schema. It doesn't state permissions or whether the check is side-effect free, so it falls 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, no filler. The payload (what is reported) is front-loaded and the invocation rule is second, which is exactly the right ordering for a status tool.

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, annotations, or parameters, the description does the needed work by enumerating the returned fields (storage, ClientID, tokens, expiry) and the fingerprint caveat. It could say more about what an unauthenticated result looks like, but it is sufficient to call correctly.

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 tool takes zero parameters, so there is nothing to document and the baseline is 4. The description correctly implies a parameterless status probe.

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 resource (auth/connection status) and enumerates exactly what it reports: secret storage backend, presence of app ClientID and tokens, and token expiry. This clearly distinguishes it from siblings like yandex_login and yandex_submit_code, which perform auth actions rather than reporting state.

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 trigger condition: 'Вызывай первым, если какой-то инструмент ответил «нет токена»' — call it first when another tool reports a missing token. That is a concrete when-to-use rule tied to a failure mode of siblings.

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?

No annotations are provided, so the description carries the full burden. It usefully discloses that the output is a link to show the user and that no terminal is required, but it omits other behavioral facts an agent would want: whether calling again invalidates a prior link, whether it waits for confirmation, and what happens on failure. Adequate but incomplete for an unannotated flow tool.

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 output, then the hand-off instruction. Every sentence earns its place 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?

No output schema exists, but the description does explain what is returned (an authorization link for the user) and the next step. For a 2-parameter, all-optional login-initiation tool this is nearly complete; only session/error semantics are left unstated.

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% – both 'mode' (manual vs localhost, including the Redirect URI prerequisite) and 'services' are fully documented in the schema. The description adds no parameter meaning beyond that, 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 ('Step 1 of Yandex login: returns an authorization link') and names the exact follow-up sibling (yandex_submit_code). An agent can distinguish this login-initiation tool from yandex_auth_status and yandex_submit_code 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?

The 'Step 1' framing plus 'after confirmation call yandex_submit_code' gives clear sequencing context for the login flow. It does not, however, mention checking yandex_auth_status first or state any condition under which this tool should not be used, so it stops short of explicit when-not guidance.

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?

No annotations, so the description carries the full burden. It does disclose a meaningful side effect — the token is persisted to OS storage — which is more than nothing. However it says nothing about failure modes (invalid/expired code), token lifetime, or what the caller gets back, which matters for a state-mutating auth step.

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 short sentences, zero filler, with the step-role front-loaded and the mode exception 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?

A state-mutating auth tool with no annotations and no output schema needs the description to cover more: it omits prerequisites (must yandex_login run first?), error behavior on a bad code, and what a successful call yields. The step-2 framing and the storage side effect are useful but leave real gaps.

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 there is a single optional parameter, so the schema already explains both the 'code' argument and its localhost exemption. The description's note that no arguments are needed in localhost mode duplicates what the schema already states, adding no new semantics. Baseline 3 is correct.

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: exchanging a confirmation code for a token, explicitly framed as 'step 2 of login', which positions it against the yandex_login / yandex_auth_status siblings without naming them. An agent can tell this is the token-exchange step rather than the credential-entry step.

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 clear usage context (step 2 of the login flow) and an explicit mode-dependent rule: in localhost mode it is called without arguments. It stops short of naming the preceding tool or stating what to do if the code is missing/expired, so it is clear guidance without full routing.

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