yandex-metrica-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| YANDEX_METRICA_TOKEN | Yes | Yandex Metrica OAuth token |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| yandex_metrica_list_countersA | List Yandex Metrica counters the configured token can access, with each counter id, name, and site. Use when the user needs a counter id before any other query. Do not use this to read one counter's settings; call yandex_metrica_get_counter once the id is known. |
| yandex_metrica_get_counterA | Get one Yandex Metrica counter by id, including its settings, status, owner, timezone, and site. Use when the user already has a counter id and wants that counter's configuration. Do not use this to discover unknown ids; call yandex_metrica_list_counters instead. |
| yandex_metrica_list_goalsA | List conversion goals configured on one Yandex Metrica counter, including each goal id and type. Use when the user asks which goals exist on a counter before building a report. Do not use this for conversion counts or rates; call yandex_metrica_get_report with the goal metrics. |
| yandex_metrica_get_reportA | Run a Yandex Metrica Reporting API query and return aggregated statistics such as visits, users, bounce rate, and traffic sources. Use when the user wants a summary, a breakdown, or a comparison of two periods via date1_b and date2_b. Do not use this for row-level visits or pageviews; call yandex_metrica_evaluate_logs_request and the other Logs API tools. Metrics use the ym:s: prefix for visits and ym:pv: for hits. |
| yandex_metrica_evaluate_logs_requestA | Check whether a Yandex Metrica Logs API export can be created for the given dates, source, and fields, without creating a request. Use when the user wants to know if a raw export is possible and how many days fit the quota. Do not use this to start the export; call yandex_metrica_create_logs_request after the check succeeds. |
| yandex_metrica_create_logs_requestA | Create an asynchronous Yandex Metrica Logs API export of raw visits or hits for one counter and date range. Use when the user wants row-level data and yandex_metrica_evaluate_logs_request has shown the export is possible. Do not use this only to test feasibility, and do not use it for aggregated totals; call yandex_metrica_get_report for those. Poll yandex_metrica_get_logs_request until the status is processed. date2 cannot be today. Fields use the ym:s: prefix for visits and ym:pv: for hits. |
| yandex_metrica_list_logs_requestsA | List every Logs API export request on a Yandex Metrica counter, in any status from created through cleaned. Use when the user wants to see existing exports or find a request id. Do not use this to poll a single request; call yandex_metrica_get_logs_request with that request id. |
| yandex_metrica_get_logs_requestA | Get the status and prepared parts of one Yandex Metrica Logs API export request. Use when the user is waiting for a created export to reach processed before downloading it. Do not use this to fetch the TSV rows; call yandex_metrica_download_logs_part once the status is processed. Do not use it to list every request; call yandex_metrica_list_logs_requests. |
| yandex_metrica_download_logs_partA | Download one processed part of a Yandex Metrica Logs API export as TSV text. Use when the user wants the rows of a request whose status is already processed. Do not use this to check whether the export is ready; call yandex_metrica_get_logs_request first. Preview mode returns about the first 50KB; full mode is only for small parts under 10MB. Part numbers come from the parts list returned by yandex_metrica_get_logs_request and start at 0. |
| yandex_metrica_cancel_logs_requestA | Cancel a Yandex Metrica Logs API export that is still pending, in status created or awaiting_retry. Use when the user wants to stop an export that has not been processed yet. Do not use this on a processed request; call yandex_metrica_clean_logs_request to delete the prepared files. |
| yandex_metrica_clean_logs_requestA | Delete the prepared files of a processed Yandex Metrica Logs API export and free the export quota. Use when the user has finished downloading and the request status is processed. Do not use this to stop a request that is still pending; call yandex_metrica_cancel_logs_request instead. |
| yandex_metrica_create_counterA | Create a new Yandex Metrica counter for a site and return its id and tracking code. Use when the user asks to add a website or start tracking a new property. Do not use this to find a counter that already exists; call yandex_metrica_list_counters or yandex_metrica_get_counter. |
| yandex_metrica_delete_counterA | Delete one Yandex Metrica counter; it stops collecting data and its statistics are no longer available through the API. Use when the user explicitly asks to remove a counter and has confirmed the deletion. Do not use this to inspect a counter; call yandex_metrica_get_counter instead. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Each tool has a clearly distinct purpose, with explicit cross-references in descriptions (e.g., 'Do not use this... call X instead') that prevent misselection. The split between aggregated reports, logs export lifecycle, and counter management is unambiguous.
All tools follow a consistent yandex_metrica_ prefix and verb_noun pattern (list_counters, get_counter, create_logs_request, download_logs_part, etc.). No mixing of conventions or styles.
13 tools is well within the ideal 3-15 range and each tool maps to a distinct API operation or step in a workflow. The logs export lifecycle is fully broken out without redundancy.
Core workflows (counter listing/retrieval/creation/deletion, reporting, full logs export lifecycle) are covered. Minor gaps exist, such as no counter update/settings modification and only goal listing without goal management, but these are not critical for typical agent tasks.