Yandex Webmaster MCP Server

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation4/5
Most tools have distinct purposes (e.g., get_hosts lists sites, get_query_analytics aggregates time series), but get_popular_search_queries and get_search_queries overlap, with one explicitly deprecated. The descriptions clarify the distinction, so misselection is unlikely.
Naming Consistency5/5
All tools follow a consistent 'get_' prefix with descriptive nouns, except submit_url which is a clear action verb. The pattern is uniform and readable, with no mixed conventions.
Tool Count5/5
13 tools is a well-scoped size for a Yandex Webmaster server, covering diagnostics, analytics, indexing, and recrawl without being overwhelming or too sparse.
Completeness4/5
The surface covers core domain needs: diagnostics, analytics, indexing, sitemaps, and recrawl submission. Minor gaps exist (e.g., no verification or sitemap submission), but most workflows are supported. The deprecated get_search_queries slightly clutters the set.
Average 3.8/5 across 13 of 13 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds context about the data returned (monitored important URLs and their status history) but does not disclose return format, pagination, or other behaviors. With annotation coverage, this is acceptable 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, making it concise and front-loaded. However, it lacks an explicit action verb, which slightly reduces clarity despite its efficiency.
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 read-only tool with two well-documented parameters, the description provides a basic understanding of purpose but leaves gaps such as what constitutes 'important URLs' and the exact structure of status history. Given schema details and annotations, it is adequate but not comprehensive.
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 100%, with both host_id and format fully described in the schema. The tool description adds no parameter-specific information, so it relies on the schema for semantics.
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 indicates the tool returns data about monitored important URLs and their status history for a host. Although it lacks an explicit verb like 'get' or 'list', the noun phrase conveys the resource and scope, and it distinguishes from sibling tools by focusing on 'important URLs' and 'status 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?
No usage guidance is provided. The description does not state when to use this tool versus alternatives like get_sitemaps or get_indexing, nor does it mention prerequisites (e.g., that host_id should come from get_hosts). This is entirely absent.
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?
Annotations declare readOnlyHint=true, so the read-only nature is covered. The description adds useful detail about output contents (quality index, problem counts) but does not disclose behaviors like empty results for unindexed hosts or data freshness.
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, focused sentence that directly states the tool's purpose and scope with no filler or repetition. Information 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?
For a simple read tool with complete parameter descriptions, the description is adequate. It names the host scope and the key data (quality index, problem counts). It lacks details about return formatting edge cases, but the schema covers format, and the tool's simplicity reduces the need for extensive disclosure.
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 100% with clear descriptions for host_id and format. The description's 'for a host' aligns with the host_id parameter but adds no additional meaning beyond what the schema already provides.
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 it provides an indexing status summary for a host, including quality index and problem counts. It distinguishes from sibling get_indexing_history by focusing on current status, though it doesn't explicitly name 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 like get_indexing_history or get_diagnostics. There are no context cues or exclusion criteria, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description's safety profile is covered. The description adds the 'daily' context and clarifies this is a quota check, which is minor useful context. However, it does not disclose return format, units, or potential errors, but given the annotations, a neutral score is appropriate.
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 that is front-loaded with the key concept. Every word adds value, with no redundancy or fluff. It is optimally sized for a simple read-only quota check 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?
Given the tool's low complexity, full schema coverage, and read-only annotation, the description is mostly complete. It doesn't explain the exact output shape, but the description 'remaining daily re-crawl quota' implies a numeric value. The lack of an output schema is compensated by the simplicity of 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?
The input schema covers both parameters with descriptions (100% coverage). The description mentions 'for a host' which aligns with host_id, but adds no additional meaning beyond what the schema already provides. Format is described in the schema, so the description does not need to repeat it. Baseline 3 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 clearly identifies the tool's purpose: retrieving the remaining daily re-crawl quota for a host. It is specific to the resource (host) and metric (quota), which distinguishes it from sibling tools like get_recrawl_task, though it lacks an explicit verb like 'get' or 'retrieve' and is phrased as a noun phrase.
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 scenarios, prerequisites (e.g., needing the host_id from get_hosts), or exclusions. Context signals show sibling tools exist, but the description offers no differentiation or usage conditions.
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 readOnlyHint annotation already signals a safe read operation, lowering the bar for disclosure. The description adds context about the returned data points (query text, shows, clicks, average position) but does not disclose defaults, pagination behavior, or any limitations. This is acceptable but not rich beyond what annotations and schema already hint.
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 that immediately states the tool's purpose and key output fields. It is front-loaded and contains no filler or redundant wording, earning the highest score for conciseness.
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 tool has 9 parameters, no output schema, and only a readOnlyHint annotation. The description gives a high-level overview of the return content but omits practical details such as default date ranges, pagination, or output format behavior. However, the parameter schema is descriptive, and for a analytics read tool, this level of description is minimally complete but leaves room for improvement.
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 100%, so all nine parameters have descriptions. The tool description adds no additional parameter meaning beyond echoing the indicator fields already enumerated in query_indicator. With full schema coverage, a baseline of 3 is appropriate.
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 purpose: 'Per-query analytics: query text, shows, clicks, average position.' This clearly indicates it retrieves per-query performance metrics and frames it as 'the data behind which queries bring traffic.' It differentiates itself from sibling tools like get_query_analytics and get_search_queries by emphasizing per-query granularity, though it does not explicitly name an alternative.
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 usage for understanding traffic-driving queries ('the data behind which queries bring traffic') but provides no explicit guidance on when to choose this tool over siblings such as get_query_analytics or get_search_queries. It lacks exclusions or alternative references, making the usage context inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds context by listing what types of diagnostics are covered. However, it does not disclose behavioral details such as response structure, whether data is real-time, or any auth requirements beyond the schema.
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 conveys the essential purpose without waste. Every word earns its place, making it highly efficient.
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 read-only tool with two parameters and full schema coverage, the description is sufficient: it clearly states the resource and categories. It lacks details about return values, but the format parameter provides some indication, and no output schema exists to impose additional burden.
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 100%, with both 'host_id' and 'format' having descriptions. The tool description adds no additional parameter meaning beyond these schema definitions, so it meets the baseline without enhancement.
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 identifies the tool as providing site diagnostics, listing specific categories (crawl errors, DNS issues, server problems). This distinguishes it from sibling tools like get_hosts or get_indexing, making the purpose specific and unambiguous.
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 usage when site health or technical issues are needed, but there is no explicit when-to-use or comparison with alternatives. It relies on the distinct resource name to differentiate from siblings.
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 readOnlyHint annotation already declares this as a safe read operation. The description adds that it returns a time series of indexed and excluded counts, which is useful context. However, it does not disclose additional behavioral traits such as pagination, data granularity, or how the trend is presented.
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 that front-loads the core concept and use case. It contains no filler or redundant wording, making it highly efficient.
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 a read-only history query with well-documented parameters and a clear output concept (trend of indexed/excluded counts). The schema covers parameter semantics, but the absence of an output schema means the exact return structure is unspecified, leaving a small gap.
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?
All four parameters (host_id, format, date_from, date_to) have clear descriptions in the schema, including defaults and formats. The description itself adds no extra parameter-level information, so the baseline score of 3 applies given the 100% schema coverage.
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 identifies the tool as providing an indexed/excluded page-count trend over time, with the explicit use case of detecting deindexing. This distinguishes it from siblings like get_indexing, which likely shows current status, and other analytics tools.
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 a usage context ('detect deindexing') but does not explicitly state when to use this tool versus alternatives or provide any exclusions. There is no mention of prerequisites or comparing with get_indexing or get_query_analytics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds limited extra context. It clarifies the scope ('your' account) and that user_id is the key returned data, but does not disclose additional behavioral details like output structure or rate limits.
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 efficiently conveys the tool's purpose and the key output identifier.
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 read-only tool with one optional parameter and clear annotations, the description is sufficient. It mentions the core output (user_id) but does not elaborate on the response format; however, the format parameter allows the user to control that.
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 only parameter (format) is fully described in the schema (100% coverage), including its enum values and default. The description adds no extra meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Yandex Webmaster account info (user_id). The verb 'get' and the specific resource 'account info' distinguish it from sibling tools that focus on site diagnostics, queries, or indexing.
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?
Usage is implied: use when you need your account info. However, no explicit guidance is given on when this tool should be used over alternatives, nor are there any stated exclusions. The context makes it obvious but it is not explicitly stated.
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?
Annotations already declare readOnlyHint: true, so safety profile is covered. The description adds the aggregate-vs-per-query behavioral boundary, which is useful, but it doesn't disclose additional traits like return structure, pagination, or rate limits. With annotations present, 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, front-loaded sentence that immediately conveys the core behavior and scope. Every word earns its place, with the 'NOT per-query' caveat adding critical disambiguation without bloat.
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 tool with 6 parameters and no output schema, the description is fairly complete: it explains the aggregate nature, date range, and metrics, while the format parameter hints at output type. However, it doesn't describe the shape of the 'time series' (e.g., daily breakdown), which would make it more complete.
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 100%, so the baseline is 3. The description mentions 'shows/clicks/position' which aligns with query_indicator enum values, adding slight semantic context, but it doesn't go beyond the schema's already thorough parameter descriptions.
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 action ('Aggregate search-traffic time series') and clearly delineates the scope ('total shows/clicks/position over a date range'). The explicit 'NOT per-query' differentiates it from sibling tools like get_search_queries, making the purpose 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?
The description provides a clear exclusion ('NOT per-query'), signaling when not to use this tool. However, it doesn't explicitly name alternative tools for per-query data, leaving some inference to the agent. The negative cue is strong but lacks a direct 'instead, use X' pointer.
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?
Annotations already declare readOnlyHint=true, so safety is clear. The description adds the context that this tool is for status checking (read-only) and references the source of task IDs. However, it does not detail response behavior, possible statuses, or that results may be delayed. 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, concise sentence that is front-loaded with the core purpose. No wasted words; it communicates the essential information immediately.
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?
This is a simple read-only status tool with full schema coverage and a readOnlyHint annotation. The description sufficiently conveys the main usage flow (submit_url → get_recrawl_task). It omits the optional format parameter details, but those are fully covered in the schema, so the description is complete enough for this complexity.
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 100% with descriptive parameter definitions. The description does not add significant meaning beyond mentioning 'by id' and 'from submit_url', which are already in the schema. Baseline 3 applies since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving the status of a re-crawl task by ID, with the source specified as 'from submit_url'. This distinguishes it from sibling tools like get_recrawl_quota and submit_url, providing a specific verb+resource+scope.
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 phrase 'from submit_url' strongly implies when to use this tool: after submitting a URL to obtain a task_id. It ties directly to the submit_url flow, giving clear contextual usage guidance, though it does not explicitly mention alternatives or exclusions.
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 readOnlyHint annotation already indicates a safe read operation. The description adds valuable context by specifying the scope ('all sites' meaning no filtering) and the output content ('URL, verification status'). While it doesn't disclose pagination or rate limits, the annotation lowers the bar, and this additional context is useful.
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 that front-loads the action and resource. It contains no filler and every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has good annotations, and a fully described schema. The description explicitly states the output fields (URL, verification status) and the scope (all sites), which is sufficient for an agent to know what the tool returns and how to invoke it. There are no significant gaps.
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 only parameter, 'format', is fully described in the schema with an enum, default, and description. The tool description adds nothing beyond the schema, and with 100% schema coverage, the baseline score of 3 is appropriate.
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 verb 'List' and the resource 'all sites in Yandex.Webmaster', with specifics on output ('URL, verification status'). This differentiates it from sibling tools like get_diagnostics or get_search_queries, which target different data. It is specific and non-tautological.
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 this tool is for retrieving a list of all sites, but does not explicitly mention when to use it over alternatives or provide any exclusions. Sibling tool names hint at distinct functions, but the description alone offers no explicit guidance, so usage context is only implied.
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?
Annotations already declare readOnlyHint=true, covering the safety profile. The description adds value by disclosing the exact return fields (URL, status, last checked, indexed count), which is not present in the schema. It does not mention pagination, rate limits, or auth, but for a read-only list operation this is sufficient context beyond 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 description is exactly one sentence, front-loaded with the action and resource, and every word adds value. It avoids redundancy and is highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with only two parameters (one required), full schema coverage, read-only annotation, and a short description enumerating return fields, the description is complete. No output schema is needed because the description states what will be returned. There are no missing behavioral requirements or edge cases.
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 100%, with both host_id and format fully documented in the schema. The description does not add any new parameter-level meaning; it only references the host concept. Per the rubric, the baseline of 3 applies when the schema carries the burden.
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 'List' with the resource 'sitemaps' and scopes it 'for a host', clearly distinguishing it from sibling tools like get_hosts or get_indexing. It also enumerates the output fields (URL, status, last checked, indexed count), making the purpose explicit.
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 should be used when sitemap data is needed for a host, but offers no explicit guidance on when to prefer this over alternatives or when not to use it. There is no reference to sibling tools or exclusion criteria, so the agent must infer from the name and context.
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?
Annotations include readOnlyHint=true, which already signals the tool is read-only. The description adds little beyond restating the read-only nature implicitly via 'analytics'. It discloses the deprecation status, which is a useful meta-context, but does not add behavioral details like rate limits, pagination, or auth requirements. With annotations covering the safety profile, 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?
The description is a single sentence, front-loaded with the deprecation notice and alternative tool. It contains zero wasted words while conveying the tool's purpose, deprecation, and recommended replacement — highly efficient.
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 read-only tool with 4 parameters (1 required), the description combined with full schema coverage provides enough context. It names the output metrics (clicks, impressions, position) despite lacking an output schema, and the deprecation notice completes the picture. It could mention date range or format nuances, but these are already in the schema, so the description is sufficiently complete.
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 100%, meaning all parameters (format, date_to, date_from, host_id) are already documented in the JSON schema. The description adds no parameter-specific guidance beyond the mention of clicks/impressions/position, which is output content rather than parameter semantics. Baseline 3 is appropriate.
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 tool provides per-query search analytics (clicks, impressions, position). The deprecation notice and pointer to get_popular_search_queries immediately distinguish it from alternatives, making the purpose explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states '[DEPRECATED — use get_popular_search_queries]', giving an unambiguous directive to avoid this tool and use a specific alternative. This is clear when-to-use guidance, even though it primarily says 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?
Annotations already declare readOnlyHint=false and idempotentHint=false. The description adds a valuable behavioral detail: 'consumes daily quota', which is not in annotations. This helps the agent understand the side effect of limited quota. No contradictions.
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 action and the key side effect. Every word earns its place with no redundancy or fluff.
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 mutation tool with complete schema coverage and annotations, the description is largely sufficient. It explains the core action and quota consumption. However, it does not hint at what the response contains (e.g., task ID) despite no output schema existing, leaving a minor gap.
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 100%—all three parameters (url, format, host_id) have descriptions in the schema. The description adds no additional parameter meaning beyond what the schema provides. Per the rubric, baseline is 3 when schema coverage is high.
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 specific action: 'Submit a URL for re-crawling / re-indexing by Yandex'. It uses a precise verb (submit) and resource (URL), and the intent is unambiguous. It differentiates from sibling tools, which are all get_* read operations, by being the only mutating submission tool.
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 implies the usage context: when you want to trigger re-indexing of a URL. It clearly contrasts with the read-only sibling tools. However, it does not explicitly state when not to use it or mention alternatives, so it falls short of a 5 but is clear in purpose.
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

Copy to your README.md:

[![yandex-webmaster-mcp MCP server](https://glama.ai/mcp/servers/theYahia/yandex-webmaster-mcp/badges/card.svg)](https://glama.ai/mcp/servers/theYahia/yandex-webmaster-mcp)

Score Badge

Copy to your README.md:

[![yandex-webmaster-mcp MCP server](https://glama.ai/mcp/servers/theYahia/yandex-webmaster-mcp/badges/score.svg)](https://glama.ai/mcp/servers/theYahia/yandex-webmaster-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/theYahia/yandex-webmaster-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server