Яндекс Вордстат MCP подключает AI-приложение к статистике поискового спроса Яндекса. Спросите, как часто ищут фразу, в какие месяцы интерес растёт и в каких городах тема популярнее, — ассистент соберёт данные Вордстата и объяснит результат. Сервер работает через Yandex Cloud Search API, поэтому не требует доступа к рекламному кабинету Директа.
Пять инструментов. Топ и похожие запросы, динамика спроса, распределение по регионам, справочник регионов и технический запрос к API.
Только чтение. API Вордстата не создаёт кампании, объявления, ключевые фразы и другие объекты.
Спрос и сезонность. Топ запросов и регионы показывают последние 30 дней; динамика строится по дням, неделям или месяцам за нужный период.
Регион и устройство. Отчёты можно сузить до региона и сравнить спрос на компьютерах, телефонах и планшетах.
Без OAuth Директа. Нужны API-ключ и ID каталога Yandex Cloud для Search API.
Начните с безопасного запроса:
Сколько в месяц ищут «купить велосипед» и какие есть похожие запросы?
Подключить сервер · Посмотреть сценарии · Открыть техническую документацию
Related MCP server: Wordstat MCP
Нужны Node.js 20 или новее, API-ключ Yandex Cloud для Search API и ID каталога Yandex Cloud.
Получите доступ и добавьте сервер в AI-приложение — инструкции для пяти приложений ниже.
Спросите: «Сколько в месяц ищут „купить велосипед“ и какие есть похожие запросы?»
Через интерфейс приложения:
Откройте Settings → Plugins → MCP servers.
Нажмите Add server.
Добавьте команду запуска npx -y mcp-yandex-wordstat@latest и переменные окружения WORDSTAT_API_KEY, WORDSTAT_FOLDER_ID.
Через командную строку:
codex mcp add yandex-wordstat \
--env WORDSTAT_API_KEY=ваш_ключ \
--env WORDSTAT_FOLDER_ID=ваш_folder_id \
-- npx -y mcp-yandex-wordstat@latestПроверьте подключение:
codex mcp listclaude mcp add \
--env WORDSTAT_API_KEY=ваш_ключ \
--env WORDSTAT_FOLDER_ID=ваш_folder_id \
--transport stdio \
--scope user \
yandex-wordstat \
-- npx -y mcp-yandex-wordstat@latestПроверьте сервер:
claude mcp listОткройте Settings → Developer → Edit Config и добавьте сервер в claude_desktop_config.json:
{
"mcpServers": {
"yandex-wordstat": {
"command": "npx",
"args": ["-y", "mcp-yandex-wordstat@latest"],
"env": {
"WORDSTAT_API_KEY": "ваш_ключ",
"WORDSTAT_FOLDER_ID": "ваш_folder_id"
}
}
}
}Если Edit Config недоступна, отредактируйте ~/Library/Application Support/Claude/claude_desktop_config.json на macOS или %APPDATA%\Claude\claude_desktop_config.json на Windows.
Для всех проектов создайте ~/.cursor/mcp.json; только для текущего проекта — .cursor/mcp.json:
{
"mcpServers": {
"yandex-wordstat": {
"command": "npx",
"args": ["-y", "mcp-yandex-wordstat@latest"],
"env": {
"WORDSTAT_API_KEY": "ваш_ключ",
"WORDSTAT_FOLDER_ID": "ваш_folder_id"
}
}
}
}Откройте палитру команд и выполните MCP: Open User Configuration. Добавьте в mcp.json:
{
"servers": {
"yandex-wordstat": {
"type": "stdio",
"command": "npx",
"args": ["-y", "mcp-yandex-wordstat@latest"],
"env": {
"WORDSTAT_API_KEY": "${input:wordstat_api_key}",
"WORDSTAT_FOLDER_ID": "${input:wordstat_folder_id}"
}
}
},
"inputs": [
{
"type": "promptString",
"id": "wordstat_api_key",
"description": "API-ключ Yandex Cloud",
"password": true
},
{
"type": "promptString",
"id": "wordstat_folder_id",
"description": "ID каталога Yandex Cloud"
}
]
}Проверьте запуск командой MCP: List Servers.
«Сколько раз за месяц ищут эту фразу и какие похожие запросы встречаются?»
«Подбери запросы вокруг „доставка пиццы“ с их частотностью».
«Покажи запросы, содержащие мою фразу, отдельно от семантически похожих».
«Покажи спрос на „лыжи“ по месяцам за год».
«В какие недели спрос на эту услугу растёт или падает?»
«Сравни динамику запроса на телефонах и компьютерах».
«В каких городах интерес к „ремонту квартир“ выше среднего?»
«Сравни спрос в Москве и Санкт-Петербурге».
«Найди ID нужного региона и сузь следующий отчёт до него».
top_requests показывает популярные запросы, которые содержат заданную фразу, и семантически близкие запросы. Общий totalCount относится к последним 30 дням.
dynamics возвращает ряд {date, count, share} с дневной, недельной или месячной детализацией. regions распределяет спрос за последние 30 дней по регионам, а affinityIndex выше 100% означает интерес выше среднего. Значения счётчиков могут приходить строками: Яндекс передаёт большие целые числа в JSON в таком виде.
Один вызов строит данные только для одной фразы. Для большого списка ключевых слов лучше сначала сузить список, а не запускать все запросы подряд: квота Yandex Cloud Search API общая для одного ключа.
В Yandex Cloud создайте сервисный аккаунт с ролью search-api.webSearch.user.
Выпустите для него API-ключ со scope yc.search-api.execute — шаги описаны в документации AI Studio.
Найдите ID каталога (folderId) в консоли Yandex Cloud на странице каталога и в URL страницы.
Передайте ключ как WORDSTAT_API_KEY, а каталог как WORDSTAT_FOLDER_ID.
Сервер обращается к Yandex Cloud Search API v2. Старый отдельный Wordstat API с OAuth не используется. API-ключ хранится в конфигурации MCP-клиента открытым текстом — относитесь к нему как к паролю.
Ничего в Яндекс Вордстате. Все пять инструментов, включая raw_request, работают только на чтение. Технически API использует POST, но у Wordstat нет эндпоинтов на запись; сервер дополнительно не позволяет произвольному запросу уйти на другой хост.
Агрегированные данные. Сервер получает статистику поискового спроса, а не данные конкретного рекламного кабинета.
Кэш справочника регионов. В долгоживущем процессе дерево регионов загружается один раз и переиспользуется в следующих запросах.
Повторы при временных ошибках. Таймаут одного запроса — 60 секунд. Сервер делает до трёх повторов после 429, 5xx, сетевой ошибки или тайм-аута; учитывает Retry-After, а задержка не превышает 30 секунд.
Нет фонового наблюдения. Сервер работает, когда его вызывает AI-приложение. Если приложение поддерживает задания по расписанию, в нём можно настроить периодический отчёт по выбранным фразам.
Анонимная телеметрия. По умолчанию сервер отправляет случайный идентификатор установки, имя события или инструмента, версии сервера, Node.js, ОС и AI-клиента. При вызове инструмента сервер также отправляет его исход, а при ошибке - фрагмент её текста: код и сообщение, в которых e-mail, адреса, токены, числа от 4 цифр и текст в кавычках заменены на «#». Если в тексте ошибки есть значение из запроса, оно тоже может попасть во фрагмент. В неё не попадают API-ключ, аргументы инструментов, ваши сообщения, данные спроса и значения переменных окружения. Отключить её для MCP-серверов Ask Ads: ASKADS_TELEMETRY=0.
Каталог MCP-возможностей — страницы по пользовательским задачам для каждого инструмента.
Нашли ошибку или не хватает сценария? Создайте issue или напишите в Telegram.
Возвращает, как менялся спрос на фразу во времени, — ряд {date, count, share}, где share — доля от всех поисковых запросов Яндекса. Подходит для оценки сезонности и тренда. period задаёт шаг ряда (daily/weekly/monthly). fromDate/toDate ограничивают диапазон метками времени RFC3339, при этом toDate должен попадать на границу периода.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Шаг ряда. По умолчанию monthly. | |
| phrase | Yes | Поисковая фраза для анализа. | |
| toDate | No | Конец диапазона (RFC3339), выровненный по границе периода. | |
| devices | No | Фильтр по устройствам: любые из all, desktop, phone, tablet. Без параметра — все устройства. | |
| fromDate | No | Начало диапазона (RFC3339), например 2026-01-01T00:00:00Z. | |
| regionIds | No | Id регионов, которыми ограничить спрос, например [213] (Москва), [2] (Санкт-Петербург). Id берутся из list_regions. Без параметра — все регионы. |
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.
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.
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.
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.
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.
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.
Возвращает справочное дерево регионов, которые поддерживает Вордстат, — id регионов и их названия (label). Эти id подставляются в regionIds/regionMode остальных инструментов, а названия расшифровывают id регионов в их ответах. Дерево большое и стабильное: достаточно запросить его один раз и закешировать.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the result is large and stable and should be cached rather than re-fetched. Minor gap is that it does not say anything about the tree's depth or whether pagination applies, though with no parameters pagination is unlikely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: identity of the resource first, then how to use the output, then the caching hint. Every sentence carries information and nothing is repeated from the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no input schema fields to explain and no output schema, the description carries the return-value burden and does it reasonably: ids plus labels, large and stable. It stops short of describing the tree's structural shape (nesting/parent-child) or example values, which would fully close the gap for an agent parsing the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline-4 case. The description correctly implies no inputs are needed and instead explains how the output feeds sibling tools' parameters, which is the only parameter-adjacent meaning available.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Возвращает справочное дерево регионов') and states exactly what the payload contains: region ids and their labels. It also implicitly separates this reference lookup from the sibling `regions`, which computes statistics, by framing this tool as a lookup table that feeds the other tools' parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It tells the agent precisely where the returned ids go ('подставляются в regionIds/regionMode остальных инструментов') and what the labels are for (decoding ids in other tools' responses). It also advises calling once and caching because the tree is large and stable. No explicit 'do not use this for X' exclusion is given, which keeps it just 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.
Универсальный запрос: обращается напрямую к любому пути Wordstat в Yandex Cloud Search API — для эндпоинтов, у которых нет отдельного инструмента, например "v2/wordstat/topRequests". Все эндпоинты Вордстата работают методом POST; body отправляется как JSON (folderId подставляется автоматически).
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Тело запроса в формате JSON. | |
| path | Yes | Путь API, например "v2/wordstat/dynamics". | |
| method | No | HTTP-метод. Поддерживается только POST, он же по умолчанию. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/open-world, so the lower bar applies, and the description still adds real context: POST is the only supported method, `body` is serialized as JSON, and folderId is injected automatically. It does not cover error behavior or what an invalid path returns, which matters for a pass-through tool, so it stops short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first establishes what it is and when to reach for it, the second carries the operational constraints. Nothing could be removed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a raw HTTP pass-through with no output schema and open-world semantics, the description never says what comes back — raw JSON of unknown shape, or an error envelope — which is the single most important unknown for this kind of tool. It covers invocation well but leaves the result contract and failure modes unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema by explaining that `body` is sent as JSON and that folderId is auto-injected into it — non-obvious behavior the schema does not state. Neither `path` formatting beyond the example nor enum restriction gets extra clarification, keeping it at 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('обращается напрямую к любому пути Wordstat в Yandex Cloud Search API') and immediately scopes it to endpoints without a dedicated tool, which separates it from the four sibling tools. An agent can tell this is a raw passthrough, not a typed query wrapper.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the selection rule — use this only for endpoints that have no separate tool — which is a clear when-to-use condition. However, the illustrative path it names ("v2/wordstat/topRequests") is exactly what the sibling top_requests already covers, which slightly muddies the rule it just set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает, как спрос на фразу распределён по регионам за последние 30 дней. В каждой строке — id региона, count, share и affinityIndex (>100% — интерес в регионе выше среднего, <100% — ниже). regionMode выбирает группировку: all, cities (только города) или regions (только области и субъекты). Сопоставить id регионов с названиями помогает list_regions.
| Name | Required | Description | Default |
|---|---|---|---|
| phrase | Yes | Поисковая фраза для анализа. | |
| regionMode | No | Группировка: all (по умолчанию), cities (только города) или regions (только субъекты и области). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond the annotations: the fixed 30-day window, the exact row fields (id, count, share, affinityIndex), and how to interpret affinityIndex above/below 100. No output schema exists, so this return-value disclosure is genuinely valuable, and it is consistent with the readOnly/idempotent annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the core purpose, followed by return shape, parameter meaning, and a pointer to a helper tool. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, return fields, metric interpretation, and the regionMode grouping. With no output schema, the enumerated row fields fill that gap, leaving nothing an agent needs missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are already documented, including the enum values for regionMode. The description restates the regionMode grouping without adding syntax or edge-case detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: returns how demand for a phrase is distributed across regions over the last 30 days. This is distinguishable from siblings like dynamics and top_requests without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case (regional breakdown of demand) is clear, and it explicitly points to list_regions for mapping region ids to names. It does not state when to prefer this over dynamics or top_requests, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает поисковый спрос по фразе за последние 30 дней: самые популярные запросы, которые СОДЕРЖАТ фразу (results), и семантически ПОХОЖИЕ запросы, которые могут её не содержать (associations), плюс totalCount. Подходит для подбора ключевых фраз и оценки спроса. Значения счётчиков могут приходить строками (int64). Необязательные regionIds и devices сужают выборку; numPhrases задаёт, сколько фраз вернуть (1..2000).
| Name | Required | Description | Default |
|---|---|---|---|
| phrase | Yes | Поисковая фраза для анализа, например «купить велосипед». | |
| devices | No | Фильтр по устройствам: любые из all, desktop, phone, tablet. Без параметра — все устройства. | |
| regionIds | No | Id регионов, которыми ограничить спрос, например [213] (Москва), [2] (Санкт-Петербург). Id берутся из list_regions. Без параметра — все регионы. | |
| numPhrases | No | Сколько топовых фраз вернуть (1..2000; по умолчанию 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the description doesn't need to re-establish safety. It does add real behavioral context: the two-bucket result structure and the caveat that counters may arrive as strings (int64), which is non-obvious and valuable. It does not cover rate limits, ordering, or pagination behavior, so it stays at a moderate score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the return structure and then the type caveat and parameter hints. Dense but every clause carries information; minor redundancy with the schema on parameter ranges keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description carries the burden of explaining returns — and it does: names results, associations and totalCount and flags the int64-as-string quirk. Together with complete schema descriptions for all parameters, an agent has everything needed to call and interpret this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented in the schema with examples and defaults. The description only restates that regionIds/devices narrow the sample and numPhrases is 1..2000 — no syntax or semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource (returns search demand for a phrase over the last 30 days) and explicitly distinguishes the two result buckets: results (containing the phrase) and associations (semantically similar, may not contain it), plus totalCount. This is far more precise than the tool name and lets an agent understand the payload without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear usage context (keyword selection and demand estimation) and tells the agent that regionIds and devices narrow the sample. However, it never names an alternative sibling — e.g. when to prefer dynamics or regions — so the agent gets context but no explicit routing against alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.4.0dynamics6 fields changedInput schema / properties / devices / descriptionPrevious value: -"Device filter: any of all, desktop, phone, tablet. Omit for all devices."New value: +"Фильтр по устройствам: любые из all, desktop, phone, tablet. Без параметра — все устройства."Input schema / properties / fromDate / descriptionPrevious value: -"Range start (RFC3339), e.g. 2026-01-01T00:00:00Z."New value: +"Начало диапазона (RFC3339), например 2026-01-01T00:00:00Z."Input schema / properties / period / descriptionPrevious value: -"Granularity of the series. Default monthly."New value: +"Шаг ряда. По умолчанию monthly."Input schema / properties / phrase / descriptionPrevious value: -"The search phrase to research."New value: +"Поисковая фраза для анализа."Input schema / properties / regionIds / descriptionPrevious 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. Без параметра — все регионы."Input schema / properties / toDate / descriptionPrevious value: -"Range end (RFC3339), aligned to the period boundary."New value: +"Конец диапазона (RFC3339), выровненный по границе периода."raw_request3 fields changedInput schema / properties / body / descriptionPrevious value: -"JSON request body."New value: +"Тело запроса в формате JSON."Input schema / properties / method / descriptionPrevious value: -"HTTP method. Only POST is supported; defaults to POST."New value: +"HTTP-метод. Поддерживается только POST, он же по умолчанию."Input schema / properties / path / descriptionPrevious value: -"API path, e.g. \"v2/wordstat/dynamics\"."New value: +"Путь API, например \"v2/wordstat/dynamics\"."regions2 fields changedInput schema / properties / phrase / descriptionPrevious value: -"The search phrase to research."New value: +"Поисковая фраза для анализа."Input schema / properties / regionMode / descriptionPrevious value: -"Grouping: all (default), cities (only cities), or regions (only subjects/oblasts)."New value: +"Группировка: all (по умолчанию), cities (только города) или regions (только субъекты и области)."top_requests4 fields changedInput schema / properties / devices / descriptionPrevious value: -"Device filter: any of all, desktop, phone, tablet. Omit for all devices."New value: +"Фильтр по устройствам: любые из all, desktop, phone, tablet. Без параметра — все устройства."Input schema / properties / numPhrases / descriptionPrevious value: -"How many top phrases to return (1..2000; default 20)."New value: +"Сколько топовых фраз вернуть (1..2000; по умолчанию 20)."Input schema / properties / phrase / descriptionPrevious value: -"The search phrase to research, e.g. «купить велосипед»."New value: +"Поисковая фраза для анализа, например «купить велосипед»."Input schema / properties / regionIds / descriptionPrevious 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. Без параметра — все регионы."v2.0.1dynamics3 fields changedInput schema / properties / fromDate / patternAdded value: +"^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}(\\.\\d+)?(Z|[+-]\\d{2}:\\d{2})$"Input schema / properties / regionIds / items / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "string"
- }
-]New value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "pattern": "^\\d+$",
+ "type": "string"
+ }
+]Input schema / properties / toDate / patternAdded value: +"^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}(\\.\\d+)?(Z|[+-]\\d{2}:\\d{2})$"raw_request2 fields changedInput schema / properties / method / descriptionPrevious value: -"HTTP method. Default POST."New value: +"HTTP method. Only POST is supported; defaults to POST."Input schema / properties / method / enumPrevious value: -[
- "GET",
- "POST"
-]New value: +[
+ "POST"
+]top_requests1 field changedInput schema / properties / regionIds / items / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "string"
- }
-]New value: +[
+ {
+ "type": "integer"
+ },
+ {
+ "pattern": "^\\d+$",
+ "type": "string"
+ }
+]v2.0.0dynamics2 fields changedInput schema / properties / fromDate / descriptionPrevious value: -"Range start. cloud: RFC3339; oauth: YYYY-MM-DD."New value: +"Range start (RFC3339), e.g. 2026-01-01T00:00:00Z."Input schema / properties / toDate / descriptionPrevious value: -"Range end (aligned to the period). cloud: RFC3339; oauth: YYYY-MM-DD."New value: +"Range end (RFC3339), aligned to the period boundary."raw_request1 field changedInput schema / properties / path / descriptionPrevious value: -"API path, e.g. \"v2/wordstat/dynamics\" (cloud) or \"v1/regions\" (oauth)."New value: +"API path, e.g. \"v2/wordstat/dynamics\"."regions1 field changedInput schema / properties / devicesRemoved value: -{
- "description": "Device filter: any of all, desktop, phone, tablet. Omit for all devices.",
- "items": {
- "enum": [
- "all",
- "desktop",
- "phone",
- "tablet"
- ],
- "type": "string"
- },
- "type": "array"
-}top_requests1 field changedInput schema / properties / numPhrases / descriptionPrevious value: -"How many top phrases to return (cloud flavor only; default 20). Ignored on the oauth flavor."New value: +"How many top phrases to return (1..2000; default 20)."v0.1.0dynamicslist_regionsraw_requestregionstop_requestsScored across 5 tools
Each tool targets a distinct analytical dimension: top queries/associations, time dynamics, regional distribution, region reference data, and a generic fallback. The only potential overlap is raw_request, which could replicate other tools, but its description explicitly scopes it to endpoints lacking a dedicated tool.
All names use snake_case, but the patterns are mixed: some are nouns (dynamics, regions), one is verb_noun (top_requests, list_regions), and one is adjective_noun (raw_request). The set is readable but lacks a consistent verb_noun convention.
Five tools cover Wordstat's main endpoints (top requests, dynamics, regions, list regions) plus a generic escape hatch. Each tool is justified and the count is well-scoped for the domain.
The surface covers demand analysis (top_requests), trend/seasonality (dynamics), regional breakdown (regions), reference data (list_regions), and any other endpoint via raw_request. No obvious gaps for typical Wordstat workflows.
Landing A/B tests, Yandex Wordstat, Metrika, Direct and 170+ AI models in ChatGPT, Claude, Cursor
Yandex search results, images, and SERP data via the Apify Yandex Search Scraper, hosted MCP.
MCP for Yandex Direct: manage ad campaigns & analytics from Claude or ChatGPT
MCP servers for Yandex APIs: Wordstat, Search, Webmaster, Metrika, Direct. Open source, by Seyka AI.