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

Annotations are absent, so the description bears the full behavioral burden for a mutation tool. It does not state whether adding an already-existing host fails, whether verification is subsequently required, what permissions are needed, or what the return confirms.

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 zero padding. It is efficient, though arguably too terse to be maximally 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?

With only two well-documented parameters and no parameters requiring complex semantics, the definition is minimally adequate. However, for a mutation tool with no annotations, the absence of guidance on duplicate handling, verification flow, or permissions leaves meaningful 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%, with both user_id and host_url documented and an example URL given, so the baseline is 3. The description adds no meaning beyond the schema and does not map 'site' explicitly to host_url.

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?

Specific verb 'Add' plus resource 'new site' (host) makes the operation clear, even though it uses 'site' for the host_url parameter. It does not distinguish itself from siblings like delete_host, verify_host, or add_sitemap, but the core action 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?

No when-to-use guidance, no prerequisites (e.g. ownership/verification requirements), and no mention of alternatives such as verify_host. The agent must infer entirely from the tool name and sibling list.

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, yet it only says 'Add.' It does not disclose that this is a mutating operation, whether the user must own the host, whether adding is idempotent or errors on duplicates, or what authentication is required. The only behavioral signal is the implied write from 'Add.'

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 short sentence that is front-loaded and has no filler. It is concise, though trivially so given how little information it conveys.

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 output schema exists so return values need no explanation, but for a mutation tool with no annotations, three required parameters, and many sibling sitemap tools, the description is too thin. It omits prerequisites, ownership requirements, duplicate handling, and how it differs from other sitemap operations.

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 all three parameters (user_id, host_id, sitemap_url) are well documented in the schema itself, including format examples. The description adds no parameter meaning beyond the schema, 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?

States a verb and resource ('Add a sitemap'), which is clear enough in isolation, but the title is identical and the description adds nothing to distinguish it from the many sitemap siblings (get_sitemaps, get_user_added_sitemaps, delete_sitemap, get_sitemap_info). No scope or host/user context is given.

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 when-to-use guidance, no prerequisites for adding a sitemap, and doesn't mention alternatives like get_user_added_sitemaps or how this relates to verification. The agent must infer usage entirely from the 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state that this is a destructive, irreversible operation, whether permissions beyond the user_id are required, whether sitemaps or verification data are also removed, or whether dependent workflows are affected. For a deletion tool with zero annotation coverage, this is a significant 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 short sentence that is front-loaded with the action and context. It is efficient, though its brevity reflects under-specification rather than optimal terseness.

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 this is a destructive mutation tool with no annotations and an output schema that presumably describes the result, the description is too sparse. It omits critical context an agent would need: confirmatory behavior, prerequisites, side effects on related entities, and error conditions.

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 user_id and host_id are already fully documented in the schema, including the host_id format. The description adds no parameter-specific meaning beyond what the schema supplies. Baseline 3 applies when the schema does the heavy lifting.

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 clear verb+resource: 'Remove a site from Yandex Webmaster.' It does not differentiate this tool from its inverse sibling add_host, though the operation is fundamentally distinct (remove vs add). The purpose is understandable but lacks sibling-specific framing such as naming the counterpart tool.

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 or when not to use this tool, nor any mention of alternatives. The description does not clarify prerequisites such as whether the host must exist, whether verification must first be revoked, or what happens to dependent resources (sitemaps, recrawl tasks).

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 says 'Delete' but never states that the action is irreversible, whether it requires host ownership or verification, or what side effects occur on the sitemap's indexed URLs.

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 short sentence with the verb and scope front-loaded and no filler. It is efficient, though it may be too terse given the operation is destructive.

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 is a destructive mutation with no annotations and no output-schema explanation needed, yet the description never addresses irreversibility, permissions, or error conditions. Given the absence of structured behavioral hints, a bare one-line description leaves significant 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%, so all three parameters (user_id, host_id, sitemap_id) are already documented with formats and meaning. The description adds no parameter-level detail beyond the schema, which is the expected baseline when coverage is high.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Delete) and resource (sitemap), with the qualifier 'user-added' that distinguishes it from the plain sitemap operations. It does not name the sibling add_sitemap or get_user_added_sitemap_info, but the scope is clear enough to select it correctly.

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 on when to use this versus alternatives such as get_user_added_sitemaps or get_user_added_sitemap_info, and no prerequisites stated. The agent must infer that this is the removal counterpart to add_sitemap.

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 implies a read operation via "Get" and hints at the result taxonomy (FATAL, CRITICAL), but says nothing about required permissions, whether the host must be verified, throttling, or whether results are paginated.

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; the resource and its content domain are established immediately.

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 an output schema present, return values need not be explained, and both parameters are fully documented. However, for a tool that depends on a verified host and user context, the absence of any prerequisite or scoping note leaves a modest gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: both host_id (with format example) and user_id are documented in the schema itself. The description adds no parameter-level meaning, 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 ("Get site diagnostics") and names the content domain — problems and recommendations with severity levels — which helps distinguish it from the many history/sample siblings. It does not explicitly differentiate itself from neighbors like get_summary or get_host_info, so it stops 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?

