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

With no annotations, the description carries the full burden. It partially meets it by stating that every finding comes with evidence and by enumerating audit areas. However, it does not disclose whether the tool only reads the site, how it behaves under crawl limits, or what operational constraints apply; 'audit' implies read-only, but much behavior is left to inference.

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?

The description is two compact sentences with no filler; the audit areas are front-loaded and the evidence guarantee follows immediately. Every clause adds useful information, and it is appropriately sized for a tool with only two schema-covered parameters.

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 tool has no output schema and no annotations, so the description should clarify what the returned findings look like; 'each finding with evidence' is vague about evidence structure and categories. It also omits practical constraints such as crawl time, error conditions, or how results are organized. The schema covers input limits, but an agent still lacks enough detail to interpret the output confidently.

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. The schema already documents url and max_pages, including the default and maximum values, and the description adds no parameter-specific meaning beyond the general audit scope. It does not explain how max_pages affects the depth or completeness of the audit.

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 clearly states a specific action and resource: a technical site audit, and lists audited areas (indexing, metadata, headings, canonical URLs, markup, internal linking). This distinguishes it from the sibling keyword/tracking tools. It could be sharper by naming a concrete output artifact, but the purpose is unambiguous.

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 no explicit when-to-use guidance, no prerequisites, and no mention of alternatives or exclusions. The only usage signal is the generic 'technical audit' phrase, so an agent is not told when to choose this over other SEO tools like get_action_plan or get_competition.

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 behavioral-transparency burden. It does communicate that the tool is investigative reconnaissance and lists what it analyzes, implying a read-only operation. However, it does not explicitly state safety, data sources, limitations, cost behavior, or output format; only the 'n' schema description mentions paid calls.

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 with no filler. The first sentence front-loads what the tool does, and the second gives the key usage instruction. Every phrase 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?

The description covers the tool's analysis dimensions and when to call it, but the context is incomplete: there is no output schema, no annotations, two undocumented parameters, and no differentiation from closely related sibling tools. An agent knows the intent but lacks enough detail to confidently supply 'region' or 'our_domain' or to predict the returned structure.

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 only 50%: 'query' and 'n' have descriptions, while 'region' and 'our_domain' have none. The tool description does not compensate for the undocumented parameters or add meaning to the schema. The mention of 'целевой запрос' restates the query parameter rather than adding new semantic value.

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 concrete activity ('Разведка перед написанием статьи') and enumerates specific outputs: частотность, конкурентность, состав топ-10, форматы заголовков, разрывы, связанные запросы. This is a clear verb+resource statement, though it does not explicitly distinguish itself from sibling research tools such as research_keywords or get_serp_results.

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 second sentence gives explicit workflow guidance: 'Вызывать до того, как писать бриф копирайтеру.' This tells an agent when in the process to invoke the tool. It does not mention when not to use it or point to alternatives, so it misses the exclusions part of a 5.

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 behavioral burden. It discloses that the tool spends Search API requests (cost) and defines the output concept (three outcomes). It does not mention rate limits, response structure, or whether it is read-only (implied by 'check'). Missing details like error conditions or pagination.

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 the primary purpose, then outcome types, and a cost warning. Efficient and well-ordered, though the cannibalization explanation could be slightly condensed. No wasted words.

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 covers the core concept and outcome types, which is sufficient for understanding the tool's function. However, with no output schema and no explanation of the return format (e.g., list of articles with status), an agent may not know how to interpret the result. It also does not clarify how depth, region, or project_id affect results beyond schema definitions.

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 67%: depth and project_id have descriptions, region does not. The description adds no parameter-specific information beyond what the schema already provides. It fails to compensate for the undocumented 'region' parameter, leaving the agent without clarity on its role or required format.

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 clearly states the tool gets positions of blog articles by their target queries and explains the three possible outcomes (article ranks, cannibalization by another page, or nothing). The verb 'снять' (get) and resource 'позиции статей' are specific. It does not explicitly differentiate from sibling tools like get_positions, but the cannibalization focus makes it distinct.

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 implies this is for checking article-specific rankings and warns that Search API requests are consumed, which is a cost consideration. However, it does not explicitly state when to prefer this over sibling tools (e.g., get_positions) or exclude use cases. The cost note is useful but not a full usage guideline.

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?

