Skip to main content
Glama
Crash-SV

Yandex Webmaster MCP Server

by Crash-SV

Get Sitemaps

get_sitemaps

List auto-detected sitemaps for a Yandex Webmaster user and host to audit sitemap URLs and paginate through discovered entries.

Instructions

Get auto-detected sitemaps.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoResults per page (1-100, default 10)
host_idYesHost ID (format: https:example.com:443)
user_idYesYandex Webmaster user ID
offset_idNoCursor-based pagination (sitemap ID to start from)
parent_idNoParent sitemap ID (for index sitemaps)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.9/5.0
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. 'Auto-detected' hints that results are system-discovered rather than user-submitted, but nothing is said about pagination limits, permissions, or result ordering, all of which matter for a listing tool.

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

Conciseness4/5

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

A single compact sentence with no filler. It is efficient, though its extreme brevity leaves little room for the routing or behavioral context a caller needs.

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

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 need not be explained, but with no annotations and a listing tool requiring two scoping identifiers, the description is too thin to tell an agent when and how to use it correctly.

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

Parameters3/5

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

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

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

Purpose4/5

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

States a specific verb (Get) and resource (sitemaps) with the scope qualifier 'auto-detected', which implicitly distinguishes it from user-added sitemaps. It does not name the sibling tools that would complete the disambiguation, but the resource is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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