No when-to-use guidance, no prerequisites (e.g. host verification), and no mention of alternatives among the ~35 sibling tools. The agent must infer that this is the entry point for surfacing site health issues.

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 of disclosure and falls short. 'Get' implies a read, but nothing is said about permission requirements, whether the sample is capped, or how pagination behaves in practice; only the word 'samples' hints at a bounded result set.

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. The verb and resource lead, and the parenthetical earns its place by disambiguating 'external links'.

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 output schema exists so return values need no explanation, and all four parameters are documented in the schema. What is missing is the operational context an agent needs to choose this tool over get_external_links_history, which the description never addresses.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter (limit, offset, host_id, user_id) is already documented in the schema, and the description adds no format or interpretation details. Baseline 3 applies when the schema does the heavy lifting.

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?

Clear verb ('Get') plus resource ('external links (backlinks)') with a clarifying parenthetical that resolves the term for an agent. The word 'samples' hints at a scoped subset, but the description never distinguishes this tool from the sibling get_external_links_history, leaving their boundary 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?

No statement of when to use this tool versus get_external_links_history or any other sibling, and no prerequisites or preconditions given. The agent must guess that 'samples' means a small illustrative set rather than a full/historical listing.

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. 'Get' implies a safe read, and 'count over time' implies a time series, but it says nothing about the granularity of history, the time window returned, rate limits, or whether data is scoped to a user/host pair.

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 arguably terse enough that it sacrifices some useful context for brevity.

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 output schema exists, so return-value shape need not be explained, and both required params are documented. However, for a history tool the description omits period granularity and default time range, leaving a real gap in how an agent would frame the call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with both parameters (host_id with format example, user_id) fully documented in the schema. The description adds no parameter meaning beyond that, 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 verb ('Get'), resource ('external links count'), and scope ('history ... over time'), which implicitly distinguishes it from the sibling get_external_links (current snapshot). It never names that sibling explicitly, so differentiation relies on 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?

'over time' implies this is the temporal-series variant versus the point-in-time get_external_links, but the description offers no explicit when-to-use, when-not-to-use, or named alternative. Usage is implied 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?

No annotations are provided, so the description carries the full behavioral burden. "Get" weakly implies a read operation, but nothing is said about authorization requirements, whether it can fail for unverified hosts, rate limits, or the nature/format of the returned detail.

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 short, front-loaded sentence with no filler or repetition. It is structurally clean, though its brevity comes at the cost of substance rather than from tight editing.

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 presence of an output schema and 100% parameter schema coverage means return values and parameter formats need not be explained here. However, with no annotations and no usage guidance, the description leaves a real gap in distinguishing this tool from its many read-oriented 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% (host_id format and user_id are documented inline) and there are only 2 parameters, so the baseline is 3. The description adds no additional meaning about how these parameters behave or interact.

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 generic verb+resource ("Get detailed information about a specific site") but it essentially restates the title "Get Host Info" and swaps "site" for "host", which is inconsistent with the parameter naming (host_id). It does not distinguish this tool from siblings like get_summary, get_hosts, or get_verification_status.

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. With siblings such as get_hosts (list) and get_summary (summarized data), the agent gets no signal about which to pick or what preconditions exist.

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 supplied, so the description carries the full behavioral burden. It implies a read-only list retrieval but says nothing about required permissions, whether only verified owners are returned versus pending ones, or any ordering/pagination 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?