The description discloses key behavioral traits: it shows candidates by default and writes only when apply=true, including that each candidate comes with a reason. This is beyond what annotations (none provided) offer. However, it does not disclose potential side effects of writing (e.g., what happens to existing pool entries), rate limits, or authentication needs. For a write-capable tool, this is decent 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?

The description is two concise sentences, front-loaded with the primary purpose and then the key behavioral distinction (default vs apply=true). Every word contributes; no fluff or redundancy. It is well-structured for quick comprehension.

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 tool has 6 parameters, no output schema, and no annotations. The description does not explain the return format (what 'candidates with a reason' means), error handling, prerequisites for writing (e.g., is project_id required?), or the meaning of region. For a complex tool that can write, this is inadequate. It leaves an agent guessing on several critical aspects.

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 description adds meaning to seed (via 'seed-фраза') and apply (via 'записывает при apply=true'), but it does not clarify limit, region, min_freq, or project_id. With schema coverage at 50% (only apply, limit, min_freq have descriptions), the description partially compensates but leaves half the parameters unexplained. It adds some value but not enough to cover the gaps.

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 clearly states the tool's action: 'Предложить новые запросы в пул отслеживания по seed-фразе через Wordstat' – proposing new queries to the tracking pool based on a seed phrase via Wordstat. It specifies the resource (pool), the input (seed phrase), and the data source (Wordstat), making it distinct from siblings like research_keywords or track_query. No tautology or ambiguity.

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 does not provide any guidance on when to use this tool versus alternatives. It only states the purpose but does not mention exclusions, prerequisites, or contrast with sibling tools such as research_keywords or track_query. An agent must infer the use case from the purpose alone, with no explicit routing.

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 of behavioral disclosure. It mentions output categories (sites vs. large platforms) but does not describe any side effects, permissions, data limits beyond the 10-query cap, or output format. This is a significant gap for a tool that lacks annotation support.

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?

The description is a single, concise sentence in Russian that conveys the core function without fluff. It is front-loaded with the primary purpose. However, it could be structured into bullet points for clarity, but as is, it is appropriately brief.

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 tool with no annotations and no output schema, the description is incomplete. It does not explain the parameters, the return value structure, or when to invoke this tool relative to competitors. An agent would lack crucial information 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?

The schema has two parameters (region and queries) with 0% description coverage. The description only mentions the query count limit (up to 10) but does not explain the meaning of 'region' or the exact format/content of 'queries'. Since the schema provides no defaults or descriptions, the description must compensate, but it fails to do so.

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 purpose: identifying search competitors that recur across a set of queries (up to 10), and distinguishes them into sites and large platforms. It is clear about the resource (SERP competitors) and the action (find), but it does not explicitly name sibling tools or contrast with them, so it falls short of a top score.

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 versus alternatives like get_competitor_keywords or get_competition. The description implies a use case (analyzing repeat competitors across queries) but gives no explicit context, conditions, or exclusions.

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 transparency burden. It discloses that the tool sends queries to providers, that without confirm it returns only an estimate, and that with confirm it spends money and writes results to history. It even quotes a specific cost (Yandex 5.08 ₽ per query), which is strong 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, front-loaded with the core purpose, then the cost/confirm caveat. Every phrase contributes information: what the tool does, what the estimate costs, what confirm changes, and what is recorded. Zero 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?

The tool has no output schema and no annotations, so the description must explain outcomes. It does — it states the check returns whether the domain appears among sources, with address, position, and who is cited instead, plus the cost estimate behavior. This is sufficient for an agent to call it correctly, though minor details like what 'history' contains are left 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 coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining the estimate/paid distinction tied to confirm, the default provider behavior (all configured), and the kind of output produced (address, position, alternatives). These details help an agent understand parameter effects without opening 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?

The description answers a specific question — 'does AI search cite the site?' — and explicitly describes the mechanism: sends queries to providers and checks whether the domain appears among sources, with address, position, and alternatives. This clearly distinguishes it from siblings like get_serp_results (classic SERP) and geo_providers (provider configuration).

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 clearly explains the two modes (estimate without confirm, paid run with confirm) and the cost implications, giving an agent enough context to decide when to invoke it. However, it does not explicitly name alternative tools or exclusion criteria, so it falls short of providing full when-not-to-use 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?

