Yandex Webmaster MCP

Recrawl quota & tasks

recrawl_status

Read-only

Check recrawl activity and daily quota. View recent recrawl tasks with status (in progress, done, failed) or verify a specific task by ID before submitting a new recrawl.

Instructions

Read-only view of the host recrawl activity. With no taskId: the remaining daily quota plus the most recent recrawl tasks and their state (IN_PROGRESS, DONE, FAILED). Pass taskId (from recrawl_submit) to check one task. Use before recrawl_submit to confirm quota is available.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "recrawl_status"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Recent tasks to list when no taskId (1-100). Default 10.
`hostId`	No	Host id (e.g. "https:example.com:443"). Defaults to YANDEX_WEBMASTER_HOST_ID.
`taskId`	No	Check a single recrawl task by its id (from recrawl_submit). Omit to get quota + recent tasks.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.1Jul 31, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds meaningful context such as the states (IN_PROGRESS, DONE, FAILED), the notion of a daily quota, and the temporal relationship with recrawl_submit. It does not repeat the annotations but complements them with operational details, such as the default behavior when taskId is omitted.

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 three sentences, each earning its place. It front-loads the read-only nature, then describes the two modes concisely, and ends with a practical usage tip. No redundant words or unnecessary detail.

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 tool with no output schema, the description adequately explains what the agent can expect: remaining quota, recent tasks, and their states. It also covers the two invocation modes and provides a clear use case ('before recrawl_submit'). The moderate parameter count and read-only annotation reduce the need for additional behavioral disclaimers, making this 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 coverage is 100% for all three parameters, and the schema descriptions already explain the limit, hostId, and taskId semantics. The description reinforces the conditional logic of taskId and the limit's role, but it does not add substantial new meaning beyond the schema, so a 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 opens with 'Read-only view of the host recrawl activity,' clearly stating the verb and resource. It further differentiates the tool by describing the quota and task-list output, and explicitly distinguishes it from recrawl_submit by noting the taskId origin and the pre-submit usage.

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 gives explicit usage guidance: 'Use before recrawl_submit to confirm quota is available' and differentiates between the no-taskId mode (quota + recent tasks) and the taskId mode (check one task). It also references recrawl_submit as the source of taskId, clarifying when to use this tool versus the sibling.

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

Deploy Server