A single short sentence with no wasted words and the purpose front-loaded. It is efficient, though arguably terse to the point of omitting context that would help selection.

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 output schema exists, so return values need not be explained, and both parameters are documented. However, for a tool with no annotations the description leaves the verification semantics and call context unstated, making it only minimally adequate.

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%: host_id's format (https:example.com:443) and user_id's meaning are both documented in the schema. The description adds no additional parameter meaning, 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: retrieving the list of verified site owners/managers for a host. It is distinguishable from most siblings (e.g., get_verification_status, verify_host) by resource, though it never explicitly contrasts 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 such as get_verification_status or get_host_info. The agent must infer the context from the name alone.

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 implies a read-only list operation but does not state whether it is paginated, scoped to the caller, or whether it requires authentication beyond the user_id. No mutation or safety context is provided, leaving a list tool with no behavioral clues.

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 compact sentence with no filler. It is appropriately sized for a simple list endpoint.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read tool with a fully covered schema and an output schema, the description is minimally adequate. However, with no annotations and many sibling tools, it lacks scope and usage detail that would help an agent choose it correctly, and the 'sites' versus 'hosts' terminology is slightly incomplete for the tool's name.

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 only one required parameter (user_id), which the schema documents as the Yandex Webmaster user ID. The description adds no extra meaning for user_id, so baseline 3 applies for a fully covered single parameter.

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 (Get) and resource (list of all sites/hosts added to Yandex Webmaster). It is distinguishable from add_host and delete_host by the read verb, but the description calls the resource 'sites' while the sibling list uses 'host', which may confuse agents looking for a host list rather than a site list.

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 when-to-use guidance, no prerequisites, and no mention of alternatives like get_host_info or get_summary. The description is a one-line statement with no routing context.

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, and it largely does not. 'Monitoring history' is left undefined: what metrics, what time window, whether history is paginated or bounded, and whether any permissions beyond user_id are needed are all unstated.

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, tightly scoped sentence with the verb and resource front-loaded and no filler. Nothing can be trimmed without losing meaning.

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 output schema exists, so return values need not be explained, and all three required params are schema-documented. However, with zero annotations and no statement about the nature or extent of the history returned, the definition is only minimally adequate for a read tool in this family.

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%, including the URL format example and the host_id format, so the schema does substantial work. The phrase 'a specific important URL' adds only marginal framing beyond what the schema already documents, 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 (Get) plus a precise resource (monitoring history for a specific important URL), which distinguishes it reasonably from data-returning siblings like get_important_urls. It does not explicitly name the sibling that lists important URLs, so it stops 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?

There is no when-to-use guidance, no prerequisites, and no mention of the obvious alternative (get_important_urls, presumably to discover which URLs are 'important'). The agent is left to infer the workflow entirely.

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?

There are no annotations, so the description carries the full burden. It does not state whether this is a read-only operation, whether it requires the host to be verified, whether results are paginated, or how fresh the data is. Naming three data categories ('indexing status, search status, change indicators') is the only behavioral hint.

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 redundancy or filler. It is appropriately sized for the information it conveys, though the low information density reflects missing guidance rather than true conciseness.

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 output schema exists, so return values need not be explained in detail. However, for a read tool with zero annotations and many similar siblings, the description omits critical context: permission/verification requirements, data freshness, and how it differs from the adjacent get_important_url_history and get_search_urls_* tools. It is minimally complete but leaves the agent guessing about selection and behavior.

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 (user_id and host_id) are fully documented in the schema, including the host_id format. The description adds no parameter-level meaning, which is acceptable at high coverage but not contributory. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a verb ('Get') and resource ('monitoring data for important pages') and enumerates three data categories (indexing status, search status, change indicators). This is more specific than a tautology, but it does not distinguish this tool from its many siblings (e.g., get_search_urls_history, get_important_url_history), nor does it explain what an 'important page' is versus a search URL or sample.

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 indication of when to use this tool versus the dozens of sibling tools that also return URL/monitoring data. There is no mention of prerequisites (host verification), no exclusions, and no alternative named. The agent must infer usage from the name alone.

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 clarifies the shape of the returned data (page counts by HTTP status over time), but says nothing about permissions required, whether results are paginated, rate limits, or typical response granularity for a read-only analytics call.

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 zero filler. The core purpose and the nature of the returned data are both delivered immediately.

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 presence of an output schema means return values need not be explained, and all parameters are covered by the schema. However, with no annotations and no usage routing, the definition is only minimally complete for an analytics tool sitting among many similar history 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 description coverage is 100%, so all four required parameters (user_id, host_id, date_from, date_to) are already documented in the schema. The description's 'over time' phrasing loosely maps to the date range but adds no format or constraint detail beyond the schema, 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 states a specific verb+resource (get indexing history) and adds detail about what the data actually contains: indexed pages broken down by HTTP status over time. This is meaningfully more than the title, though it does not differentiate itself from similarly-named siblings such as get_indexing_samples.

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_indexing_samples or get_search_urls_history. The agent must infer usage from the name alone, and no prerequisites or context 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 must carry behavioral disclosure. It implies a read-only retrieval and discloses a 50,000-URL cap, but omits auth requirements, rate limits, and whether the cap interacts with pagination; schema and output schema cover some mechanics.

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 delivers the core action and cap 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?

With an output schema and fully documented parameters, the call mechanics are mostly covered. However, for a tool among many sibling sample/history endpoints, the absence of usage context leaves the agent guessing when to choose 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 all four parameters. The description adds no parameter-level details, which matches the baseline 3 when schema does the heavy lifting.

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 'Get' and resource 'samples of indexed pages', and gives a scale cap. It does not explicitly distinguish itself from sibling sample tools like get_search_urls_samples, so 4 rather than 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?