With no annotations, the description carries the full burden, and it does add value by stating 'Ничего не тратит' (spends nothing) and using 'История' to imply a read-only historical view. It does not cover data freshness or limits, but the cost-free/read-only behavior is meaningfully 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?

Two short sentences with no filler. The core purpose and output are front-loaded, and the cost note is compact and useful.

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 is adequate for a simple historical query tool: it states the purpose, the filter dimensions, the key metrics, and the no-cost behavior. However, without annotations or an output schema, it leaves provider semantics and filter combination ambiguous, and it does not say when to choose this over related geo tools.

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 75%, covering limit, query, and domain; provider is left as an enum without explanation. The description adds that domain or query can act as filters and describes the result contents, but it does not clarify how provider interacts with the other filters or whether they combine.

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 clearly identifies the resource: history of visibility checks in AI answers, scoped by domain or query. It also lists the returned metrics (citation count, share, frequent competitors), which distinguishes it from siblings like get_position_history and geo_check_visibility.

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 explicit guidance on when to use this tool instead of related geo tools. The phrase 'по домену или запросу' only describes filtering, and 'Ничего не тратит' implies safe usage but does not route the agent between alternatives.

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?

The description discloses that the tool 'ничего не тратит' (spends nothing), which is a behavioral guarantee beyond the schema. It also implies it is a read-only configuration check. However, with no annotations provided, the description carries the burden; it could add more detail about what exactly is returned (e.g., list of providers vs. statuses), but the cost-free and non-destructive nature is clearly conveyed.

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?

The description is compact and front-loaded: it states the main purpose first, then the cost implication, then the usage instruction. Every sentence adds value, and there is no redundancy or 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 zero-parameter, read-only informational tool, the description is nearly complete. It explains what the tool does, that it is free, and when to call it. The only minor gap is that it doesn't specify the exact output format or whether it returns a list of providers with statuses, but given the simplicity and no output schema, this is a minor omission.

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 schema is trivially complete. The description adds context about what the tool reports (providers, missing keys, cost), which is useful even though there are no parameters to explain. Baseline 4 is appropriate for a no-parameter tool.

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 clearly states the tool's purpose: it lists configured AI answer providers (Yandex, Perplexity, OpenAI, Gemini, Claude), missing keys, where to get them, and call cost. It uses a specific verb ('Какие провайдеры настроены') and resource ('провайдеры ИИ-ответов'), and it is distinguishable from siblings like geo_check_visibility or get_storage_stats.

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 explicitly says to call this tool first before checking visibility ('Вызывать первым перед проверкой видимости'), giving clear usage context. It also states that it costs nothing, which helps an agent decide when to invoke it without risk.

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 behavioral burden. It does disclose that the tool 'doesn't spend anything' and that each finding includes evidence and recommended actions, which is useful context. However, it does not clarify whether it fetches pages, whether it modifies anything, or what limits apply.

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, with the core purpose and checklist front-loaded. The second sentence adds value about output format and side-effect behavior. Slightly dense as a run-on list, but no wasted words.

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 covers what is checked and what the output looks like, which is adequate for a read-only audit. It lacks guidance on parameter usage, how many pages are checked by default, and how it relates to sibling tools, leaving some gaps for an agent deciding when to invoke it.

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 parameters. The description adds no extra meaning about the url or pages parameters, but it does not need to because the schema is self-sufficient.

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 clearly identifies the tool's focus: assessing a site's readiness for AI search without API keys, and lists concrete aspects (llms.txt, robots.txt AI bots, JSON-LD, FAQ markup, Markdown versions). It lacks a direct verb like 'check' or 'audit', but the resource and scope are specific enough to distinguish it from generic 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 explicit statement about when to use this tool versus alternatives such as geo_check_visibility, audit_site, or geo_history. The phrase 'without keys' implies a use case, but no exclusions, prerequisites, or sibling comparisons are provided.

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 does a good job: it discloses that the tool performs an HTTP readiness check to the site itself, that it makes no paid requests, and that it only uses data already in the database—otherwise it names a tool and estimate rather than inventing data. This goes well beyond a generic 'get plan' description and gives important operational expectations.

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?

