Yandex Metrica MCP

What the Yandex Metrica MCP MCP server does

Yandex Metrica MCP provides an MCP interface to three areas of the Yandex Metrica platform: counter management, the Reporting API, and the Logs API. It runs locally and communicates with an MCP client over standard input and output. There is no web server, persistent storage layer, or background daemon.

The server includes 13 tools. Counter tools list accessible counters, retrieve counter details, list goals, create counters, and permanently delete counters. The Reporting API tool runs queries against aggregated statistics, including traffic, behavior, and goal-conversion data. It can also compare two periods when a second pair of dates is supplied.

Logs API tools support raw, non-aggregated exports for row-level session or hit analysis. The available operations cover export evaluation, creation, request listing, status polling, part downloads, cancellation, and cleanup. Tool annotations identify read-only and potentially destructive operations.

How it works

The Yandex Metrica MCP MCP server sends requests to Yandex Metrica using an OAuth token supplied through the environment. Responses remain close to the API format, so agents receive the structures returned by Yandex rather than a heavily normalized data model.

Reporting queries are synchronous from the tool caller’s perspective. Logs exports are asynchronous. A typical workflow is:

1. Check whether the requested export can be created.
2. Create the Logs API request.
3. Poll its status until it is processed.
4. Download each available part by its part number.
5. Clean processed files when they are no longer needed.

Downloaded log parts default to a preview with metadata and approximately 50 KB of content. Use full mode only when the part is small enough to fit the client’s response handling, because raw parts may be hundreds of megabytes.

Setup and configuration

Docker is the documented current installation path. Run the published GHCR image with interactive input and pass YANDEX_METRICA_TOKEN into the container. The token must have the metrika:read scope. A versioned image tag can be used when reproducible deployment is important; latest and main are also available.

The server requires Node.js 24 or newer when built and run from source. Source setup consists of cloning the repository, installing dependencies, and building the project. The README states that an npm release has not yet been published, so the scoped package should not currently be invoked through npx.

Optional settings include YANDEX_METRICA_TIMEOUT_MS for request timeouts, LOG_LEVEL for logging verbosity, YANDEX_METRICA_USER_AGENT for a custom user agent, and YANDEX_METRICA_BASE_URL for test environments. A counter ID is needed for live tests, not for normal server startup.

Tools and capabilities

The Yandex Metrica MCP MCP server exposes these capability groups:

• Counter listing, inspection, goal listing, creation, and deletion.
• Aggregated Reporting API queries and period comparisons.
• Logs API evaluation, creation, listing, polling, downloading, cancellation, and cleanup.
• Preview or full retrieval modes for processed log parts.
• MCP annotations that distinguish read-only and destructive actions.

Limitations and notes

Authentication is configured through environment variables rather than interactive OAuth. Creating or deleting counters and managing Logs API exports can change the Metrica account, so agents should distinguish those tools from the eight read-oriented tools.

The Reporting API returns aggregated, sampled statistics, while the Logs API is intended for raw export. The two APIs therefore suit different analysis tasks. Full log downloads can produce very large responses, and the default preview exists to limit the amount returned by a tool call.

The local transport is stdio only. The server does not provide an HTTP endpoint or retain state between runs.