No when-to-use guidance, prerequisites, or alternatives are given. The agent is not told when this tool is preferable to get_search_urls_samples or get_indexing_history.

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 not state that results are bounded samples rather than a full set, does not mention permission requirements, and gives no indication of pagination behavior despite limit/offset parameters. 'Samples' hints at partial returns but nothing is spelled out.

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 short, front-loaded sentence with zero filler. It is efficient, though the brevity borders on under-specification rather than genuine conciseness.

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 output schema exists and the input schema is fully described, so return values and parameters need not be repeated. Still, with no annotations and 5 parameters, the definition leaves the agent without scoping, permission, or alternative-tool context.

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 all five parameters (including the indicator filter values and pagination fields) are already documented in the schema. The description adds no additional parameter meaning, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb ('Get') and resource ('broken internal links') with the 'samples' scope qualifier, which implicitly distinguishes it from the sibling get_internal_broken_links_history. However, it never states the boundary explicitly and provides no detail about what a 'sample' contains or how it differs from the history tool.

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 (host/user scoping), and no reference to the closely related get_internal_broken_links_history sibling. The agent must infer selection from the name alone.

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, yet it only describes the data (link counts over time). It says nothing about permission requirements, rate limits, default time-window behavior when date_from/date_to are omitted, or aggregation granularity. The output schema covers the return shape, but behavioral context is thin.

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 efficient sentence with the resource front-loaded and zero filler. It is arguably too terse given the missing guidance, but the sentence itself is clean and 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?

An output schema exists, so return values need not be explained, and the input schema fully documents parameters. However, for a tool with no annotations, the description provides no usage routing relative to its obvious sibling and no behavioral notes, leaving it minimally adequate rather than 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?

Schema description coverage is 100% and every parameter (user_id, host_id, date_from, date_to) is documented in the schema itself. The description adds no parameter semantics beyond the schema, 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 states a specific verb ('Get') and resource ('history of broken internal links count over time'), making the time-series nature clear. It implicitly distinguishes itself from the sibling get_internal_broken_links (current snapshot) via 'history,' but never names or contrasts that sibling explicitly.

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, and no reference to the alternative (get_internal_broken_links for the current count versus this history tool). Usage must be inferred entirely from the name and the word 'history.'

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 discloses one useful trait (the TOP-3000 cap) but says nothing about pagination behavior despite limit/offset parameters, nor about auth requirements or rate limits. Most behavioral context is left unstated.

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; the cap and returned indicators come first. It is efficient, though arguably too terse to carry its informational load.

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 an output schema covering return values and full schema description coverage, the core calling information is present. The remaining gap is routing guidance among the many query-related siblings, which the description does not address, leaving it only minimally 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?

Schema coverage is 100%, so the schema already documents all nine parameters in detail, including defaults and formats. The description only loosely maps its 'indicators (shows, clicks, positions)' phrase to the query_indicator options, adding little beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Get'), a specific resource ('popular search queries'), and a scope ('TOP-3000') with the indicators returned. This is clearly distinguishable from generic siblings like get_sitemaps or get_hosts, but it does not differentiate from closely related siblings such as get_query_history or get_query_analytics.

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 and no alternative named. Given multiple query-related siblings (get_query_history, get_single_query_history, get_query_analytics), an agent gets no help choosing between them, nor any prerequisites (e.g., needing a user_id/host_id pair).

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 mentions '(POST)' implying a mutation method (though this is likely a read operation with a POST body), and states data is limited to the last 2 weeks, which is useful. However, it omits critical behavioral details: whether the POST body requires a JSON payload, authentication requirements, rate limits, and what the response contains. The 2-week limitation is the only substantial 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?

The description is extremely concise—two short phrases—with no wasted words. The data limitation is front-loaded, though the overall content is sparse.

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 the tool's complexity (12 parameters, required user_id and host_id, output schema present) and lack of annotations, the description is too sparse. It fails to explain the tool's relationship to siblings, the POST request format, or any behavioral constraints beyond the 2-week window. An agent would need to infer a lot from the schema alone.

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 all 12 parameters are fully documented in the schema. The description adds no parameter-specific information beyond what the schema provides, so 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 says 'Advanced search query analytics' which restates the tool name (get_query_analytics) without specifying the verb or resource in a way that distinguishes it from siblings like get_popular_queries or get_query_history. It does not clarify what analytics are returned, leaving the agent unable to differentiate its purpose.

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 when-to-use guidance is provided. The parenthetical '(POST)' hints at method but doesn't explain context. The note about 'last 2 weeks only' is a data constraint, not a usage guideline. The agent gets no help deciding between this tool and the many other query-related 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 exist, so the description carries the full disclosure burden. It doesn't mention authentication requirements, Yandex Webmaster ownership constraints, rate limits, or whether results are cached. Only the read-only nature is implied by 'get'.

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 compact sentence that front-loads the tool's purpose and return dimensions. It is efficient but the parenthetical '(all queries)' could be clearer.

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 output schema exists, so return values need not be explained. However, the description is thin for a parameter-rich analytics tool with no annotations and no usage guidance, leaving key operational context to the schema and annotations (which are absent).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description doesn't add syntax or explain how query_indicator or device_type_indicator affect aggregation granularity beyond what the schema already documents.

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 (get) and resource (aggregated search query statistics) with the returned dimensions (shows, clicks, positions by day). It clearly differs from siblings like get_popular_queries and get_single_query_history by emphasizing aggregated statistics, though it doesn't explicitly name the alternatives.

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 explicit when-to-use or when-not-to-use guidance is provided. The phrase 'all queries' hints at scope but doesn't direct the agent to get_single_query_history or get_popular_queries for narrower use cases.

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 burden. 'Get' implies a read-only operation and 'per day' hints at a reset cadence, but it says nothing about the reset timezone, whether the quota is per host or per user, or whether it's shared across the account.

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 a parenthetical that genuinely adds clarity to the resource name. 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?