The description is dense but not bloated: two long sentences pack the priority categories, per-item contents, data sources, and key constraints. It is front-loaded with the main purpose and every clause adds useful information. Slightly over-long for trivial reading, but justified for a tool of this complexity.

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 and no annotations, the description explains the output structure well: each item has evidence, measurement date, instruction, verification method, and a deadline. It also covers data sources and the fallback behavior when data is missing. It would be more complete with explicit guidance on output JSON shape or when a fresh audit is triggered, but it is close to sufficient for safe selection.

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 input schema has 100% description coverage, so the baseline is 3. The description does not explain individual parameters but does enrich the meaning of the `sections` values (e.g., quick wins defined by Webmaster positions 4–15 and tracker 4–10). Parameters like `limit`, `fresh_audit`, and `max_pages` remain adequately covered by the schema alone.

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 clearly states that the tool outputs a prioritized site-editing plan with named categories (indexing, quick wins, snippet, cannibalization, AI search, competitor gaps, etc.), which is distinct from sibling tools that return raw positions, audits, or keyword metrics. The verb/resource relationship is clear: it returns an action plan.

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 context is implied rather than explicit: the description explains that the plan is built from an audit, readiness check, and existing database data, which suggests it is for synthesizing existing data into actionable tasks. However, it does not explicitly state when to use this tool over alternatives like audit_site, get_positions, or build_brief.

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. It explicitly states that no new API requests are made, indicating a read-only, historical operation, and describes the report contents. This is meaningful behavioral disclosure, though it lacks details on permissions or 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?

The description is two concise sentences that immediately state the report's content and the historical, non-mutating nature of the call. Every word adds value, and it is efficiently 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 tool with a single parameter, no output schema, and no annotations, the description adequately conveys what the report contains and that it is historical. It does not detail the exact structure of the verdict or delta, but an agent can reasonably infer the expected output. Minor gaps remain, but it is nearly complete for its simplicity.

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 sole parameter, project_id, is an integer with a self-explanatory name, and its meaning is clear from the schema even without description text. The description does not add any further explanation, but the parameter is simple enough that the schema name suffices; a baseline 3 is appropriate given the low schema 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?

The description clearly states the tool returns a report on blog articles including a verdict, delta, and cannibalization list. It identifies the resource (blog articles) and the specific outputs, but does not explicitly distinguish it from sibling tools like check_articles, so it falls 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 notes that data comes from history and that no new API requests are made, implying it is a lightweight read-only call. However, it provides no explicit guidance on when to choose this tool over alternatives, nor any exclusions or context for selection.

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 must carry transparency burden. It mentions 'with full breakdown by factors and evidence', giving some insight into output, but does not disclose side effects (likely read-only), data source, complexity, or rate limits. It is a read-like analysis tool, but without annotations, the absence leaves gaps.

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?

The description is two sentences, concise and front-loaded with the purpose, then the usage guidance. No fluff, each 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?

Given 3 parameters, no annotations, no output schema, and 0% schema coverage, the description is insufficient. It does not explain input structure, output format, or how parameters relate, leaving an agent guessing on how to invoke 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?

Schema description coverage is 0%, so the description must explain parameters. It provides no definition of 'query', 'region', or 'queries', and does not clarify that 'queries' is an array or how multiple queries are handled. The description is in Russian and may add language context, but for parameter semantics it adds nothing.

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 tool analyzes query competitiveness (Конкурентность запросов) and provides factor breakdown and evidence, which is a specific verb+resource. It explains when to use it (to understand why a query is complex), but does not clearly differentiate from siblings like research_keywords or get_serp_results, which may also relate to competition.

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 says 'Use when you need to understand WHY a query is complex', which gives some usage context, but does not specify when NOT to use it or list alternatives. There is no guidance on choosing between this and similar tools like get_keyword_metrics or research_keywords.

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 behavioral burden and reveals an important trait: the tool performs no new API calls and relies on accumulated SERP snapshots, signaling a read-only, cache-based operation. It does not detail error behavior, authentication, or pagination, but the core operational behavior is 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?

