yandex-mcp

by zai-one

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.0
Disambiguation3/5
Most tools map to distinct resource-action pairs, and product prefixes help separate Wordstat, SERP, Direct, Metrika, and Webmaster. However, several read/report tools overlap in function (metrika_report vs metrika_get_statistics, direct_get_campaign vs direct_get_inventory, webmaster_get_sitemap vs list_sitemaps vs list_user_sitemaps), requiring careful description reading to avoid misselection.
Naming Consistency4/5
Tool names are mostly consistent within each product area, following a service-specific prefix plus verb_noun pattern (e.g., direct_list_campaigns, metrika_list_counters, webmaster_get_diagnostics). Some deviations exist, such as yandex_wordstat_regions and yandex_wordstat_dynamics lacking a verb, so the pattern is not perfectly uniform.
Tool Count2/5
With 48 tools, the server is heavily overloaded for a single MCP surface, far exceeding the typical 3-15 well-scoped range. Although the tools are grouped by Yandex product, the sheer number of near-repetitive Webmaster read endpoints makes the set feel bloated and harder for an agent to navigate efficiently.
Completeness4/5
The tool set covers the major Yandex product areas comprehensively: Wordstat research, SERP async workflow, Direct campaign management and writes, Metrika statistics/goals, and extensive Webmaster read/reconcile/apply operations. Minor gaps exist, such as no explicit verification-start tool or no direct counter creation, but agents can accomplish core workflows with the available surface.
Average 3.2/5 across 48 of 48 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- Last stable release on September 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description declares 'read-only' and 'bounded', which gives some safety and limit information, but it is minimal. With no annotations provided, the description carries the full burden of disclosure. It fails to mention what happens on errors, whether authentication is required, what rate limits apply, or what the response structure looks like. The term 'bounded' is ambiguous—it could mean limited result size, request throttling, or something else.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, which is technically concise, but it is under-specified rather than efficiently informative. It fails to convey essential usage details, so the brevity works against usefulness. A concise description would include the key elements of what the tool does and how to use it; this omits nearly all of them.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a reporting tool with an open 'params' object and an output schema (which suggests a rich response), the description is grossly incomplete. An agent would not know what to put in the params, what the response contains, or what 'bounded' means in practice. The tool is not callable correctly based on this description alone. Even with an output schema, the input side is entirely unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single required parameter 'params' which is an open object with additionalProperties: true and no property definitions. Schema description coverage is 0%. The description adds no information about what keys this object should contain, such as counter ID, date range, metrics, or filters. An agent has zero guidance on how to construct the request body, making this parameter effectively opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the tool as a 'Metrika reporting request' with a specific verb ('run') and resource ('Metrika reporting'), which separates it from a pure tautology. However, it is vague about what 'statistics' actually means—no mention of metrics, dimensions, date ranges, or counters. It does not differentiate itself from sibling tools like metrika_list_counters or direct_get_statistics beyond the name, leaving an agent to guess the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any conditions, prerequisites, or exclusions, nor does it reference sibling tools like metrika_list_goals or direct_get_statistics. An agent has no contextual hints about the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description implies read-only ('read') and a 31-day max period, but omits side effects, permissions, pagination behavior, and error/empty results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with no filler, but the phrase 'explicit periods are at most 31 days' is slightly awkward and would benefit from clearer structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and no schema descriptions, the description leaves many functional details unexplained; output schema exists, but request semantics are under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 8 params with 0% description coverage; description does not explain host_id, limit, offset, order_by, query_indicator, device_type_indicator, or date formatting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States it reads a page of popular queries, indicating action and resource, but does not clarify how this differs from webmaster_get_query_history or define 'popular queries'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this over sibling tools; only mentions a date-range limit, not selection criteria or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It communicates that the operation is a read and that one 'page' is returned, but it does not explain pagination behavior, what the cursor represents, whether parent_id changes scope, or what the response contains. This is thin transparency for a 4-parameter API tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with no filler words. However, it is under-specified rather than usefully concise, and the jargon phrase 'upstream sitemap identifier cursor' reads as unclear rather than efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, 0% schema description coverage, no annotations, and many sitemap-related siblings, the description is not complete enough. The output schema may cover return values, but the description still omits the required host_id, pagination usage, parent_id semantics, and selection criteria among sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented parameters. It adds a partial clue about 'cursor' (an upstream sitemap identifier), but it says nothing about the required host_id, the semantics of limit, or the role of parent_id. It does not provide enough parameter context for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a verb ('Read') and a resource ('sitemap page'), so it is not a tautology. But 'one sitemap page' and 'upstream sitemap identifier cursor' are ambiguous: it is unclear whether this lists paginated sitemaps for a host or reads a single sitemap entry, and it does not distinguish itself from sibling tools like webmaster_get_sitemap or webmaster_list_user_sitemaps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to choose this tool versus sibling sitemap tools, nor any statement about required host_id or how pagination should be driven. The phrase 'using the upstream sitemap identifier cursor' implies a prior step, but no usage context or alternative is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. It hints that the result is a sitemap registration pending human approval, but it does not explain side effects, reversibility, required permissions, idempotency, or what happens after preparation. This is a significant gap for a mutating/staging tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, and the action is front-loaded. However, the awkward phrase 'expiring human approval' hurts clarity and could have been worded better.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two required parameters, no annotations, and an output schema, but the description is too terse to orient an agent. It fails to explain the prepare/apply workflow, prerequisites, or what 'human approval' means operationally, leaving the agent to guess whether this tool or apply_sitemap should be called.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the tool description does not explain 'host_id' or 'url'. The parameter names are somewhat self-explanatory, but nothing clarifies expected formats, where host_id comes from, or whether url must be a full sitemap URL.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('prepare') and resource ('sitemap registration'), so the core purpose is discernible. However, the phrase 'for expiring human approval' is ambiguous and likely contains a typo, and the description does not distinguish this tool from the sibling webmaster_apply_sitemap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives. The mention of 'human approval' implies a staging step, but it never says to use apply_sitemap for the actual submission or explains the prepare/apply split.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does usefully disclose that the tool cannot send a POST, implying a read-only or reconciliation behavior. However, it does not explain what reconciliation does to state, what the output contains beyond the schema, or what happens when the existing action does not match.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief at two sentences and wastes no words. The key read/reconcile purpose is front-loaded, and the POST limitation is stated directly. The main downside is that brevity comes at the cost of semantic clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 documentation is not strictly needed, but the description leaves significant gaps: all four required parameters are semantically undocumented, the meaning of 'reconcile' is unexplained, and there is no guidance on how this tool fits into the prepare/apply workflow shown by sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter-level meaning. The role of idempotency_key, the difference between the 'recrawl' and 'sitemap' enum values, and how host_id and url relate to 'this principal's existing action' are all left undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb ('Read and reconcile') and a resource ('this principal's existing action'), but 'reconcile' is jargon that is never defined, and the description does not distinguish this from sibling read-oriented tools like webmaster_get_recrawl_task or webmaster_get_sitemap. It is clear that this is not a POST action, but the core purpose remains somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is the negative constraint 'This tool cannot send a POST,' which tells the agent what the tool cannot do but not when to use it versus alternatives. It does not mention that preparation tools like webmaster_prepare_recrawl or apply tools like webmaster_apply_recrawl should be used for creating or sending actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It does state this is a read operation and reveals the non-error queue status behavior when results are not ready. However, it omits other behavioral traits such as permissions, rate limits, and when the offline path is triggered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence with the core action front-loaded. It avoids padding, though the phrase 'safe offline queue status' is slightly awkward and less clear than the rest.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five parameters, no annotations, and a likely asynchronous result flow, the description is too thin to support correct invocation. It omits the required date range, report type, campaign filtering, and polling behavior, leaving those details to the schema and agent inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to date_from, date_to, field_names, report_type, or campaign_ids. The agent must rely entirely on the schema for parameter semantics, as the description does not compensate for its low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Read campaign statistics', and clarifies the two possible result forms: completed TSV rows or offline queue status. This is clear but does not explicitly differentiate it from sibling tools like direct_get_campaign or metrika_get_statistics by naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool instead of alternatives such as direct_get_inventory or metrika_get_statistics. The mention of queue status vaguely implies an asynchronous workflow, but the conditions for choosing this tool or waiting for results are left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It does disclose that this is a read-only allowlisted operation, which is useful and prevents misuse as a write tool. However, it does not explain what 'strict read allowlist' means operationally, whether authentication is required, or any limitations around the listing behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant wording. It conveys the core purpose efficiently. It loses a point because the phrase 'strict read allowlist' is somewhat opaque and does not earn its place as clearly as a more explicit behavioral note would.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return-value documentation may be handled elsewhere, and there is only one optional parameter. Nevertheless, the description is incomplete for an agent: it fails to explain selection_criteria, does not route the agent to sibling tools when appropriate, and provides only minimal context about the 'strict read allowlist' mechanism.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the selection_criteria parameter at all. The parameter is optional and accepts an object or null, but the description provides no meaning for how selection criteria affect the returned campaigns. This leaves the agent without any guidance for constructing a valid request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'List Direct campaigns'. It is straightforward and distinguishes itself from direct_get_campaign by indicating a plural listing operation rather than a single-campaign fetch. However, it does not explicitly contrast itself with sibling tools like direct_get_campaign or direct_get_statistics, so it falls just short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as direct_get_campaign, direct_get_inventory, or direct_write. It only hints at a read-only context through 'strict read allowlist', but does not state exclusions or selection criteria for choosing this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure burden. It offers only two hints: UTC dates are required and some 'server budget gate' exists, but it never explains what the budget gate does, whether the operation is read-only, or any consequences of hitting the gate. This is insufficient for a tool with no other behavioral metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. It front-loads the core action ('Get Wordstat demand over time') and adds date details, but the undefined 'server budget gate' is a minor structural flaw that could confuse rather than inform.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, three required ones, and no annotations, this description is incomplete. It omits any mention of the required phrase parameter, the meaning of period, filtering options (devices, regions), or the behavior of the budget gate. Even though an output schema exists, the agent still lacks enough context to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate by explaining the parameters. It only illuminates the date format (UTC, YYYY-MM-DD) for from_date/to_date, while phrase, period, devices, and regions remain unexplained. The description adds minimal semantic value beyond the schema's raw field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource – 'Get Wordstat demand over time' – which clearly distinguishes this from sibling tools like yandex_wordstat_get_top or yandex_wordstat_regions by emphasizing the temporal dimension. However, the phrase 'server budget gate' is cryptic and slightly muddies the otherwise clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention the sibling wordstat tools or any conditions that would select this one, leaving the agent to infer usage solely from the name and the phrase 'over time'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It mentions 'through the server budget gate,' hinting at some budget-controlled execution, but does not explain what that means, whether the operation is read-only, what limits apply, or what side effects may occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently communicates the core action even though it omits important operational details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and only a one-sentence description, the agent lacks critical context: what 'server budget gate' means, how region values are specified, how devices affect results, and how this tool relates to sibling Wordstat tools. The output schema exists but does not compensate for missing invocation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. Parameters like phrase, region, and devices are only named; their accepted values, formats, and semantics are unexplained. The phrase 'by region' gives a weak hint about the region parameter but nothing more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and scope: 'Get Wordstat demand by region' with a 30-day window. This makes it distinguishable from related tools like yandex_wordstat_get_top and yandex_wordstat_dynamics, though it does not explicitly differentiate itself from yandex_wordstat_regions_tree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as yandex_wordstat_get_top, yandex_wordstat_dynamics, or yandex_wordstat_regions_tree. The regional focus implies the use case, but there is no explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 indicates the operation is a 'get' (implying read-only), but it does not disclose auth requirements, rate limits, whether responses are raw provider payloads, or whether any allowlisting violations will cause failures. The description adds minimal context beyond the tool name and action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler. It front-loads the core action and scope and does not repeat information already present in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-level tool with two generic parameters and zero annotation coverage, the description is under-specified. It does not explain the inventory allowlist, how to select the service, what params to pass, or what behavioral constraints apply. The presence of an output schema helps but does not make this contextually complete for an agent deciding to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the only parameters are generic 'service' and 'params'. The description suggests a provider-native passthrough but gives no indication of what values 'service' should take, how 'params' should be structured, or which Direct inventory operations are allowed. It does not compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Run') and a clear target ('provider-native get against the explicit Direct inventory allowlist'), which distinguishes it as a low-level passthrough read rather than a wrapper like direct_get_campaign. However, 'inventory allowlist' is not defined, so the exact resource remains somewhat ambiguous without external context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to choose this tool over siblings such as direct_get_campaign, direct_get_statistics, or direct_write. The phrase 'explicit Direct inventory allowlist' implies a constrained scope, but it does not explain the conditions under which an agent should use this raw get instead of higher-level alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It only indicates a read operation and a page boundary; it does not mention authentication, rate limits, ordering, or whether 'samples' implies a non-exhaustive or random subset.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word earns its place, and the key action and resource appear immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool is simple and has an output schema, the description lacks enough behavioral and routing context for an agent to choose it confidently among many webmaster siblings. Adding host scoping and pagination details would materially improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate. 'One page' loosely hints at limit/offset semantics, but it does not explain host_id or clarify how limit and offset interact, leaving the agent to infer everything from parameter names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and a specific resource ('external link samples'), and the phrase 'one page' suggests a paginated listing. It is distinguishable from siblings like webmaster_get_external_links_history, though 'samples' is somewhat ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool over alternatives such as webmaster_list_broken_links or webmaster_get_external_links_history. The 'one page' wording implies pagination, but no use cases, exclusions, or alternate tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose that no live provider call is made, but it does not explain what 'prepare' actually does, whether it creates persistent state, whether it is idempotent, what side effects occur, or what permissions are required. This is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise, front-loaded sentence with no filler. Every word contributes to the core meaning, and the key qualifier 'without a live provider call' is included. It is efficient, though perhaps too sparse to support the other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 0% parameter coverage, absence of annotations, and a clear sibling workflow around submit/status/get_result, the description is incomplete. It does not explain the relationship to yandex_serp_submit, what to do with the prepared request, or how the parameters should be populated. The existence of an output schema does not fill these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the three parameters: query, region, or response_format. The defaults '225' and 'FORMAT_XML' are left unexplained, and the description does not compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Prepare', with a clear resource, 'an asynchronous Yandex SERP request', and adds the scoping qualifier 'without a live provider call'. This clearly distinguishes it from a live execution call, though it does not explicitly name sibling tools such as yandex_serp_submit or yandex_serp_get_result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without a live provider call' implies this is a staging or pre-submission step in an asynchronous workflow, but no explicit guidance is given about when to use this tool versus yandex_serp_submit, yandex_serp_status, or yandex_serp_get_result. Usage context 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.
Behavior2/5
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 only states the high-level operation and does not disclose whether the operation is read-only, what 'presence' means, how device aggregation works, whether forecasts are historical or future, or any rate/auth constraints. 'Forecast' hints at a non-mutating operation but that is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the verb and object. It is appropriately compact, though adding routing or behavioral context would improve it without much bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The input schema covers the required parameters and an output schema exists, so return-value details are not strictly needed. However, the description does not clarify the meaning of 'presence', the forecast horizon, or the device dimensions, leaving noticeable operational gaps for an agent that must invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description maps the two required parameters to 'phrases and regions' and adds 'by device' as an output dimension, which gives them some semantic role. However, with schema description coverage at 0%, it does not compensate further: no explanation of region ID format, phrase count limits, or how phrases and regions interact is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Forecast') and resource ('search-volume presence') and identifies the key dimensions ('by device', 'for phrases and regions'). It is reasonably distinguishable from the recrawl/sitemap tools, though it does not explicitly differentiate from forecasting or statistics siblings like yandex_wordstat_dynamics or direct_get_statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. Given the large sibling set including wordstat, statistics, inventory, and forecast-adjacent tools, the description leaves the agent to infer when 'direct_keyword_forecast' is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses idempotent behavior ('Uncertain POSTs are reconciled without retransmission') and the submit-once semantics, but it does not mention side effects, error behavior, quota implications, or required authentication/authorization beyond what might be implied by host_id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, using two short sentences to convey the core action and idempotency guarantee. No unnecessary words are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits critical context such as the need to call prepare_recrawl first, the meaning of approval_id, the role of reconcile_action, quota constraints, and what the response contains. It is too sparse to fully guide an agent through the recrawl application flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters (url, host_id, approval_id, idempotency_key) are left completely undocumented in the description. The description does not compensate for the 0% schema coverage; for example, it never explains what approval_id is or how idempotency_key should be generated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Submit one accepted URL exactly once') and highlights idempotency, which distinguishes it from related tools like prepare_recrawl or get_recrawl_task. However, 'accepted' is somewhat ambiguous without knowing the preceding approval step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus siblings such as webmaster_prepare_recrawl, webmaster_apply_sitemap, or webmaster_reconcile_action. The idempotency note hints at handling retries but does not clarify the overall workflow or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. The word 'Read' implies a non-mutating operation, but the description does not explain page semantics beyond 'one page', sampling behavior, or whether any quota or authorization constraints apply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or repetition. It is appropriately concise, though it sacrifices useful guidance for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple paginated read tool with an output schema and defaulted parameters, the one-line description plus schema gets an agent reasonably close to correct invocation. However, it is only minimally viable because it lacks parameter semantics and any routing guidance versus related broken-link tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description names no parameters. It does not explain that host_id identifies the site, or that limit and offset control page size and position. The phrase 'one page' only weakly implies pagination and does not compensate for the complete lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and a specific resource ('broken internal link samples'), and adds 'one page' to signal pagination. This clearly distinguishes it from sibling tools like webmaster_get_broken_links_history or webmaster_list_external_links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that history is available via webmaster_get_broken_links_history, nor does it state conditions like verified host or site ownership requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The mention of 'continuation metadata' implies pagination behavior, which is a useful behavioral trait. However, it does not explicitly state that the operation is read-only or describe any other side effects, though the 'read' verb and context suggest it is safe.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is well-structured and easy to parse, providing the core purpose without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple paginated list operation, the description covers the essential behavior (pagination) but omits context such as what the samples represent or any relationship to other webmaster tools. Since an output schema exists, not detailing return values is acceptable, but the description could still be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has three parameters (host_id, limit, offset) with no descriptions. The description does not explain what these parameters mean or how they relate to the pagination mentioned. Since schema coverage is 0%, the description fails to compensate, leaving parameter usage unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Read') and resource ('indexing samples'), distinguishing it from other list tools like 'webmaster_get_indexing_history'. However, it does not elaborate on what exactly constitutes an 'indexing sample', which could leave some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., other webmaster list tools). It only mentions pagination, but does not indicate typical use cases or conditions for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does reveal a key constraint—the 31-day limit—and indicates a read operation. However, it does not clarify what happens when the requested range exceeds 31 days (truncation vs. error), nor mention authentication or rate-limit considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence with no filler. It front-loads the verb and resource, and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description is too sparse to make the tool fully invokable without guessing. It lacks parameter explanations, usage context, and edge-case behavior for the 31-day limit. For a tool with three required parameters and zero schema descriptions, this leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies the date range concept via '31 days', but does not explain host_id, date_from, or date_to formats or semantics. The description adds minimal meaning beyond the bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read') and a specific resource ('broken internal link history'), plus a scope constraint ('at most 31 days'). This distinguishes it from sibling tools like webmaster_list_broken_links (likely current broken links) and webmaster_get_external_links_history (external link history), though it does not explicitly name these alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as webmaster_list_broken_links or other history tools. The agent must infer usage solely from the tool name and sibling context, with no explicit conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does add one meaningful constraint: at most 31 days of history. However, it does not explain date inclusivity, timezone handling, data granularity, rate limits, or any other behavioral context beyond being a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence with no filler. The core behavior and the 31-day cap are front-loaded, so an agent can quickly grasp the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three required parameters, zero schema coverage, and no usage guidance, the description is too minimal for an agent to reliably construct a valid request. The output schema covers return shape, but input semantics and selection context are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not define host_id, date_from, or date_to meanings, formats, or relationships. The phrase 'at most 31 days' hints at date-range semantics but does not map to the actual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Read') and resource ('indexing history'), with the additional constraint of 'at most 31 days'. It distinguishes from sibling history tools like webmaster_get_query_history by naming a distinct resource, though it does not explicitly call out alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings such as webmaster_get_query_history, webmaster_get_search_urls_history, or other read/history tools. The 31-day cap hints at a potential use case but does not provide selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'read' implies a non-mutating operation, but there are no annotations and no further detail about side effects, permissions, or error behavior. The description is minimal and does not fully disclose what happens when the sitemap is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and free of unnecessary wording. It efficiently states the core action and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists, the description omits important contextual details such as parameter semantics, how user_added affects the lookup, and when to choose this tool over related sitemap tools. This makes the tool underspecified for reliable autonomous selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema exposes host_id, sitemap_id, and user_added, but the description does not explain any of them. In particular, the meaning of user_added and its relationship to 'detected' vs 'submitted' is left entirely to the agent to infer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a read operation for a single sitemap's details or registration, using a specific verb and resource. It is distinguishable from list-oriented sibling tools like webmaster_list_sitemaps, though 'detected' vs 'submitted' could be clearer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus sibling sitemap tools. It does not mention that this tool is for a single sitemap lookup or that list operations should be used for enumeration, leaving usage context to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does disclose that the operation is a read and that the cursor is an exclusive identifier, which is useful behavioral context. However, it does not mention ordering, cursor lifecycle, rate limits, or relationship to other sitemap operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler, and the key action is stated first. It is compact but somewhat terse, leaving room for more semantic detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a paginated read operation, the description provides a reasonable baseline with the cursor behavior and page concept. However, with no annotations and zero parameter description coverage, the absence of any mention of host_id, limit, or alternative tools leaves notable gaps for an agent selecting and invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only adds meaning for the cursor parameter by calling it an exclusive identifier. It does not explain host_id, the required parameter, or limit, leaving most parameters to be interpreted from their names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as reading a page of submitted sitemaps and mentions an exclusive identifier cursor, which conveys pagination. However, it does not distinguish itself from the sibling tool webmaster_list_sitemaps, despite the different 'user' scope in the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool instead of webmaster_list_sitemaps or webmaster_get_sitemap. The phrase 'one page... with cursor' implies a paginated reading use case, but no exclusions, alternatives, or conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of disclosing behavior. The verb 'Return' implies a read-only operation, and the description names the payload contents (provenance metadata and normalized SERP output). However, it does not address side effects, error behavior, retention, or whether the result is cached or generated on demand.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, and the main verb is front-loaded. It earns its place by naming both output categories. It could be slightly more informative without being bloated, but as written it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The input schema is minimal and an output schema exists, so the return structure is covered elsewhere. However, the description omits the relationship to the broader yandex_serp flow (prepare, submit, status) and does not explain how job_id is obtained or validated. For a simple getter this is workable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate, but it never mentions job_id or explains how the job_id relates to the returned data. The single parameter is self-descriptive by name, but the description adds no connection between the input and the output. This is a meaningful gap for an agent selecting parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Return raw provenance metadata and normalized Yandex SERP output.' It communicates a specific retrieval verb and the kind of data returned. It does not explicitly differentiate from yandex_serp_status, but the 'raw provenance metadata and normalized output' wording implies result retrieval rather than status checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to call this tool versus siblings like yandex_serp_submit or yandex_serp_status. There is no mention of prerequisites, such as whether a job must be completed or submitted first. The agent must infer the usage context entirely from the tool name and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds some useful behavioral context: the operation is conditional on acceptance, uses a durable idempotency key, and returns registration readback. Still, it does not disclose effects, failure behavior, or whether submission is replaceable/reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, the phrase 'durable key and registration readback' is dense and could be more transparent, slightly reducing readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, this is a 4-required-parameter state-changing operation with no annotations and no parameter documentation. The description does not explain where approval_id comes from, how host_id and url relate, or how idempotency is enforced, leaving important gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for all four required parameters. The description only hints at idempotency_key ('durable key') and loosely maps 'accepted' to approval_id, but it does not explain url, host_id, or approval_id semantics. This fails to compensate for the undocumented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Submit') and resource ('one accepted sitemap'), which clearly identifies the operation. The mention of 'durable key' and 'registration readback' helps distinguish this apply step from list/prepare siblings, though the jargon is somewhat cryptic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'accepted sitemap' implies this tool should be used after a sitemap has been prepared or approved, and 'durable key' suggests idempotent retry behavior. However, no explicit alternatives or when-not-to-use guidance is provided, and the relationship to webmaster_prepare_sitemap is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It clearly signals a read-only operation and reveals the 31-day range limit, but it does not mention date formatting, permissions, or other behavioral caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler. The core action and constraint are front-loaded and immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter read tool with an output schema, the description is minimally viable. However, it lacks enough context about date semantics and how this history differs from related history tools to be considered fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds little about the parameters. It implies date range length limits via 'at most 31 days', but host_id and the expected date format are left undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Read') and resource ('search URL count history'), and adds a concrete constraint ('at most 31 days'). It is distinguishable from sibling history tools like query or indexing history, though it does not explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings such as webmaster_get_query_history or webmaster_get_indexing_history. The 31-day limit is an operational constraint, not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries responsibility for behavioral context. It discloses a notable behavior: missing metrics remain missing, which sets expectations about response completeness. However, it does not address permissions, data availability, or any other operational traits beyond that one quirk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. The 'missing metrics remain missing' note is compact and adds meaningful behavioral information without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with an output schema, the description is minimally adequate: it identifies the operation and a notable response trait. It falls short of complete because it offers no usage context or parameter explanation, but the low complexity and presence of an output schema keep the gap from being severe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, host_id, is left entirely to the schema's minimal 'string' type. The description does not explain how host_id relates to the summary or what format/identifier is expected, and with 0% schema description coverage there is no compensatory semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Read') and resource ('indexing and site summary'), which conveys the core action. It does not explicitly name a sibling tool for differentiation, but 'summary' reasonably distinguishes it from history- and diagnostics-focused siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool over alternatives such as webmaster_get_indexing_history or webmaster_get_host. The description only establishes a read context, leaving the agent to infer appropriate selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states that the status is 'durable' and asynchronous; it does not explain polling semantics, whether the call can be repeated safely, error behavior, or how job status transitions. This is minimal disclosure for a stateless-looking read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no filler, and the core action 'Return durable status' is front-loaded. It is concise and readable, although the term 'durable' could be more concrete without costing much length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a single required string parameter and an output schema present, the description is minimally viable for a simple status query. However, it lacks lifecycle context (when the status becomes available, how this relates to prepare/submit/get_result) and leaves an agent to infer that job_id originates from the submission step.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, job_id, has no schema description (0% coverage), and the tool description does not compensate by explaining its format, origin, or relationship to yandex_serp_submit. It only implies a job identifier through the phrase 'Yandex SERP job,' which is weak semantic support.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and a precise resource ('durable status for an asynchronous Yandex SERP job'). This clearly separates it from siblings like yandex_serp_prepare/yandex_serp_submit (job creation) and yandex_serp_get_result (result retrieval) without needing to open any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to call this tool instead of related SERP tools. The asynchronous wording implies it should be used after submission, but the description does not say to call it after yandex_serp_submit or before yandex_serp_get_result, nor does it state any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden and does well: it warns about sampling even when rows appear complete, explains that differences use provider totals rather than summed partial rows, and notes that missing values stay null. It does not cover auth, rate limits, or error behavior, but discloses the most important quirks for a reporting tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three sentences, front-loads the main purpose, and each sentence adds distinct value: what it reports, how pagination/sampling behaves, and how comparisons are calculated. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema, the tool has 12 parameters, 4 required, and no schema descriptions. The description omits essential invocation details: date formats, required parameters, how comparison dates are specified, and how filters/dimensions/sort are expressed. The caveats are useful but not sufficient for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain individual parameters such as counter_id, date1/date2, compare_date1/compare_date2, metrics, dimensions, filters, sort, max_pages, or page_size. It hints at period comparison and bounded rows, but an agent would still lack concrete guidance for the 12-parameter schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Report or compare two Metrika periods') with concrete scope, including sampling, exact totals, and bounded JSON/CSV rows. It is clear enough to distinguish this from many siblings, though it does not explicitly name metrika_get_statistics as a close alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides operational caveats but no guidance on when to choose this tool over alternatives like metrika_get_statistics or metrika_list_counters. It does not state prerequisites, exclusions, or explicitly when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, and it does add meaningful context: it states the possible statuses and warns that DONE does not prove search indexing. The verb 'Read' also signals a non-mutating operation. It omits details like permissions or polling behavior, but for a simple read tool the core behavioral caveat is valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action, and the caveat about DONE earns its place. It is slightly telegraphic—'Read IN_PROGRESS/DONE/FAILED' is not a full sentence—but there is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity read tool with an output schema, the description covers the main action and an important interpretation trap. However, with no annotations, no parameter explanations, and many sibling recrawl tools, an agent still lacks guidance on how to obtain a task_id, when to poll, and how this differs from nearby tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain host_id and task_id, but it does not. It only implies that task_id refers to a recrawl task; host_id is not described at all, and there is no guidance on formats, sources, or how to obtain valid IDs. The description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Read' and names the resource through the statuses IN_PROGRESS/DONE/FAILED and the tool name 'recrawl_task'. It is clear that this tool retrieves the status of a recrawl task. It does not explicitly contrast with sibling tools, but the task-level read action is a useful scope marker.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as webmaster_list_recrawl_queue, webmaster_get_recrawl_quota, or webmaster_apply_recrawl. The DONE caveat helps interpret results but does not help an agent select this tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It usefully reveals that one page is only a sample, not the full index, which is non-obvious. It does not mention ordering, consistency, or other behavioral details, though for a read-only listing operation the main caveat is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Both the action and the caveat earn their place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters, no annotations, and a large sibling list, the description is too sparse to be fully complete. It omits what host_id refers to, how pagination parameters behave, and when to prefer this tool over related webmaster tools; the output schema does not fill those gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain host_id, limit, or offset. The phrase 'one page' weakly hints at pagination semantics, but it does not compensate for the complete lack of parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Read one page of URLs in search.' The caveat that a sample is not the full index clarifies scope, but it does not explicitly contrast any sibling tool, so differentiation is only partial.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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, and no alternative tools are named. The pagination caveat implies this tool is for reading individual pages, but an agent must infer how it fits among the many sibling webmaster tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses key behavioral traits: 'idempotent' (safe to retry) and 'readback' (returns the updated state). This goes beyond a simple action statement. However, it does not mention potential destructive effects of delete or error behavior, but given no annotations, this is reasonable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action and then adds concise qualifiers. It is appropriately sized and contains no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has five parameters and two required fields, the description omits any explanation of how to specify create versus update versus delete, what 'params' contains, or what 'idempotency_key' does. The presence of an output schema reduces the need to document return values, but the parameter semantics gap makes the description incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description names none of the five parameters (operation, counter_id, goal_id, params, idempotency_key). With no guidance on what these mean or how they relate, an agent cannot infer parameter usage from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('create, update or delete') and the resource ('Metrika goal'), and 'Autonomously' and 'idempotent' differentiate it from read-only tools like metrika_list_goals. It is unambiguous and distinguishes from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. It does not say 'use this to modify goals, not to list them' or mention any prerequisites. The phrase 'Autonomously' hints at its purpose but is not explicit enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose that the operation is a read and that history is capped at 31 days. However, it leaves important behavior unspecified, such as what happens when the requested date range exceeds 31 days, whether the limit is truncation or an error, and whether pagination applies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler. The most important operational constraint, 'at most 31 days', is front-loaded and directly useful to an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse to fully support correct invocation. It lacks guidance on date format, host_id provenance, how to handle ranges beyond 31 days, and the relationship to sibling history/list tools. The output schema helps with return values, but parameter behavior and selection context remain under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds some meaning to date_from and date_to by indicating that the range is limited to 31 days, but it says nothing about host_id, date formats, or how the date range relates to the limit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read') and a precise resource ('external link history') with an explicit boundary ('at most 31 days'). The resource term 'external link history' clearly distinguishes this from siblings like webmaster_list_external_links and webmaster_get_broken_links_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives. It does not mention that current external links are covered by webmaster_list_external_links or that broken-link history belongs to webmaster_get_broken_links_history. The word 'history' weakly implies the use case, but no explicit context or exclusion is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly says 'Read', indicating a non-destructive operation. Since no annotations are provided, this direct statement about read-only behavior is transparent. However, it does not disclose any side effects (which are unlikely) or other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that efficiently conveys the tool's purpose without redundancy or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity with 6 parameters and an output schema, the description is minimal. It lacks essential details such as date format, expected behavior for null values, default indicators, or any specifics about the response format. The tool name is not explicitly mentioned in the description, though it is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only adds a hint about '31 days' (likely a date range constraint) and 'aggregate or selected-query indicators', which partially relates to query_indicator and device_type_indicator. It does not explain the date format, the meaning of each indicator, or the role of host_id, leaving most parameters undefined beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read'), the resource (query history), and the scope ('aggregate or selected-query indicators') with a time limit of 31 days. It is specific and distinguishable from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention any conditions, prerequisites, or comparative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose that the operation queues an asynchronous request, which is useful, but it does not mention side effects, quota consumption, or what the response will contain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence with the main action front-loaded. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter tool with no parameter descriptions or annotations, the description is too sparse. It conveys the overall action but leaves critical details about prerequisites, parameter meanings, and output unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaningful information about the parameters. query is only implied by 'SERP request', while region, approval_id, idempotency_key, and response_format are not explained at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Queue', and identifies the resource as an approved asynchronous Yandex SERP request. This clearly distinguishes it from sibling tools like prepare, status, and get_result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'approved' implies that the request must have been approved before this tool is used, but it does not explicitly name prerequisites such as yandex_serp_prepare or contrast with yandex_serp_status and yandex_serp_get_result. Usage guidance is therefore implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It adds useful context by mentioning 'raw provenance' and 'normalized output,' but it does not explain what these mean, nor does it disclose constraints, rate limits, or side effects. For a read-only retrieval tool, this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler. It front-loads the core action and immediately adds the distinguishing output detail, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 may be covered, but the description lacks operational context: no parameter format guidance, no usage conditions, no clarification of 'raw provenance.' An agent would need to infer critical input details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description does not explain any parameters. 'phrase' and 'regions' are somewhat self-explanatory from their names, but the expected format of regions and the meaning of 'num_phrases' are left undefined, forcing the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific operation ('Get Yandex Wordstat top requests') and characterizes the output as 'raw provenance and normalized output.' It clearly distinguishes itself from siblings like yandex_wordstat_dynamics and yandex_wordstat_regions by focusing on top requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many alternatives. The description neither mentions exclusions nor suggests a context such as 'use when you need top query phrases for a given set of regions.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral burden. It does disclose that Cloud credentials are required and that a 'server budget gate' applies, which are useful constraints. However, it does not explain what the gate does, whether the call is read-only, or what failure behavior to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler and states the core resource up front. The phrase 'server budget gate' is jargon, but it does not make the description bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an empty input schema and an output schema present, little structural information is missing. Still, the meaning of 'server budget gate' and the relationship to yandex_wordstat_regions are unclear, leaving the definition only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty with zero parameters, so there is no parameter semantics to document. The description adds no parameter details, but none are needed; the zero-parameter baseline applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Get the Wordstat region tree', a specific verb and resource, so an agent knows what the tool returns. However, it does not distinguish this from the sibling tool yandex_wordstat_regions; 'tree' implies a hierarchy but the difference is left implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 yandex_wordstat_regions or other Wordstat tools. The mention of 'Cloud credentials and the server budget gate' hints at prerequisites but does not explain when this tool is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It clearly signals a read-only operation and lists returned attributes, but it does not explain the meaning of 'native severity', pagination, time-range scope, or any host-state prerequisites, leaving some behavior implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence that names the verb, resource, and fields with no filler. Every word contributes to the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema, the description covers the basic operation but leaves the unusual term 'native severity' undefined and does not tie the single parameter to the described resource. The sibling list helps domain context, but the description itself is a bit thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description never mentions host_id, so the only parameter is left entirely to its property name for meaning. An agent can guess that host_id identifies the target host, but the description adds no clarification about format, source, or valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and names the resource ('problems') plus the key fields returned (severity, presence state, state-change time). This distinguishes it from sibling getters like webmaster_get_summary or webmaster_get_recrawl_task, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when-to-use guidance and names no alternatives or exclusions. An agent must infer from the tool name and sibling names that this is for site diagnostics; the sentence itself provides only the operation, not selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the word 'Read' is the main behavioral signal, implying a non-mutating operation. The word 'exact' adds that lookups are exact-match, but the description does not disclose other behavioral traits such as error handling, authorization requirements, rate limits, or response behavior beyond what an output schema might already show.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the verb and resource without filler, repetition, or unnecessary detail. It is appropriately sized for a simple one-parameter read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read operation with an output schema and no nested objects, the description is nearly sufficient. It is missing explicit guidance relative to the many sibling tools, but the core information needed to call it correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only describes host_id as a string with 0% schema description coverage, so the description must compensate. The phrase 'exact Webmaster host identifier' clarifies that the parameter refers to a specific host and that matching is exact, but it does not provide a format, example, or source for the identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and a specific resource ('metadata for an exact Webmaster host identifier'), clearly indicating a single-host lookup. It does not explicitly contrast with sibling get_* tools, but the phrase 'exact host identifier' helps distinguish it from list-oriented tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as webmaster_list_hosts or other webmaster_get_* tools. There is no mention of prerequisites, like obtaining a host_id, or exclusions, so the agent must infer usage entirely from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'List' clearly implies a read-only operation, and the scope is stated as exactly one counter id. However, it does not disclose whether access rights are needed, whether all goals are returned, or whether any filtering or pagination applies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler. It front-loads the verb and resource, then adds a necessary scope constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one required parameter and an output schema. The description covers the main purpose and parameter meaning sufficiently for an agent to make a plausible call. It lacks explicit alternative routing and deeper behavioral details, but these are less critical given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning to 'counter_id'. It does this by clarifying that the parameter is a Metrika counter id and that it should be a single positive one. This meaningfully supplements the bare string type in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List') and resource ('goals') for a given 'Metrika counter id', which clearly separates it from sibling tools like metrika_list_counters or metrika_get_statistics. The qualifier 'one positive' adds scope, though 'positive' is slightly ambiguous (positive integer vs. a real/valid counter).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as metrika_apply_goal or metrika_list_counters. The context of 'list goals for one counter' implies a simple read operation, but the description does not state exclusions, prerequisites, or a recommended workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. 'Read' does convey a read-only operation, and 'daily quota' adds a temporal scope, but it does not disclose requirements like host verification or what happens if quota is unavailable. This is adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the key verb front-loaded. Every word earns its place, and there is no redundant or vague filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with an output schema present, the description covers the core operation and resource sufficiently. It could add usage guidance or host_id semantics, but the low complexity and existing output schema make the definition mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions host_id or explains that the quota is scoped to the given host. The parameter name and tool name partially compensate, but the description itself adds no parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and object: 'Read the daily quota and remaining submissions.' This clearly identifies the operation and resource, and 'quota' distinguishes it from sibling recrawl tools like webmaster_get_recrawl_task or webmaster_apply_recrawl.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, no prerequisites, and no mention that it should be checked before preparing or applying a recrawl. Any usage context is only implied by the tool name and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially covers behavior by indicating it is a read operation. However, it does not disclose potential side effects, error conditions, or any other behavioral aspects beyond the basic read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise and to the point, with no unnecessary words. It immediately states the action and resource, making it easy to grasp.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the operation, the description provides sufficient context for an agent to understand what the tool does. It does not need to elaborate on return format or filtering since these are implied by the parameter names and the nature of the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only implicitly hints at pagination via 'one page' but does not explain the meaning of limit, offset, or host_id. The parameter names are somewhat intuitive, but the description does not add explicit semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and the resource ('asynchronous recrawl requests'), and specifies that it is for one page. This effectively distinguishes it from related operations like creating or applying recrawl requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus other recrawl-related tools (e.g., webmaster_get_recrawl_task). It does not mention alternatives or specific use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It says 'Read', which implies a non-destructive operation, but it does not disclose side effects, quotas, error behavior, or any other behavioral details. The 'bounded page' hint is the only additional behavioral clue.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence. Every word contributes meaning, with no redundancy or extraneous details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple paginated list operation, the description provides enough context to perform a basic call. It lacks explicit output format or field details, but no output schema is provided and the operation is straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema lists limit and offset with defaults but no descriptions. The phrase 'one bounded page' hints at pagination semantics, which indirectly explains the parameters. However, it does not explicitly define limits, defaults, or how offset interacts with paging.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Read') and the resource ('sites accessible to the server account'), with a pagination qualifier ('one bounded page'). It is unambiguous and distinct from sibling list operations in the same domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool instead of the many sibling webmaster list tools. It does not mention alternatives or selection criteria, leaving the choice to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It usefully discloses that this is a preparation step requiring human approval and checks rather than immediate execution, but it is ambiguous whether the checks are performed by the tool or expected already, and it omits side effects or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 12-word sentence with the verb and primary constraint front-loaded. No redundant phrases or filler, and every element contributes to the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with an output schema, the description covers the overall workflow but leaves host_id unexplained and does not clearly connect this preparation step to the follow-up apply step or the quota-check sibling. The ambiguous 'after checks' also leaves a gap in the operation's contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning, but it only adds 'exactly one' for URL and says nothing about host_id or URL format. An agent would still have to infer the meaning and constraints of the required host_id from its name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('prepare'), a singular resource ('exactly one URL'), and a clear workflow position ('for human approval'), which distinguishes it from sibling tools like webmaster_apply_recrawl and webmaster_get_recrawl_task. It also names the prerequisite checks, making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the condition under which the tool should be used ('after ownership, quota and duplicate checks') and that output goes to human approval, which is clear context. It does not explicitly name alternatives or say when not to use it, but the prepare-vs-apply distinction is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 with no side effects, and the numeric id condition is stated. But it does not mention not-found behavior, auth requirements, or return value nuances. For a simple getter this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no redundant words. The key information (get one by id) is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity—one required parameter and an output schema—the description covers the essential invocation. It doesn't discuss error cases or explicit alternatives, but the presence of an output schema and simple input makes it largely complete for an agent to select and call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It confirms campaign_id is a numeric identifier, which reinforces the schema's integer type and property name, but adds no meaning beyond that. The single self-explanatory parameter keeps this adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('one Direct campaign'), and specifies the lookup key ('numeric id'). This clearly distinguishes it from sibling direct_list_campaigns (list) and other direct tools that operate on campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The singular 'one' and 'by numeric id' imply this is for fetching a specific campaign when its id is known, which distinguishes it from list operations. However, it does not explicitly name alternatives like direct_list_campaigns or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It reveals key behavior: the operation only drafts changes and opens an approval, does not apply them, requires human acceptance, and the approval expires. It also mentions the draft carries a diff hash and approval_id. It does not disclose expiration duration or any side effects beyond the draft, but the core non-applying, approval-gated nature is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. The first sentence states the action, and the second provides the essential workflow constraint. Every sentence contributes useful information and the most important fact—approval is required—is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's role and relationship to direct_apply_changes well, and output schema existence means return values need less explanation. However, the complete absence of `changes` parameter semantics leaves a major gap for an agent trying to actually construct a valid call. It is usable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the only parameter, `changes`, is an array of opaque objects with `additionalProperties: true`. The description only says 'change set' and does not explain the required structure, fields, or format of each item. Since the schema provides no guidance, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Draft a Direct change set and open an unaccepted, expiring approval.' It clearly distinguishes itself from sibling direct_apply_changes by explaining that the draft must be approved before direct_apply_changes can execute it. This gives an agent a clear sense of the tool's role in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is a prerequisite for direct_apply_changes: a human must accept the approval before applying. It names the exact sibling it pairs with, which gives strong usage context. It does not explicitly state when not to use it or list alternative prepare-style tools, so it stops short of fully explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It explicitly discloses that the operation is read-only and uses a server-side credential, covering both safety and auth model. This is meaningful for a zero-parameter 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It states the action, resource, and credential model efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter schema, presence of an output schema, and simple read-only nature, the description covers the essential context. It could add a brief note tying it to sibling Metrika tools, but this is not critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. A baseline of 4 applies because there are no parameters requiring semantic explanation beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('List') and resource ('Metrika counters'), making the operation unambiguous. It also distinguishes itself from the sibling Metrika tools such as metrika_list_goals and metrika_get_statistics by identifying counters as the target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit when-to-use guidance or compare against related tools. The phrase 'server-side read-only credential' hints at an auth context but does not explain when an agent should choose this tool over sibling Metrika tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and delivers useful behavioral facts: the call is idempotent, performs a post-write readback of affected objects, and is restricted to an allowlisted service/method set. It does not mention auth/permissions or explicit side-effect severity, but the delete/archive methods make mutability clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loads the core action; every clause adds a distinct fact (scope, allowlist, idempotency, readback, approval path). No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with no annotations, the description covers scope, allowed methods, idempotency, and the human-gate alternative, and an output schema exists for return values. However, an agent still lacks concrete service/method pairing rules and an item structure, which matters for a write API with only 0% schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description compensates partly by enumerating allowed method values, naming the object types for items, and signaling idempotency. It still leaves the exact shape of items and the allowed service values to inference, so the compensation is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('apply') and a concrete resource span ('campaigns/adgroups/ads/keywords/bids'), going well beyond the terse tool name. It also distinguishes itself from direct_apply_changes by naming it as the approval-gated alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives actionable context: this is the autonomous path, while direct_apply_changes is the approval-gated path for campaigns:update, which tells an agent when to prefer each. It stops short of a full when-not-to-use statement or broader alternative selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It explicitly discloses that the operation is read-only and has no side effect of starting verification, which is the key behavioral trait an agent needs. It does not discuss auth or rate limits, but for a simple read operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler. The read-only guarantee is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one required parameter and an output schema is available. The description plus schema gives an agent enough to call it correctly, though slightly more context about host_id provenance would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single host_id with no description and schema description coverage is 0%. The tool description does not mention host_id or explain how to obtain/format it, so it fails to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') with a concrete resource ('ownership verification state') and explicitly distinguishes the tool from verification-starting operations ('without starting verification'). This makes the tool's purpose immediately identifiable relative to sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states when to use this tool: when you need to read the ownership verification state. The phrase 'without starting verification' signals it is not for initiating verification, though it does not name a specific alternative tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It clearly signals a read-only operation ('Read') and adds meaningful context that OAuth credentials remain server-side, which reassures the agent that no token handling is exposed. It does not overpromise side effects or contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one short, front-loaded sentence that conveys the action, resource, and an important security behavior. Every word earns its place; there is no redundant or boilerplate text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, schema-bearing read tool, the description is sufficient: it names what is read and the OAuth context, and the output schema covers return values. Slightly more usage context would make it fully complete, but nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there is nothing for the description to document. Baseline 4 applies because no parameter explanation is needed; the description already identifies the implicit OAuth context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Read') and resource ('OAuth account user identifier'), making the operation unambiguous. It is distinct from sibling tools, which target recrawl, sitemaps, wordstat, direct, metrika, etc., so an agent can select it immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for obtaining the current OAuth account's user identifier whenever that value is needed, but it does not explicitly state when to use it, prerequisites, or exclusions. There is no direct sibling alternative for user lookup, so the lack of explicit routing is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that the operation is fail-closed, consumes the approval exactly once for idempotency, and performs a readback of affected campaigns to confirm the applied state. This is unusually transparent for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with the core action front-loaded and the enforcement details following. Every clause adds necessary information—preconditions, idempotency, and readback—with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a fail-closed write tool with no annotations, this description covers the critical operational context: what is required, what happens to the approval, and how the state is verified. The main gaps are the lack of explicit routing against direct_write and no explanation of the output beyond readback, though an output schema exists to cover return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter descriptions, so the description must compensate. It does: 'accepted approval' maps to approval_id, 'consumed exactly once' maps to idempotency_key, 'affected campaigns are re-read' maps to campaigns, and 'allowlisted service/method' maps to service and method. It stops short of enumerating allowed values or formats, hence not a 5, but all five parameters receive meaningful semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Execute one accepted, allowlisted Direct write (Campaigns.update) with readback.' This precisely identifies the operation, the object being changed, and the verification step, and it clearly differentiates this tool from preparation or listing siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete invocation preconditions: a runtime flag, an accepted approval whose hash matches the exact changes, and a bounded allowlisted service/method. This tells an agent when it is safe to call the tool. It does not explicitly name alternatives like direct_write or direct_prepare_changes, but the 'accepted approval' framing strongly implies this is the post-approval execution path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

yandex-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![yandex-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/zai-one/yandex-mcp/badges/card.svg)](https://glama.ai/mcp/servers/zai-one/yandex-mcp)

Score Badge

Copy to your README.md:

[![yandex-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/zai-one/yandex-mcp/badges/score.svg)](https://glama.ai/mcp/servers/zai-one/yandex-mcp)