An output schema exists, so return values need not be explained, and both required parameters are documented in the schema. The description is nearly complete, though a note on quota reset timing or scope would round it out.

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 both parameters (host_id, user_id) are fully documented in the schema with format examples. The description adds no additional meaning about the parameters, 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 states a specific verb (Get) and resource (daily recrawl quota), and the parenthetical clarifies exactly what the resource means (URLs submittable per day). This clearly separates it from siblings like request_recrawl or get_recrawl_tasks, which act on tasks rather than the quota.

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 explicit when-to-use guidance or named alternatives appear. The context of a 'quota' implies the agent should check it before calling request_recrawl, but that inference is left to the reader 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 present, the description carries the full behavioral burden and discloses almost nothing: not whether results are paginated by default, how many tasks are returned, or the ordering. The only behavioral signal is the implicit read-only nature of 'get', which the agent must infer.

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 short sentence, front-loaded and free of waste. It is concise rather than bloated, though the brevity comes at the cost of detail captured in other dimensions.

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 output schema exists, so return values need not be explained, and the schema fully documents parameters. Still, for a 6-parameter, host-scoped listing tool with several close siblings, the definition omits scope, relation to alternatives, and pagination behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter (limit, offset, date_from, date_to, host_id, user_id) is already documented in the schema with formats and defaults. The description adds no extra meaning, 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 clear verb ('get') and resource ('list of recrawl tasks'), so the basic intent is legible. However, it does not distinguish this tool from nearby siblings such as get_recrawl_task_status, get_recrawl_quota, or request_recrawl, nor does it indicate that results are scoped to a single host/user despite the required host_id and user_id.

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 call this versus get_recrawl_task_status (single task) or get_recrawl_quota. No prerequisites, no mention that user_id/host_id are required to scope the listing, and 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?

No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing beyond the operation's name. It does not say whether the call is read-only, what task states are returned, how a missing/expired task_id is handled, or whether the task must belong to the given user_id. For a status-polling tool this is a real gap, though the output schema partially compensates on the return side.

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 short sentence with the verb and resource front-loaded and zero filler. It is efficient, though so terse that it forgoes any structure that could carry additional context.

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 existence of an output schema means return values need not be explained, and all three parameters are documented in the schema. However, with no annotations and no behavioral detail, the definition is only minimally viable for an agent that must know when to poll this tool and what task lifecycle states to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with host_id, task_id, and user_id each documented in the schema (including the host_id format string). The description adds no syntax, format, or relationship detail 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?

The description states a specific verb ('Get') and resource ('status of a specific recrawl task'), which is enough to distinguish it from the read-only siblings at a glance. The word 'specific' hints at the singular counterpart to get_recrawl_tasks, but the sibling is never named, so the differentiation is implicit rather than explicit.

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 indication of where task_id comes from (request_recrawl or get_recrawl_tasks), and no exclusions or prerequisites. The agent must infer the entire usage context from the name alone.

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, and it says nothing about permissions, scoping (user/host), result shape, or pagination. For a history endpoint with required user_id/host_id context, that leaves meaningful gaps unaddressed.

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 waste. It is arguably too terse for the routing ambiguity in this sibling cluster, but nothing is padded.

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 output schema exists, so return values need not be explained, and parameters are fully covered by the schema. What is missing is sibling routing against three similarly named search-URL tools and any behavioral notes, leaving the definition minimally adequate.

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 all four parameters (user_id, host_id, date_from, date_to) are already documented with formats. The description adds nothing beyond implying a date-bounded history query; baseline 3 applies since the schema does the heavy lifting.

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 ('Get history') and a specific resource ('pages appearing/disappearing from Yandex search'), which distinguishes it from the adjacent but vague sibling get_search_urls_history. It stops short of naming that sibling or clarifying the 'events' framing, 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?