Two front-loaded sentences: the first states the tool's output clearly, the second discloses implementation behavior. No redundant words, and the information density is high for the tool's complexity.

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 explains core value and data source, but without output schema or annotations it does not fully describe result shape, the meaning of region, or how 'top' is defined. An agent could call it with just the required domain, yet some context about optional parameters and output format remains 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?

The description maps two parameters conceptually: 'competitor' refers to domain and 'нас' (us) implies our_domain for comparison, complementing the schema descriptions. However, the region parameter is left without any semantic explanation in either the schema or the description, and 67% schema coverage leaves a gap.

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 clearly identifies the tool's purpose: showing queries where a competitor ranks in the top and where our domain is absent. It also adds a differentiator by stating it is built from accumulated SERP snapshots and performs no new API requests, but it does not explicitly name a sibling tool or use an imperative verb.

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 statement that the tool is based on accumulated snapshots and does not make new API requests implies when it is appropriate (using cached data) and when not (needing fresh results). However, it provides no explicit comparisons to alternatives or exclusion conditions, leaving usage inference to the agent.

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 25-query limit and the competition calculation basis, which is non-obvious. However, it does not mention output structure, error behavior, or whether the tool is read-only, so transparency is partial.

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?

The description is two short sentences with no filler. The core purpose is front-loaded, followed immediately by the key constraints and methodology. 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 simple metrics tool, the description covers purpose, query limit, and methodology. However, with no output schema and no annotations, it does not state the return format or any limit/error behavior, leaving a meaningful gap for an agent that needs to consume the result 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 schema documents region and with_competition but not keywords. The description adds meaning to keywords by describing them as a list of queries limited to 25, and it explains what competition means for with_competition. Region remains only schema-documented, so the description does not fully compensate, but it adds real value.

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 opens with a specific action and resource: frequency and competitiveness for a list of queries, including a hard cap of 25. It also clarifies how competitiveness is calculated. However, it does not explicitly differentiate from sibling tools like get_competition or research_keywords.

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 intended use case is clear: call this when you need frequency and competitiveness for up to 25 queries. The methodology note about Yandex SERP composition and ignoring link weight gives context that helps with tool selection, but it does not explicitly name alternatives or state when not to use this tool.

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 behavioral disclosure burden. It only states that the tool returns history and competitiveness dynamics; it does not explain output format, time range, rate limits, or whether this is a read-only operation, which is a meaningful 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?

The description is a single compact sentence with no filler or redundant phrasing. It opens with the core resource ('История позиций домена') and adds the secondary component ('динамика конкурентности') efficiently.

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 tool with three parameters, no annotations, and no output schema, the description omits too much operational context. An agent would not know how to set the region, what the returned history looks like, or how this differs behaviorally from close siblings like get_positions.

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 clarify the parameters, but it only loosely references 'domain' and 'one query'. The required 'query' parameter is not explicitly explained, and the 'region' parameter is entirely absent from the description.

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 clearly identifies the tool's subject: a domain's position history for a single query, plus competitiveness dynamics for that query. It is specific enough to distinguish the core concept from current-position tools like get_positions, though it does not explicitly name any sibling or contrast 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?

The description gives no guidance on when to use this tool versus alternatives such as get_positions, track_query, or geo_history. It implies a single-query historical scope but does not state that implication or provide any exclusion criteria.

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 of behavioral disclosure. It goes beyond a simple getter by explicitly stating that no new API requests are made and data comes from history, which is valuable for avoiding unintended side effects. It doesn't mention errors, permissions, or response format, but the core non-obvious behavior is 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?

Two short, front-loaded sentences with no filler. The first sentence communicates the core output, and the second delivers the crucial behavior about making no new API requests. Every word 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?

The description is adequate for a simple read-style endpoint, but with no output schema and no annotations, it leaves gaps around parameter meaning, required fields, and return structure. An agent can guess the intent but not fully know how to construct the call correctly, especially for 'region'.

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%, and the description does not explain either parameter. 'domain' is inferable from context, but 'region' remains ambiguous as an integer (ID? country code? search region?). The tool relies entirely on parameter names, which is insufficient for an agent to know what values to provide.

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?

