Yandex Metrica MCP

Статистика

get_statistics

Read-onlyIdempotent

Fetch web analytics metrics from Yandex Metrica for a counter, with options for dimensions, metrics, filters, and pagination. Get totals and handle sampling for accurate data.

Instructions

Запрашивает Reporting API Яндекс Метрики (stat/v1/data) по счётчику. ПО УМОЛЧАНИЮ возвращает одну строку, агрегированную за период (без измерений), с visits/users/pageviews/bounceRate/avgVisitDurationSeconds. dimensions разбивает результат на строки (ym:s:date — динамика по дням, ym:s:lastTrafficSource — источники трафика, ym:s:deviceCategory — устройства), metrics задаёт нужные метрики — для конверсий это ym:s:goalreaches / ym:s:goalconversionRate (идентификаторы целей даёт list_goals). В ответе есть totals (итог по ВСЕМ строкам — для вопросов «сколько всего» суммировать не нужно), total_rows и sampled/sample_share (sampled=true означает, что данные приблизительные; для точных цифр нужно сузить период или передать accuracy=full). Если counterId не передан, берётся YANDEX_METRIKA_COUNTER_ID.

Input Schema

TableJSON Schema

Name	Required	Description
`sort`	No	Поле сортировки; префикс '-' — по убыванию, например -ym:s:visits.
`date1`	No	Дата начала: YYYY-MM-DD или относительная (today, yesterday, NdaysAgo). По умолчанию 7daysAgo.
`date2`	No	Дата конца: YYYY-MM-DD или относительная (today, yesterday, NdaysAgo). По умолчанию yesterday.
`limit`	No	Максимум строк на странице (игнорируется, если задан autoPaginate).
`offset`	No	Смещение по строкам для постраничной выдачи, отсчёт с 1.
`filters`	No	Выражение фильтра Метрики, например ym:s:deviceCategory=='mobile'.
`metrics`	No	Метрики, например ym:s:visits, ym:s:users, ym:s:bounceRate, ym:s:goal<id>reaches. По умолчанию — типовой набор.
`accuracy`	No	Точность сэмплирования: 'full' — точный расчёт (медленнее) или доля 0..1. По умолчанию — авторежим API.
`maxPages`	No	Лимит страниц для autoPaginate. По умолчанию 100.
`counterId`	No	Идентификатор счётчика. По умолчанию YANDEX_METRIKA_COUNTER_ID.
`dimensions`	No	Измерения для группировки, например ym:s:date, ym:s:lastTrafficSource, ym:s:deviceCategory. Без них — итог за период.
`autoPaginate`	No	Забирает все строки, листая страницами максимального для API размера (склеивает data, сохраняет totals). Игнорирует `limit`; ограничен maxPages и лимитами по строкам/байтам (при их достижении выставляет _truncated).

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv1.4.1Aug 21, 2026

changedInput schema / properties / accuracy / description

Previous value: -"Sampling accuracy: 'full' for exact (slower), or a 0..1 share. Default the API's auto."New value: +"Точность сэмплирования: 'full' — точный расчёт (медленнее) или доля 0..1. По умолчанию — авторежим API."

changedInput schema / properties / autoPaginate / description

Previous value: -"Fetch all rows by following the API-max page size (merges data, carries totals). Ignores `limit`; capped by maxPages and by row/byte limits (flags _truncated when hit)."New value: +"Забирает все строки, листая страницами максимального для API размера (склеивает data, сохраняет totals). Игнорирует `limit`; ограничен maxPages и лимитами по строкам/байтам (при их достижении выставляет _truncated)."

changedInput schema / properties / counterId / description

Previous value: -"Counter id. Defaults to YANDEX_METRIKA_COUNTER_ID."New value: +"Идентификатор счётчика. По умолчанию YANDEX_METRIKA_COUNTER_ID."

changedInput schema / properties / date1 / description

Previous value: -"Start date YYYY-MM-DD or relative (today, yesterday, NdaysAgo). Default 7daysAgo."New value: +"Дата начала: YYYY-MM-DD или относительная (today, yesterday, NdaysAgo). По умолчанию 7daysAgo."

changedInput schema / properties / date2 / description

Previous value: -"End date YYYY-MM-DD or relative (today, yesterday, NdaysAgo). Default yesterday."New value: +"Дата конца: YYYY-MM-DD или относительная (today, yesterday, NdaysAgo). По умолчанию yesterday."

changedInput schema / properties / dimensions / description

Previous value: -"Group-by dimensions, e.g. ym:s:date, ym:s:lastTrafficSource, ym:s:deviceCategory. Omit for a period total."New value: +"Измерения для группировки, например ym:s:date, ym:s:lastTrafficSource, ym:s:deviceCategory. Без них — итог за период."