No guidance on when to use this versus get_search_urls_history, get_search_urls_samples, or get_search_urls_events_samples. The agent must infer the distinction from the name alone.

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 implies a read/sampling operation but says nothing about permissions, rate limits, whether results are truncated, or how 'samples' are selected. Only the events concept adds behavioral context.

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 efficient sentence with the key concept front-loaded and no filler. It is arguably too terse given the tool's complexity, but there is no wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists and all parameters are documented, so return values and inputs are covered elsewhere. However, with no annotations and no usage guidance, the description leaves the agent without routing or safety context for a tool with three similar 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% and all four parameters (limit, offset, host_id, user_id) are documented in the schema. The description adds no additional parameter meaning, 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 gives a specific verb (Get) and resource (samples of pages that recently appeared or disappeared from Yandex search), clarifying that 'events' means appearance/disappearance. It is clear on its own but never distinguishes itself from near-identical siblings like get_search_urls_samples or get_search_urls_events_history.

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 when-to-use, when-not-to-use, or named alternative, despite several overlapping siblings (get_search_urls_samples, get_search_urls_events_history). The reader must infer the scenario from 'recently appeared or disappeared' alone.

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 load. The 'get' verb implies a read-only operation and the output schema covers the return shape, but the description discloses nothing about permissions (e.g. user_id ownership), rate limits, or how much history is retained. Some value, but significant gaps remain for a no-annotation 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 efficient sentence with no filler, and the core resource is front-loaded. The phrasing 'pages count in Yandex search results' is slightly awkward but does not waste space.

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?

Parameters are fully documented in the schema and an output schema exists, so the return format is covered. The gaps are the missing usage routing against many similar siblings and the lack of any behavioral context (auth, scope), which leaves the definition under-specified for a 4-required-param 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 100%, so the schema already documents all four parameters (date format, host_id format, user_id). The description adds no syntax or constraint detail beyond what the schema provides, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (get) and resource (history of pages count in Yandex search results) with a clear temporal framing, so the agent knows what it returns. However, it does not distinguish itself from close siblings like get_search_urls_samples, get_search_urls_events_history, or get_indexing_history, which all concern historical Yandex search data.

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 the alternative siblings that also return history data. Usage is only weakly implied by the name and the phrase 'over time'; an agent must guess which of the several history tools to pick.

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 usefully discloses a 50,000-record cap, which is real behavioral context about result volume, but it says nothing about permissions, whether data is a snapshot, or pagination behavior (which is only in the schema). The single cap is helpful but not sufficient for a data-retrieval 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 tight sentence that front-loads the action and resource and wastes no words. The parenthetical cap is the one piece of extra information and 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?

An output schema exists, so return values need not be described, and the cap is mentioned. But with four parameters and many overlapping siblings, the description lacks the context needed to decide when this tool is the right one and what guarantees the samples carry.

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 all four parameters (limit, offset, host_id, user_id) are already documented in the schema itself. The description adds no additional parameter meaning, 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 (get) and resource (samples of pages in Yandex search results), which is clear on its own. However, it offers no differentiation from close siblings like get_search_urls_history, get_search_urls_events_samples, or get_indexing_samples, leaving the agent to guess which sampling tool is appropriate.

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 the many sibling tools, no mention of prerequisites such as host verification, and no indication of the time window or state the samples reflect. Usage must be inferred entirely from the 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It says nothing about whether this is a read-only operation, what the return format looks like, pagination, rate limits, or permissions needed to access the history. For a data-retrieval tool with zero annotation coverage, this is a significant 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 compact sentence with no wasted words. It is front-loaded with the purpose and appends the prerequisite in a parenthetical. Efficient, though it could be slightly richer in guidance without becoming bloated.

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 7 parameters (5 required) and an output schema exists, so return values need not be explained. However, with no annotations and no usage context beyond the query_id source, the description is adequate but leaves the agent without behavioral or eligibility guidance for a moderately complex 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 100%, so all 7 parameters are fully documented in the schema itself. The description mentions only that query_id comes from get_popular_queries, adding marginal value over the schema's own description ('Query ID from get_popular_queries response'). Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Get') and resource ('search statistics history for a specific query'), clearly distinguishing it from the broader get_query_history sibling. It also points to get_popular_queries for obtaining the query_id, adding context that aids selection.

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?

Implies usage: retrieve history for one query obtained from get_popular_queries. References a prerequisite tool, which is good guidance, but does not explicitly state when to use this versus get_query_history or get_query_analytics.

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 never says this is a read-only lookup, what authentication/permission scope the required user_id and host_id imply, or what happens if the sitemap_id does not correspond to an auto-detected sitemap. Only an output schema exists to cover return values.

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 waste. Its brevity is appropriate given the 100%-covered schema, though the one-line form leaves no room for the disambiguating context the sibling set demands.

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 100% schema coverage, an output schema present, and no nested objects, the description is minimally sufficient to invoke the tool. However, for a tool in a crowded sitemap sibling cluster with zero annotations, it omits the routing and safety context an agent would benefit from.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with all three required params (user_id, host_id, sitemap_id) documented in the schema itself, including host_id's format. 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 ('get') and resource ('sitemap'), and the qualifier 'auto-detected' distinguishes it from the sibling get_user_added_sitemap_info without naming it. Clear, though it never explicitly routes the agent between sitemap-reading siblings.

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 by the phrase 'auto-detected sitemap', which hints at the contrast with user-added sitemap tools. There is no statement of when to prefer this over get_user_added_sitemap_info or get_sitemaps, and no prerequisites mentioned.

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. 'Auto-detected' hints that results are system-discovered rather than user-submitted, but nothing is said about pagination limits, permissions, or result ordering, all of which matter for a listing 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 compact sentence with no filler. It is efficient, though its extreme brevity leaves little room for the routing or behavioral context a caller needs.

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 output schema exists so return values need not be explained, but with no annotations and a listing tool requiring two scoping identifiers, the description is too thin to tell an agent when and how 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?