Description states exactly what the tool returns: current domain positions, delta to the previous measurement, and lists of grown/fallen queries. This clearly distinguishes it from siblings like get_position_history, which would return historical series, and run_tracking, which triggers new tracking.

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 phrase 'Данные из истории, новых запросов к API не делает' explicitly signals that this is for reading existing historical data without triggering new API work. It doesn't name specific alternatives or state when-not-to-use, but the context and sibling names imply the distinction.

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 conveys that results are 'live' Yandex output, implying a read-only network fetch, but it does not disclose rate limits, caching behavior, failure modes, or whether results are snapshotted or transient. For a tool with zero annotation coverage, this is a notable 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?

The description is a single efficient sentence that front-loads the core purpose and lists returned fields without fluff. It could be slightly more structured, but it earns its place and is appropriately sized.

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 that there is no output schema and no annotations, the description should provide enough operational context for an agent to call the tool correctly. It names outputs but leaves region semantics, relationship to the many sibling tools, and behavioral caveats unaddressed, so it is not complete enough.

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 only 33%: only 'n' is documented. The description mentions 'по одному запросу' but does not explain the 'query' or 'region' parameters, their formats, or how they affect results. With coverage this low, the description should compensate and does not.

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: it returns live Yandex SERP data for a single query, and enumerates the returned fields (positions, domains, titles, URL depth, page counts). It is clear enough to distinguish from sibling tools like get_position_history, though it does not explicitly name any sibling.

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 phrase 'по одному запросу' implies this tool is for single-query live SERP retrieval, which gives some usage context. However, it does not explicitly state when to prefer this over siblings like get_positions, track_query, or find_serp_competitors, and offers no exclusions.

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 must carry the full behavioral burden. It implies the tool reads already-accumulated data, but it does not explicitly state that it is read-only, what the response contains, or any freshness or scope limitations.

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?

The entire description is a single compact sentence, front-loading the database context and listing useful content categories without 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 parameterless tool this is minimally adequate: the description names the data areas returned. However, with no output schema and no annotations, it leaves the return format and read-only nature implied rather than explicit, and it does not orient the agent among the many sibling data tools.

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 and 100% schema coverage, so parameter documentation is unnecessary. The description still adds value by clarifying which stored-data categories the result covers.

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 (yaseo database) and enumerates the data categories it exposes: snapshots, position measurements, competition history, and frequent result domains. It does not explicitly state that it returns or aggregates these, and it overlaps conceptually with siblings like get_positions and get_competition, so it stops short of a full 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?

There is no guidance on when to use get_storage_stats instead of related tools such as get_positions, get_competition, or get_serp_results. The list of content suggests an overview use case, but no when-to-use or when-not-to-use context is provided.

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 present, so the description carries the full behavioral burden. It discloses the execution mechanism (Wordstat), the scope (RF), and the output shape (frequency and related queries), which makes the tool's behavior predictable. It does not mention side effects, auth, or rate limits, but this is a research operation and there is no contradiction with any annotation.

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?

The description is a single compact sentence that front-loads the action and resource. The positioning clause 'Основной инструмент подбора семантики' adds useful context without wasted words.

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 tool with four parameters and no output schema, the description supplies the essential completion criteria: it expands seeds via Wordstat and returns frequency and related queries. It does not detail the exact response structure, but the schema coverage and the tool's simplicity make the description sufficiently complete.

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 schema already describes all four parameters, so the baseline is 3. The description reinforces that seeds are 1–5 phrases and the region is RF, but it does not add substantial meaning beyond the existing parameter descriptions.

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 uses a specific verb, 'Расширить' (expand), names the resource (1–5 seed phrases via Wordstat), and states the output (frequency and related queries for RF). It also positions itself as the main semantic-research tool, though it does not explicitly distinguish itself from sibling expand_query_pool.

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 clear context: use this as the primary tool for keyword selection and seed expansion via Wordstat. It lacks explicit exclusions or when-not-to-use instructions for alternatives, but the stated primary-tool role provides enough guidance for an agent.

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. It reveals side effects: spending Search API calls and writing a history measurement. It also provides the important no-op guarantee: the run stops before the first request and spends nothing when limits would be exceeded, and it discloses the blocked-response 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?

