This server acts as an MCP interface for Yandex Wordstat, allowing AI clients to programmatically access search demand statistics, trends, and regional distribution for keywords via the Yandex Cloud Search API v2.
Top & Related Queries: Retrieve the most popular search queries containing a given phrase, plus semantically related queries, with total search volume over the last 30 days. Supports filtering by region and device type.
Demand Dynamics: Get a time-series of search demand for a phrase to analyze seasonality and trends, with daily, weekly, or monthly granularity and customizable date ranges.
Regional Distribution: View how search demand is spread across geographic regions, including an affinity index indicating above- or below-average interest. Supports grouping by cities or regions.
Region Reference Tree: Fetch the full reference tree of Wordstat-supported region IDs and names, useful for filtering and decoding regions in other requests.
Raw API Access: Make direct calls to any Wordstat API endpoint not covered by dedicated tools, with automatic authentication injection.
The server also includes built-in resilience mechanisms such as retries for 429/5xx errors and request timeouts.
Provides tools for querying Yandex Wordstat via the Yandex Cloud Search API v2, enabling AI agents to retrieve search demand statistics such as frequency, similar queries, seasonality, and regional distribution.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Yandex Wordstat MCP Сколько в месяц ищут "купить велосипед"?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Яндекс Вордстат MCP connects an AI application to Yandex search demand statistics. Ask how often a phrase is searched, in which months interest grows, and in which cities the topic is more popular — the assistant will collect Wordstat data and explain the result. The server works through Yandex Cloud Search API, so it does not require access to the Direct advertising account.
Five tools. Top and similar queries, demand dynamics, regional distribution, region reference, and a technical API request.
Read-only. The Wordstat API does not create campaigns, ads, key phrases, or other objects.
Demand and seasonality. Top queries and regions show the last 30 days; dynamics are built by day, week, or month for the desired period.
Region and device. Reports can be narrowed to a region and compare demand on computers, phones, and tablets.
No Direct OAuth. You need an API key and a Yandex Cloud folder ID for Search API.
Start with a safe request:
How many times a month is "buy a bike" searched, and what similar queries are there?
Connect the server · See scenarios · Open technical documentation
Related MCP server: yandex-searchapi-mcp
You need Node.js 20 or newer, a Yandex Cloud API key for Search API, and a Yandex Cloud folder ID.
Get access and add the server to your AI application — instructions for five applications below.
Ask: "How many times a month is 'buy a bike' searched, and what similar queries are there?"
Through the application interface:
Open Settings → Plugins → MCP servers.
Click Add server.
Add the launch command npx -y mcp-yandex-wordstat@latest and environment variables WORDSTAT_API_KEY, WORDSTAT_FOLDER_ID.
Through the command line:
codex mcp add yandex-wordstat \
--env WORDSTAT_API_KEY=ваш_ключ \
--env WORDSTAT_FOLDER_ID=ваш_folder_id \
-- npx -y mcp-yandex-wordstat@latestCheck the connection:
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@latestCheck the server:
claude mcp listOpen Settings → Developer → Edit Config and add the server to claude_desktop_config.json:
{
"mcpServers": {
"yandex-wordstat": {
"command": "npx",
"args": ["-y", "mcp-yandex-wordstat@latest"],
"env": {
"WORDSTAT_API_KEY": "ваш_ключ",
"WORDSTAT_FOLDER_ID": "ваш_folder_id"
}
}
}
}If Edit Config is unavailable, edit ~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows.
For all projects, create ~/.cursor/mcp.json; for the current project only, create .cursor/mcp.json:
{
"mcpServers": {
"yandex-wordstat": {
"command": "npx",
"args": ["-y", "mcp-yandex-wordstat@latest"],
"env": {
"WORDSTAT_API_KEY": "ваш_ключ",
"WORDSTAT_FOLDER_ID": "ваш_folder_id"
}
}
}
}Open the command palette and run MCP: Open User Configuration. Add to 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"
}
]
}Check the launch with the MCP: List Servers command.
"How many times a month is this phrase searched, and what similar queries appear?"
"Find queries around 'pizza delivery' with their frequency."
"Show queries containing my phrase separately from semantically similar ones."
"Show demand for 'skis' by month for a year."
"In which weeks does demand for this service grow or fall?"
"Compare the dynamics of a query on phones and computers."
"In which cities is interest in 'apartment renovation' above average?"
"Compare demand in Moscow and St. Petersburg."
"Find the ID of the needed region and narrow the next report to it."
top_requests shows popular queries that contain the given phrase and semantically close queries. The overall totalCount refers to the last 30 days.
dynamics returns a series {date, count, share} with daily, weekly, or monthly granularity. regions distributes demand over the last 30 days by region, and an affinityIndex above 100% means above-average interest. Counter values may come as strings: Yandex passes large integers in JSON in this form.
One call builds data for only one phrase. For a large list of keywords, it is better to first narrow the list rather than run all queries in a row: the Yandex Cloud Search API quota is shared for one key.
In Yandex Cloud, create a service account with the role search-api.webSearch.user.
Issue an API key for it with the scope yc.search-api.execute — the steps are described in the AI Studio documentation.
Find the folder ID (folderId) in the Yandex Cloud console on the folder page and in the page URL.
Pass the key as WORDSTAT_API_KEY and the folder as WORDSTAT_FOLDER_ID.
The server accesses Yandex Cloud Search API v2. The old separate Wordstat API with OAuth is not used. The API key is stored in plain text in the MCP client configuration — treat it like a password.
Nothing in Яндекс Вордстат. All five tools, including raw_request, work read-only. Technically, the API uses POST, but Wordstat has no write endpoints; the server additionally does not allow an arbitrary request to go to another host.
Aggregated data. The server receives search demand statistics, not data from a specific advertising account.
Region reference cache. In a long-lived process, the region tree is loaded once and reused in subsequent requests.
Retries on temporary errors. The timeout for one request is 60 seconds. The server makes up to three retries after 429, 5xx, a network error, or a timeout; it respects Retry-After, and the delay does not exceed 30 seconds.
No background monitoring. The server works when the AI application calls it. If the application supports scheduled tasks, you can set up a periodic report for selected phrases there.
Anonymous telemetry. By default, the server sends a random installation ID, the event or tool name, server, Node.js, OS, and AI client versions. It does not include the API key, tool arguments, your messages, demand data, or environment variable values. To disable it for Ask Ads MCP servers: ASKADS_TELEMETRY=0.
MCP capabilities catalog — pages on user tasks for each tool.
Found a bug or missing a scenario? Create an issue or write to Telegram.
Returns how demand for a phrase changed over time — a series of {date, count, share}, where share is the fraction of all Yandex searches. Use it for seasonality and trend. period sets the granularity (daily/weekly/monthly). fromDate/toDate bound the range as RFC3339 timestamps, and toDate must align to the period boundary.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | Granularity of the series. Default monthly. | |
| phrase | Yes | The search phrase to research. | |
| toDate | No | Range end (RFC3339), aligned to the period boundary. | |
| devices | No | Device filter: any of all, desktop, phone, tablet. Omit for all devices. | |
| fromDate | No | Range start (RFC3339), e.g. 2026-01-01T00:00:00Z. | |
| regionIds | No | Region ids to scope demand to, e.g. [213] (Moscow), [2] (St. Petersburg). Get ids from list_regions. Omit for all regions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's additional details (e.g., 'share is the fraction of all Yandex searches' and the alignment constraint for toDate) add useful behavioral context without contradicting 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?
The description is two sentences: the first clearly states output and purpose, the second covers parameter constraints. It is front-loaded, concise, and contains no fluff.
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?
Given 6 parameters, no output schema, and high complexity, the description explains the output structure and key parameter constraints. It omits error conditions or empty results, but overall is fairly complete.
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 baseline is 3. The description adds extra meaning by explaining 'share' and the alignment requirement for toDate, improving understanding beyond the schema alone.
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 clearly states the tool returns demand over time with a specific data structure (date, count, share) and explicitly calls out its use for seasonality and trend analysis. This distinguishes it from sibling tools like list_regions or top_requests.
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 description suggests usage for seasonality and trend but does not provide explicit when-to-use or when-not-to-use scenarios or alternatives. However, the purpose is clear enough to infer appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the reference tree of regions Wordstat supports — region ids and their names (label). The ids feed the regionIds/regionMode of the other tools, and the names decode region ids in their responses. The tree is large and stable; fetch it once and cache it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints. Description adds that the tree is large and stable, justifying caching strategy.
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 concise sentences with no waste. First sentence states the core return value, second explains usage, third advises caching.
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 0-parameter, read-only tool with no output schema, the description completely covers the behavior, return content, and caching recommendation.
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?
Tool has 0 parameters, so schema coverage is 100%. Description does not need to add parameter semantics; baseline 4 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?
Clearly states the tool returns the reference tree of regions supported by Wordstat, including IDs and labels. Distinguishes from siblings by specifying it's a reference tree used as input for other tools.
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?
Explicitly instructs to fetch once and cache due to large stable tree. Describes how the output feeds into other tools via regionIds/regionMode, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Escape hatch to call any Yandex Cloud Search API Wordstat path directly, for endpoints without a dedicated tool, e.g. "v2/wordstat/topRequests". Every Wordstat endpoint is POST; body is sent as JSON (folderId is injected automatically).
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | JSON request body. | |
| path | Yes | API path, e.g. "v2/wordstat/dynamics". | |
| method | No | HTTP method. Only POST is supported; defaults to POST. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive. Description adds that folderId is auto-injected and body is sent as JSON, providing useful behavioral context beyond 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?
Two sentences with zero waste. Front-loaded with purpose and includes essential usage details.
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?
Adequately covers purpose, usage, and parameter behavior. Lacks description of the response format, but given it's an escape hatch, this is acceptable.
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%. Description adds that folderId is injected automatically, which is not in the schema, enhancing understanding of the body parameter.
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?
Clearly states it's an escape hatch for endpoints without dedicated tools, with an example path. Distinguishes from sibling tools like dynamics and top_requests.
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?
States it's for endpoints without a dedicated tool and that all endpoints are POST, giving clear context. Lacks explicit when-not-to-use but sufficiently implies usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns how demand for a phrase is distributed across regions over the last 30 days. Each row has the region id, count, share and affinityIndex (>100% = above-average interest in that region, <100% = below). regionMode chooses the grouping: all, cities (only cities) or regions (only oblasts/subjects). Map region ids to names with list_regions.
| Name | Required | Description | Default |
|---|---|---|---|
| phrase | Yes | The search phrase to research. | |
| regionMode | No | Grouping: all (default), cities (only cities), or regions (only subjects/oblasts). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, idempotentHint, destructiveHint) already convey safety and non-destructiveness. The description adds behavioral context beyond annotations: it specifies the data time range (last 30 days), the output fields (count, share, affinityIndex), and explains the meaning of affinityIndex ('>100% = above-average interest, <100% = below'). This is valuable behavioral detail not present in 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?
The description is two sentences long, front-loading the main purpose in the first sentence. Every sentence provides essential information: first the core functionality, second the parameter details and cross-reference to sibling tool. No redundant or extraneous text.
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?
The tool has two parameters (both described), rich annotations, and no output schema. The description explains output fields (count, share, affinityIndex) and provides interpretation of affinityIndex. It references list_regions for name resolution. It does not mention potential pagination or limits, but the fixed 30-day window and single-phrase input make this acceptable for a query tool. Completeness is high for the complexity level.
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 input schema covers both parameters with descriptions (phrase and regionMode enum). The description adds a summary of regionMode ('all, cities, or regions/oblasts') and mentions mapping via list_regions, but this largely repeats schema information. Parameter semantics are adequately handled by the schema, so the description adds minimal extra meaning.
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 begins with 'Returns how demand for a phrase is distributed across regions over the last 30 days,' clearly stating the verb ('returns'), the resource ('demand distribution'), and the scope. It distinguishes itself from sibling tools like list_regions by mentioning how to map region ids to names, and the phrase 'across regions' differentiates it from other analytical tools.
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 description does not explicitly state when to use this tool versus siblings like dynamics or top_requests. It provides some guidance via the regionMode parameter (all, cities, regions) and mentions using list_regions for name mapping, but lacks a clear when-to-use or when-not-to-use statement relative to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns search-demand for a phrase over the last 30 days: the most popular queries that CONTAIN the phrase (results) and semantically RELATED queries that may not contain it (associations), plus totalCount. Use it to discover keywords and gauge demand. Counts can arrive as strings (int64). Optional regionIds and devices narrow the result; numPhrases sets how many to return (1..2000).
| Name | Required | Description | Default |
|---|---|---|---|
| phrase | Yes | The search phrase to research, e.g. «купить велосипед». | |
| devices | No | Device filter: any of all, desktop, phone, tablet. Omit for all devices. | |
| regionIds | No | Region ids to scope demand to, e.g. [213] (Moscow), [2] (St. Petersburg). Get ids from list_regions. Omit for all regions. | |
| numPhrases | No | How many top phrases to return (1..2000; default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint), the description adds crucial behavioral details: the 30-day time window, the fact that counts can arrive as strings (int64), and the optional parameters for narrowing results. This enriches agent understanding beyond safe-operation flags.
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 front-load the core functionality and behavior, with no unnecessary words. Every sentence adds value, making it highly concise and well-structured for quick agent comprehension.
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?
Given the complexity (4 parameters, no output schema), the description explains the two result types, data type nuance for counts, and parameter effects. It could mention result ordering or error handling, but overall covers essential context for effective use.
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 description does not need to compensate. It provides an example for 'phrase' and reiterates parameter roles, but adds little new meaning beyond what's already in the schema's descriptions. Baseline score of 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 clearly states it returns search-demand for a phrase over the last 30 days, specifying two distinct result types (containing phrases and related queries) plus totalCount. It distinguishes itself from sibling tools like 'list_regions' and 'raw_request' by focusing on keyword discovery and demand gauging.
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 description explicitly says 'Use it to discover keywords and gauge demand,' providing a clear context of use. However, it does not mention when to avoid using it or suggest alternatives among siblings, such as when dynamic data is needed instead.
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.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
top_requests, dynamics, regions, and list_regions each map to a distinct analytical dimension: current keyword demand, trend over time, geographic distribution, and the region reference. raw_request is clearly labeled as an escape hatch, so it is unlikely to be confused with the domain tools. No two tools appear to do the same thing.
Tool names are all lower_snake_case and readable, but the convention is mixed: top_requests, dynamics, and regions are noun-style, list_regions uses verb_noun, and raw_request is an adjective_noun escape hatch. This is not chaotic, but it lacks a uniform verb_noun or consistent action-noun pattern.
Five tools is well-scoped for a focused Wordstat analytics server. It provides the essential analytical operations plus a generic passthrough, with no redundancy or obvious bloat.
The server covers the core Wordstat surfaces: query popularity, time dynamics, geographic breakdown, and the region reference needed to interpret results. The raw_request passthrough also allows direct calls to any additional Wordstat endpoint, so there are no dead ends.
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
Read-only Yandex Metrika MCP. Query visits, sources, geo, devices and more in plain language.
Query your SEO data in plain language: rankings, audits, backlinks, competitors and AI visibility.