changedInput schema / properties / filters / description

Previous value: -"Metrica filter expression, e.g. ym:s:deviceCategory=='mobile'."New value: +"Выражение фильтра Метрики, например ym:s:deviceCategory=='mobile'."

changedInput schema / properties / limit / description

Previous value: -"Max rows per page (ignored when autoPaginate is set)."New value: +"Максимум строк на странице (игнорируется, если задан autoPaginate)."

changedInput schema / properties / maxPages / description

Previous value: -"Page cap for autoPaginate. Default 100."New value: +"Лимит страниц для autoPaginate. По умолчанию 100."

changedInput schema / properties / metrics / description

Previous value: -"Metrics, e.g. ym:s:visits, ym:s:users, ym:s:bounceRate, ym:s:goal<id>reaches. Defaults to a common set."New value: +"Метрики, например ym:s:visits, ym:s:users, ym:s:bounceRate, ym:s:goal<id>reaches. По умолчанию — типовой набор."

changedInput schema / properties / offset / description

Previous value: -"1-based row offset for pagination."New value: +"Смещение по строкам для постраничной выдачи, отсчёт с 1."

changedInput schema / properties / sort / description

Previous value: -"Sort field; prefix with '-' for descending, e.g. -ym:s:visits."New value: +"Поле сортировки; префикс '-' — по убыванию, например -ym:s:visits."

Changed11 schema fields changedv1.0.2Jul 7, 2026

addedInput schema / properties / accuracy / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "maximum": 1,
+    "minimum": 0,
+    "type": "number"
+  }
+]

changedInput schema / properties / accuracy / description

Previous value: -"Sampling accuracy: 'full' for exact (slower), or 0..1. Default the API's auto."New value: +"Sampling accuracy: 'full' for exact (slower), or a 0..1 share. Default the API's auto."

removedInput schema / properties / accuracy / type
```
Removed value: -"string"
```

changedInput schema / properties / autoPaginate / description

Previous value: -"Fetch all rows by following limit/offset (merges data, carries totals)."New value: +"Fetch all rows by following the API-max page size (merges data, carries totals). Ignores `limit`; capped by maxPages and by row/byte limits (flags _truncated when hit)."

removedInput schema / properties / date2 / $ref
```
Removed value: -"#/properties/date1"
```

changedInput schema / properties / date2 / description

Previous value: -"End date YYYY-MM-DD or relative. Default yesterday."New value: +"End date YYYY-MM-DD or relative (today, yesterday, NdaysAgo). Default yesterday."

addedInput schema / properties / date2 / pattern

Added value: +"^(\\d{4}-\\d{2}-\\d{2}|today|yesterday|\\d+daysAgo)$"

addedInput schema / properties / date2 / type
```
Added value: +"string"
```

changedInput schema / properties / limit / description

Previous value: -"Max rows per page."New value: +"Max rows per page (ignored when autoPaginate is set)."

changedInput schema / properties / limit / maximum
```
Previous value: -100000New value: +10000
```

addedInput schema / properties / maxPages

Added value: +{
+  "description": "Page cap for autoPaginate. Default 100.",
+  "maximum": 1000,
+  "minimum": 1,
+  "type": "integer"
+}

First observedv1.0.0Jun 27, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already mark it as read-only, idempotent, and non-destructive. The description adds valuable behavioral context: default returns a single aggregated row, totals field should not be summed, sampling with sample/accuracy behavior, autoPaginate semantics, and default counter/env variable fallback. This goes well beyond the structured annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense paragraph, but it is logically organized: purpose, default behavior, dimensions/metrics, response semantics, then default counter. Though long, it avoids waste and includes practical notes (autoPaginate, sampling). Loses a point for lack of bullet points or clear sections.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers default values (date range, limit, counter), response structure (totals, pagination), and sampling behavior. Missing explicit error cases or output schema, but annotations and parameter descriptions cover most operational needs. It's solid for an API wrapper.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all parameters with descriptions, but the tool description adds crucial usage context: date formats and relatives, goal ID format (from get_goals), explanation of autoPaginate, and the meaning of `–` prefix for sort. This materially helps an agent set parameters correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Сообщается конкретный глагол + ресурс:

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions that goal IDs come from get_goals, implying a relationship, and states defaults for date range and counter ID allocations. However, it does not explicitly state when to prefer this tool over get_analytics, get_visits, or raw_request, nor does it state when not to use it.

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

Deploy Server

Статистика

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools