Yandex Wordstat MCP conecta una aplicación de IA con las estadísticas de demanda de búsqueda de Yandex. Pregunta con qué frecuencia se busca una frase, en qué meses crece el interés y en qué ciudades el tema es más popular: el asistente recopilará los datos de Wordstat y explicará el resultado. El servidor funciona a través de Yandex Cloud Search API, por lo que no requiere acceso a la cuenta publicitaria de Direct.
Cinco herramientas. Consultas principales y similares, dinámica de demanda, distribución por regiones, directorio de regiones y solicitud técnica a la API.
Solo lectura. La API de Wordstat no crea campañas, anuncios, frases clave ni otros objetos.
Demanda y estacionalidad. Las consultas principales y las regiones muestran los últimos 30 días; la dinámica se construye por días, semanas o meses para el período deseado.
Región y dispositivo. Los informes se pueden limitar a una región y comparar la demanda en computadoras, teléfonos y tabletas.
Sin OAuth de Direct. Se necesitan una clave de API y un ID de catálogo de Yandex Cloud para Search API.
Comience con una consulta segura:
¿Cuántas veces al mes se busca «comprar bicicleta» y qué consultas similares existen?
Conectar el servidor · Ver escenarios · Abrir documentación técnica
Related MCP server: Wordstat MCP
Se necesitan Node.js 20 o superior, una clave de API de Yandex Cloud para Search API y un ID de catálogo de Yandex Cloud.
Obtenga acceso y agregue el servidor a la aplicación de IA: instrucciones para cinco aplicaciones a continuación.
Pregunte: «¿Cuántas veces al mes se busca „comprar bicicleta“ y qué consultas similares existen?»
A través de la interfaz de la aplicación:
Abra Settings → Plugins → MCP servers.
Haga clic en Add server.
Agregue el comando de inicio npx -y mcp-yandex-wordstat@latest y las variables de entorno WORDSTAT_API_KEY, WORDSTAT_FOLDER_ID.
A través de la línea de comandos:
codex mcp add yandex-wordstat \
--env WORDSTAT_API_KEY=ваш_ключ \
--env WORDSTAT_FOLDER_ID=ваш_folder_id \
-- npx -y mcp-yandex-wordstat@latestVerifique la conexión:
codex mcp listInstrucciones oficiales de Codex
claude mcp add \
--env WORDSTAT_API_KEY=ваш_ключ \
--env WORDSTAT_FOLDER_ID=ваш_folder_id \
--transport stdio \
--scope user \
yandex-wordstat \
-- npx -y mcp-yandex-wordstat@latestVerifique el servidor:
claude mcp listAbra Settings → Developer → Edit Config y agregue el servidor a claude_desktop_config.json:
{
"mcpServers": {
"yandex-wordstat": {
"command": "npx",
"args": ["-y", "mcp-yandex-wordstat@latest"],
"env": {
"WORDSTAT_API_KEY": "ваш_ключ",
"WORDSTAT_FOLDER_ID": "ваш_folder_id"
}
}
}
}Si Edit Config no está disponible, edite ~/Library/Application Support/Claude/claude_desktop_config.json en macOS o %APPDATA%\Claude\claude_desktop_config.json en Windows.
Para todos los proyectos, cree ~/.cursor/mcp.json; solo para el proyecto actual, .cursor/mcp.json:
{
"mcpServers": {
"yandex-wordstat": {
"command": "npx",
"args": ["-y", "mcp-yandex-wordstat@latest"],
"env": {
"WORDSTAT_API_KEY": "ваш_ключ",
"WORDSTAT_FOLDER_ID": "ваш_folder_id"
}
}
}
}Abra la paleta de comandos y ejecute MCP: Open User Configuration. Agregue a 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"
}
]
}Verifique el inicio con el comando MCP: List Servers.
«¿Cuántas veces al mes se busca esta frase y qué consultas similares aparecen?»
«Selecciona consultas alrededor de „entrega de pizza“ con su frecuencia».
«Muestra las consultas que contienen mi frase, por separado de las semánticamente similares».
«Muestra la demanda de „esquís“ por meses durante un año».
«¿En qué semanas crece o cae la demanda de este servicio?»
«Compara la dinámica de la consulta en teléfonos y computadoras».
«¿En qué ciudades el interés por „reparación de apartamentos“ es superior a la media?»
«Compara la demanda en Moscú y San Petersburgo».
«Encuentra el ID de la región necesaria y limita el siguiente informe a ella».
top_requests muestra las consultas populares que contienen la frase dada y las consultas semánticamente cercanas. El totalCount general se refiere a los últimos 30 días.
dynamics devuelve una serie {date, count, share} con detalle diario, semanal o mensual. regions distribuye la demanda de los últimos 30 días por regiones, y un affinityIndex superior al 100% significa un interés superior a la media. Los valores de los contadores pueden venir como cadenas: Yandex transmite números enteros grandes en JSON de esta manera.
Una sola llamada construye datos solo para una frase. Para una lista grande de palabras clave, es mejor primero reducir la lista en lugar de ejecutar todas las consultas seguidas: la cuota de Yandex Cloud Search API es común para una misma clave.
En Yandex Cloud, cree una cuenta de servicio con el rol search-api.webSearch.user.
Emita para ella una clave de API con el alcance yc.search-api.execute: los pasos se describen en la documentación de AI Studio.
Encuentre el ID del catálogo (folderId) en la consola de Yandex Cloud en la página del catálogo y en la URL de la página.
Pase la clave como WORDSTAT_API_KEY y el catálogo como WORDSTAT_FOLDER_ID.
El servidor se comunica con Yandex Cloud Search API v2. La antigua API de Wordstat separada con OAuth no se utiliza. La clave de API se almacena en la configuración del cliente MCP en texto plano: trátela como una contraseña.
Nada en Yandex Wordstat. Las cinco herramientas, incluida raw_request, funcionan solo de lectura. Técnicamente, la API usa POST, pero Wordstat no tiene endpoints de escritura; el servidor además no permite que una solicitud arbitraria vaya a otro host.
Datos agregados. El servidor obtiene estadísticas de demanda de búsqueda, no datos de una cuenta publicitaria específica.
Caché del directorio de regiones. En un proceso de larga duración, el árbol de regiones se carga una vez y se reutiliza en las siguientes solicitudes.
Reintentos ante errores temporales. El tiempo de espera de una solicitud es de 60 segundos. El servidor hace hasta tres reintentos después de 429, 5xx, error de red o tiempo de espera; tiene en cuenta Retry-After, y el retraso no supera los 30 segundos.
Sin observación en segundo plano. El servidor funciona cuando la aplicación de IA lo llama. Si la aplicación admite tareas programadas, se puede configurar un informe periódico sobre las frases seleccionadas.
Telemetría anónima. Por defecto, el servidor envía un identificador de instalación aleatorio, el nombre del evento o herramienta, las versiones del servidor, Node.js, el sistema operativo y el cliente de IA. No incluye la clave de API, los argumentos de las herramientas, sus mensajes, los datos de demanda ni los valores de las variables de entorno. Para desactivarla para los servidores MCP de Ask Ads: ASKADS_TELEMETRY=0.
Catálogo de capacidades MCP: páginas sobre tareas de usuario para cada herramienta.
¿Encontró un error o falta un escenario? Cree un issue o escriba a 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 инструментов top_requests и dynamics, а названия расшифровывают 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 non-obvious traits beyond them: the response is large, it is stable over time, and caching is the intended usage pattern. It stops short of describing pagination or exact response shape.
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 what is returned, then downstream usage, then the caching recommendation. Every sentence carries information an agent would otherwise have to discover empirically.
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?
No output schema exists, and the description compensates by describing the payload (id + label). Enough to call it correctly, but it never resolves the relationship with the similarly named `regions` sibling, which is the remaining completeness gap.
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?
Zero parameters, so the baseline is 4. The description does useful adjacent work by explaining the semantics of the returned ids in the consuming tools' `regionIds` parameter, though there is no parameter schema of its own to enrich.
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 a reference tree of regions supported by Wordstat, with ids and labels. It also names sibling tools (top_requests, dynamics) where the ids are consumed. However, it does not differentiate itself from the sibling `regions`, leaving real ambiguity about which of the two to call.
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?
Explains what to do with the output (plug ids into regionIds of top_requests/dynamics, use labels to decode responses) and advises fetching once and caching because the tree is large and stable. No exclusion against the `regions` sibling, which is the one missing piece of routing guidance.
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
The pair list_regions and regions is genuinely easy to confuse: one returns a static reference tree of region ids/names, the other returns per-region demand for a phrase. Descriptions do disambiguate once read, but raw_request also overlaps with every other tool by design, giving an agent three plausible paths for some queries.
All names are snake_case, but the grammatical pattern is mixed: verb_noun (list_regions), bare nouns (dynamics, regions), adjective_noun (raw_request), and noun with modifier (top_requests). Readable, yet no predictable verb-first convention an agent can rely on.
Five tools map cleanly onto the Wordstat surface: a reference lookup, two analytical endpoints, a top-queries endpoint, and one escape hatch. Nothing feels padded or missing at this scope.
Core Wordstat capabilities (top requests/associations, dynamics time series, regional breakdown, region dictionary) are all covered, and raw_request guarantees no endpoint is unreachable. The minor gap is that anything outside these four requires hand-building a raw POST with a path and body, rather than a typed tool.
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.