Skip to main content
Glama
askads

Yandex Wordstat MCP

by askads
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Динамика спроса во времени

dynamics
Read-onlyIdempotent

Track Yandex search demand over time by phrase, returning dated counts and share data to reveal seasonality and trends. Set daily, weekly, or monthly intervals and filter by region or device.

Instructions

Возвращает, как менялся спрос на фразу во времени, — ряд {date, count, share}, где share — доля от всех поисковых запросов Яндекса. Подходит для оценки сезонности и тренда. period задаёт шаг ряда (daily/weekly/monthly). fromDate/toDate ограничивают диапазон метками времени RFC3339, при этом toDate должен попадать на границу периода.

Input Schema

NameRequiredDescriptionDefault
periodNoШаг ряда. По умолчанию monthly.
phraseYesПоисковая фраза для анализа.
toDateNoКонец диапазона (RFC3339), выровненный по границе периода.
devicesNoФильтр по устройствам: любые из all, desktop, phone, tablet. Без параметра — все устройства.
fromDateNoНачало диапазона (RFC3339), например 2026-01-01T00:00:00Z.
regionIdsNoId регионов, которыми ограничить спрос, например [213] (Москва), [2] (Санкт-Петербург). Id берутся из list_regions. Без параметра — все регионы.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv2.4.0
    • changedInput schema / properties / devices / description
      Previous value: -"Device filter: any of all, desktop, phone, tablet. Omit for all devices."New value: +"Фильтр по устройствам: любые из all, desktop, phone, tablet. Без параметра — все устройства."
    • changedInput schema / properties / fromDate / description
      Previous value: -"Range start (RFC3339), e.g. 2026-01-01T00:00:00Z."New value: +"Начало диапазона (RFC3339), например 2026-01-01T00:00:00Z."
    • changedInput schema / properties / period / description
      Previous value: -"Granularity of the series. Default monthly."New value: +"Шаг ряда. По умолчанию monthly."
    • changedInput schema / properties / phrase / description
      Previous value: -"The search phrase to research."New value: +"Поисковая фраза для анализа."
    • changedInput schema / properties / regionIds / description
      Previous value: -"Region ids to scope demand to, e.g. [213] (Moscow), [2] (St. Petersburg). Get ids from list_regions. Omit for all regions."New value: +"Id регионов, которыми ограничить спрос, например [213] (Москва), [2] (Санкт-Петербург). Id берутся из list_regions. Без параметра — все регионы."
    • changedInput schema / properties / toDate / description
      Previous value: -"Range end (RFC3339), aligned to the period boundary."New value: +"Конец диапазона (RFC3339), выровненный по границе периода."
  2. Changed3 schema fields changedv2.0.1
    • addedInput schema / properties / fromDate / pattern
      Added value: +"^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}(\\.\\d+)?(Z|[+-]\\d{2}:\\d{2})$"
    • changedInput schema / properties / regionIds / items / anyOf
      Previous value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "string"
-  }
-]New value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "pattern": "^\\d+$",
+    "type": "string"
+  }
+]
    • addedInput schema / properties / toDate / pattern
      Added value: +"^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}(\\.\\d+)?(Z|[+-]\\d{2}:\\d{2})$"
  3. Changed2 schema fields changedv2.0.0
    • changedInput schema / properties / fromDate / description
      Previous value: -"Range start. cloud: RFC3339; oauth: YYYY-MM-DD."New value: +"Range start (RFC3339), e.g. 2026-01-01T00:00:00Z."
    • changedInput schema / properties / toDate / description
      Previous value: -"Range end (aligned to the period). cloud: RFC3339; oauth: YYYY-MM-DD."New value: +"Range end (RFC3339), aligned to the period boundary."
  4. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. The description still adds real context beyond them: the return field semantics (share = fraction of all Yandex searches) and the non-obvious constraint that toDate must land on a period boundary. Missing: any note on rate limits, empty-result behavior, or data granularity 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?

Three short sentences, front-loaded with the core purpose and return shape, followed by usage and the one tricky parameter constraint. No 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?

With no output schema, the description usefully documents the returned {date, count, share} fields and explains share, covering the biggest gap. Remaining gaps are minor: what happens if toDate is not aligned to the period, and whether the series can return empty buckets.

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 re-states that period sets the series step and that from/to use RFC3339 with toDate aligned to period boundaries, but this largely duplicates the schema and adds nothing about devices or regionIds.

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?

Names a specific resource and verb: shows how demand for a phrase changed over time, and returns a concrete series shape {date, count, share}. This is inherently distinct from time-agnostic siblings like top_requests or regions, so an agent can select it without opening the schema.

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?

"Подходит для оценки сезонности и тренда" gives clear usage context for when this tool is appropriate. It does not name an alternative or state exclusions (e.g. when a single-point snapshot would be enough), leaving that inference to the agent.

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

Deploy Server

Other Tools