Yandex Wordstat MCP は、AIアプリケーションをYandexの検索需要統計に接続します。フレーズがどのくらい検索されているか、どの月に興味が高まるか、どの都市でテーマが人気かを尋ねると、アシスタントがWordstatのデータを収集して結果を説明します。このサーバーはYandex Cloud Search APIを通じて動作するため、ディレクトの広告アカウントへのアクセスは不要です。
5つのツール。 トップおよび類似クエリ、需要の推移、地域別分布、地域ディレクトリ、APIへの技術リクエスト。
読み取り専用。 Wordstat APIはキャンペーン、広告、キーフレーズなどのオブジェクトを作成しません。
需要と季節性。 トップクエリと地域は直近30日間を表示します。推移は日次、週次、月次のいずれかで任意の期間にわたって構築されます。
地域とデバイス。 レポートを地域に絞り込み、パソコン、スマートフォン、タブレットの需要を比較できます。
ディレクトのOAuthは不要。 Search APIにはYandex CloudのAPIキーとカタログIDが必要です。
安全なリクエストから始めましょう：
「自転車を買う」は月にどのくらい検索され、類似クエリにはどのようなものがありますか？
サーバーを接続する · シナリオを見る · 技術ドキュメントを開く
Related MCP server: Wordstat MCP
必要なもの：Node.js 20以上、Search API用のYandex Cloud APIキー、Yandex CloudカタログID。
アクセスを取得し、AIアプリケーションにサーバーを追加します — 以下の5つのアプリケーションの手順を参照してください。
「「自転車を買う」は月にどのくらい検索され、類似クエリにはどのようなものがありますか？」と尋ねます。
アプリケーションのインターフェースから：
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 listSettings → 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 が利用できない場合は、macOSでは ~/Library/Application Support/Claude/claude_desktop_config.json、Windowsでは %APPDATA%\Claude\claude_desktop_config.json を編集します。
すべてのプロジェクトには ~/.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 コマンドで起動を確認します。
「このフレーズは月に何回検索され、類似クエリにはどのようなものがありますか？」
「「ピザ配達」に関連するクエリを頻度付きで選んでください。」
「私のフレーズを含むクエリと、意味的に類似したクエリを分けて表示してください。」
「「スキー」の需要を1年分、月別に表示してください。」
「このサービスの需要はどの週に増減しますか？」
「スマートフォンとパソコンでのクエリの推移を比較してください。」
「「マンションリフォーム」への関心が平均より高い都市はどこですか？」
「モスクワとサンクトペテルブルクの需要を比較してください。」
「必要な地域のIDを見つけて、次のレポートをその地域に絞り込んでください。」
top_requests は、指定したフレーズを含む人気クエリと、意味的に近いクエリを表示します。全体の totalCount は直近30日間を対象としています。
dynamics は、日次、週次、月次の粒度で {date, count, share} の系列を返します。regions は直近30日間の需要を地域別に分配し、affinityIndex が100%を超えると平均以上の関心を意味します。カウンターの値は文字列で返されることがあります。Yandexは大きな整数をJSONでこの形式で送信するためです。
1回の呼び出しで構築されるデータは1つのフレーズのみです。キーワードのリストが大きい場合は、すべてのクエリを連続して実行するのではなく、まずリストを絞り込むことをお勧めします。Yandex Cloud Search APIの割り当ては1つのキーで共有されるためです。
Yandex Cloudで、search-api.webSearch.user ロールを持つサービスアカウントを作成します。
そのアカウントに対して、スコープ yc.search-api.execute のAPIキーを発行します — 手順は AI Studioドキュメント に記載されています。
Yandex Cloudコンソール のカタログページとページURLでカタログID（folderId）を確認します。
キーを WORDSTAT_API_KEY として、カタログを WORDSTAT_FOLDER_ID として渡します。
サーバーはYandex Cloud Search API v2にアクセスします。OAuthを使用する旧来の独立したWordstat APIは使用されません。APIキーはMCPクライアントの設定に平文で保存されるため、パスワードと同様に扱ってください。
Yandex Wordstatでは何も変更できません。raw_request を含む5つのツールはすべて読み取り専用で動作します。技術的にはAPIは POST を使用しますが、Wordstatには書き込み用のエンドポイントはありません。また、サーバーは任意のリクエストが別のホストに送信されることを追加で防ぎます。
集計データ。 サーバーは特定の広告アカウントのデータではなく、検索需要の統計を取得します。
地域ディレクトリのキャッシュ。 長時間稼働するプロセスでは、地域ツリーは一度だけ読み込まれ、以降のリクエストで再利用されます。
一時的なエラー時の再試行。 1回のリクエストのタイムアウトは60秒です。サーバーは 429、5xx、ネットワークエラー、タイムアウトの後に最大3回再試行します。Retry-After を考慮し、遅延は30秒を超えません。
バックグラウンド監視なし。 サーバーはAIアプリケーションが呼び出したときに動作します。アプリケーションがスケジュールジョブをサポートしている場合は、選択したフレーズの定期レポートを設定できます。
匿名テレメトリ。 デフォルトで、サーバーはランダムなインストールID、イベント名またはツール名、サーバー、Node.js、OS、AIクライアントのバージョンを送信します。APIキー、ツールの引数、メッセージ、需要データ、環境変数の値は含まれません。Ask AdsのMCPサーバーで無効にするには：ASKADS_TELEMETRY=0。
MCP機能カタログ — 各ツールのユーザータスク別ページ。
Возвращает, как менялся спрос на фразу во времени, — ряд {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.