Three sentences with no filler, front-loaded with purpose, then cost, then guardrails. Every sentence adds decision-relevant 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?

Covers purpose, cost, failure modes, and the unblocking parameter despite having no output schema. The main omissions are success-return behavior and the meaning of region, but the description is nearly sufficient for a first 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 80%, so the schema already documents most parameters. The description adds a use-case link for now (how it lifts the restriction in blocked runs), but it does not materially extend domain/queries/competitors semantics. Region remains undescribed in both schema and description.

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 clear action: capture current positions for tracked queries and persist a measurement to history ("Снять текущие позиции по отслеживаемым запросам и записать замер в историю"). This distinguishes it from sibling tools like track_query or get_positions by emphasizing tracked-query scope plus the history write, and it also flags Search API cost.

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?

Explains when running makes sense and the constraints: a run consumes Search API quota, and aborts before any request if it would exceed YASEO_TRACKING_MAX_CALLS or violate YASEO_TRACKING_MIN_INTERVAL_DAYS. It also tells the agent how to respond to blocks via the now parameter. It does not explicitly name sibling tools as alternatives, so no exclusions are given.

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 discloses the basic action (add/remove queries) but does not mention any side effects, such as whether removing a query deletes historical data, whether the operation requires specific permissions, or whether it is idempotent. It also does not state what happens on success or failure. For a state-mutating tool with zero annotation coverage, this is a significant transparency 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?

The description is concise, just two sentences, and front-loads the core action (add/remove) before giving the run_tracking context. There is no fluff or repetition. It could be slightly more informative without losing efficiency, but it is well-structured for its length.

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 tool has 4 parameters, no output schema, and no annotations, so the description must carry a lot of weight. It only explains the general purpose and the relationship to run_tracking, but it does not describe the parameters, expected return values, edge cases, or prerequisites (such as authentication via whoami). An agent would have to guess at the 'region' semantics and the response format, making the description inadequate for confident 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 only 25% (only the 'remove' parameter has a description). The tool description itself does not explain the meaning of the 'region' parameter, nor does it clarify the difference between the singular 'query' and the plural 'queries' (when to use one over the other). It repeats the general purpose but fails to add value beyond the schema for the three undocumented parameters, so it does not compensate for the low 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?

The description clearly states the verb and resource: 'Поставить запросы на регулярное отслеживание позиций или снять их' – to put queries on regular position tracking or remove them. It also mentions that tracked queries are used by run_tracking, which helps place the tool in context. However, it does not explicitly differentiate from siblings like get_positions or run_tracking beyond the mention, so it stops short of a perfect score.

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 implies usage by stating 'Отслеживаемые запросы использует run_tracking' – tracked queries are used by run_tracking – which suggests you should use this tool to manage the set of queries before running tracking. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives such as get_positions or get_position_history. It gives some context but no exclusions.

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?

The description states 'Ничего не тратит' (spends nothing), which is a behavioral disclosure that the tool has no side effects or resource consumption. While annotations are absent, this statement provides useful behavioral context. It doesn't detail what happens if config is missing, but the description covers the key behavioral trait.

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?

The description is concise, with two sentences that front-load the purpose and then add usage guidance. Every sentence earns its place: the first explains what it does, the second explains when to use it. No wasted words.

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, no-output-schema tool, the description is quite complete. It explains what the tool checks, that it's free, and when to call it. It doesn't describe the output format, but with no output schema, that's a minor gap. The description gives enough for an agent to use 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?

The tool has zero parameters, so the schema provides no parameter information. The description compensates by explaining what the tool checks (keys, database path, default domain), which gives context about what the tool operates on. With 0 params, baseline is 4, and the description adds relevant context.

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 clearly states the tool's purpose: checking yaseo configuration, including key sources, missing keys, where to obtain them, database path, and default domain. It uses a specific verb ('Проверить') and resource ('конфигурацию yaseo'), making it distinct from sibling tools that perform actions like tracking, auditing, or research.

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 explicitly says to call this tool first before spending requests ('Вызывать первым, прежде чем тратить запросы'). This provides clear when-to-use guidance and implies it should be used before other tools, which is strong usage guidance.

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