Schema coverage is 100%, so all five parameters (including the cursor-based offset_id and parent_id for index sitemaps) are already documented in the schema. The description adds no parameter meaning beyond that, which lands at the baseline.

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 (Get) and resource (sitemaps) with the scope qualifier 'auto-detected', which implicitly distinguishes it from user-added sitemaps. It does not name the sibling tools that would complete the disambiguation, but the resource 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?

No guidance on when this should be called versus get_user_added_sitemaps, get_sitemap_info, or get_user_added_sitemap_info. There are also no stated prerequisites, even though user_id and host_id are required.

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, yet it says nothing about required credentials, whether the call is a safe read, pagination, or default date behavior. The one useful hint is 'over time', implying a time-series read, but that is thin for a 4-param tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with no filler and the core concept front-loaded. It is efficient, though it is arguably too terse to be maximally useful given the metadata gap.

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 output schema exists, so return-value explanation is not needed, and the schema fully documents inputs. However, with no annotations and no usage context, the definition is only minimally complete for distinguishing this history tool from its numerous 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%, so each of the four parameters (date_to, date_from, host_id, user_id) is already documented in the schema, including formats and defaults. The description adds no parameter-level detail, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Get) and resource (Site Quality Index history), and expands the SQI/ИКС acronym, which helps an agent identify the exact metric. It is clear but does not differentiate from the many sibling *_history tools beyond naming the resource.

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 offers no when-to-use guidance, no prerequisites (e.g. that user_id/host_id are required), and no comparison to alternatives like get_indexing_history or get_search_urls_history. Usage must be inferred entirely from the 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?

No annotations are provided, so the description carries the behavioral burden alone. 'Get' implies a read-only operation, which is a reasonable inference, but the description doesn't state auth requirements, whether the two IDs need to belong to the same user, or any rate limits. It is adequate but not rich.

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 names the operation and lists exactly what it returns. No waste, no ambiguity, 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?

With an output schema present, the description need not explain return values, and it appropriately enumerates the summary metrics it will produce. Annotations being absent means some behavioral context (read-only nature, prerequisites) is missing, but annotations are not required for this kind of safe read tool, and the description is otherwise complete for calling 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% and both parameters (host_id, user_id) are fully documented, including host_id format. The description adds no parameter-level detail beyond what the schema already provides, 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 states a clear verb+resource ('Get site summary') and enumerates the three summary metrics returned (SQI, indexed pages count, site problems count). It distinguishes itself from siblings like get_host_info or get_sqi_history by the aggregate nature of 'summary'. However, it doesn't explicitly say how it differs from those similarly-named metric tools, keeping it 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?

There is no explicit when-to-use or when-not-to-use guidance. Given many siblings that return overlapping metrics (get_host_info, get_sqi_history, get_diagnostics), no instruction is provided to help an agent choose this aggregate summary over those. Usage is only 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 full behavioral burden, yet it discloses nothing beyond the bare read action. It does not mention whether a user_id/host_id must already be verified, whether the sitemap must be user-added versus system-discovered, or any error behavior for a missing sitemap_id.

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 or repetition. It is appropriately sized, though it is so terse that there is no room for the routing detail 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?

An output schema exists, so return values need not be explained, and the schema fully documents the required parameters. The remaining gap is the lack of differentiation from get_sitemap_info, which matters given how many sitemap siblings exist.

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%, including the host_id format hint, so the schema already documents all three parameters. The description adds no syntax or format detail beyond what the schema provides, which is the baseline 3 case.

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 (Get) and resource (details of a user-added sitemap), so the agent knows it retrieves a single sitemap's details. However, it does not distinguish itself from the close siblings get_sitemap_info and get_user_added_sitemaps, leaving the agent to infer the boundary from the name alone.

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 when-to-use guidance, no conditions, and no mention of alternatives such as get_sitemap_info or get_user_added_sitemaps. The agent must guess which sitemap retrieval tool applies to its situation.

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, yet it only hints that this is a read via the verb "Get". It says nothing about pagination behavior, result ordering, or whether the returned sitemaps are filtered in any way.

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?

It is a single short sentence with no waste, but the brevity comes at the cost of under-specification rather than efficiency. Front-loading is fine; there is simply nothing to front-load.

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 output schema exists, so return values need not be explained, and parameters are fully documented in the schema. However, given the number of similarly named sibling tools, the absence of any disambiguating or usage context leaves a real gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with limit, offset, host_id, and user_id all documented in the schema (including format hints for host_id). The description adds no parameter meaning beyond the schema, 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 restates the tool title and name with no additional specificity. It does not clarify how "user-added sitemaps" differs from the sibling get_sitemaps or get_user_added_sitemap_info, so an agent cannot distinguish it without opening the schemas.

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 indication of when to use this tool versus the closely named siblings get_sitemaps and get_user_added_sitemap_info, nor any mention of prerequisites or context. The agent must infer usage entirely.

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 discloses that the result is scoped to the authenticated user (auth is required), which is useful, but says nothing about token requirements, error behavior, or whether the ID is cached/stable. For a trivial no-arg getter this is adequate but thin.

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 short sentence with the essential noun phrase front-loaded and zero filler. Nothing can be trimmed without losing meaning.

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 output schema exists, so the description needn't explain return values, and with no parameters and no nested objects the call surface is fully covered. Only the absence of any auth/permission note keeps it from being 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 tool takes zero parameters, so the baseline of 4 applies. There is no parameter surface for the description to compensate for.

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?

Specific verb ('Get') plus resource ('authenticated Yandex Webmaster user ID'), naming the service and the exact entity returned. It is clearly distinct from the host/sitemap/query-oriented siblings, though it does not explicitly name any sibling it contrasts with.

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 on when to call this versus alternatives, nor any prerequisites beyond the implied 'authenticated'. Usage is only inferable from the phrase 'authenticated ... user ID'.

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 only an implicit read (via 'Get') and says nothing about permission requirements, whether the host must already exist, or what verification states can be returned — a notable gap for a tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short, front-loaded sentence with no filler or redundancy. It is efficient, though the brevity borders on under-specification rather than tightness.

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 output schema exists and schema coverage is complete, so return values and parameters need not be re-explained. What is missing is the relationship to verify_host and any hint about verification states, leaving the definition minimally adequate for a simple getter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both required parameters (host_id with format hint, user_id) are fully documented in the schema. The description adds no parameter meaning of its own, 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 states a verb and resource ('Get site verification status'), but it is essentially the tool name with 'site' inserted and adds no detail about what 'verification status' means (e.g., which verification method). It also fails to distinguish itself from the sibling verify_host, so an agent cannot tell the read-check apart from the action tool from the text alone.

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 call this versus verify_host, add_host, or get_host_info, and no stated prerequisites (e.g., host must be added first). The agent must infer usage entirely from the 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 provided, the description carries the full behavioral burden and falls short: it does not say whether the recrawl is queued asynchronously, whether quota is consumed, whether the call fails when quota is exhausted, or what permissions user_id/host_id imply. 'Submit' signals a mutation, but nothing about reversibility or side effects 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?

A single front-loaded sentence with zero filler, which is structurally clean. It is arguably too terse for a 3-parameter mutation tool, which slightly undercuts its effectiveness.

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 output schema exists, so return values need no explanation, but for an unannotated action tool the description should cover quota consumption and asynchronous processing. It omits both, and leaves the relationship to the recrawl-quota/tasks/status siblings entirely 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%: url, host_id (with format hint), and user_id are all documented in the schema itself. The description adds only the word 'URL' and no format, batching, or constraint detail, 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 (submit) and resource (URL for recrawl/reindexing) with the target service named (Yandex), so the action is unambiguous. It does not, however, differentiate itself from the related siblings get_recrawl_quota, get_recrawl_tasks, or get_recrawl_task_status, which an agent must distinguish between.

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 when-to-use guidance, no prerequisites, and no exclusions. The existence of get_recrawl_quota strongly implies a quota constraint that the description never mentions, and it never says to check get_recrawl_task_status afterward for the result.

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 burden of behavioral disclosure, but it only states the action. It omits permissions required, side effects, idempotency, and what 'starting' verification actually does (e.g., sends requests, creates a task).

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 single sentence is too terse and does not front-load useful information; it is under-specified rather than concise. The sentence does not earn its place because it repeats the name without adding value.

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 mutation tool with no annotations and a rich output schema, the description is incomplete. It fails to explain when to use it, what it requires, or how it fits with the verification-status sibling, leaving significant 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%, so the schema already documents all three parameters. The description adds no parameter semantics, leaving the baseline of 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Start site verification process' essentially restates the tool name (verify_host) without adding specific detail about what verification entails. It gives a verb and a resource, but the purpose remains vague and does not distinguish it from siblings like get_verification_status.

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 on when to use this tool versus alternatives is provided. The description does not mention prerequisites, context, or the existence of a status-checking sibling.

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