
Yandex Metrica MCP
io.github.stufentlyPublished by GitHub account stufentlyv0.2.3Updated Oct 26, 2026
Yandex Metrica for AI agents: counters, goals, Reporting API and Logs API export over stdio.
Overview
Local stdio MCP server for Yandex Metrica: list counters and goals, run Reporting API queries, and export raw Logs API data.
- What you can do
- List counters and goals, and read counter details
- Run Reporting API queries, including two-period comparisons
- Manage counters: create a new counter or delete one permanently
- Run the Logs API export lifecycle: evaluate, create, poll status, download TSV parts, cancel and clean
- When to use it
- Useful when an assistant should answer questions about Yandex Metrica traffic, sources, behavior metrics and goal conversions, or pull row-level session and hit data for a custom analytics pipeline.
- Requirements
- Runs locally over stdio, normally as the published Docker image (Node.js 24+ if built from source). Needs a Yandex OAuth token with the metrika:read scope in YANDEX_METRICA_TOKEN; counter create/delete additionally need metrika:write. Network access to the Yandex Metrica API. Optional variables set timeout, log level, user agent and base URL.
Installation
In SourceWeft
- Open Yandex Metrica MCP in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
yandex-metrica-mcp
MCP server for the Yandex Metrica Reporting API, Logs API and counter management, designed for use with Claude Code and Codex CLI. Eight of its 13 tools only read; five change your Metrica account — create and delete a counter, and create, cancel and clean a Logs API export. Each tool says which it is in its MCP annotations (readOnlyHint, destructiveHint).
Runs locally over stdio. No web server, no persistent storage, no background daemons.
Why this project exists
Yandex Metrica has two distinct APIs that serve different purposes:
- Reporting API (
/stat/v1/data) — aggregated, sampled statistics. Use this to build reports, query traffic sources, behavior metrics, goal conversions, etc. - Logs API (
/management/v1/counter/{id}/logrequests) — raw, non-aggregated event export. Use this when you need row-level session or hit data for custom analytics pipelines.
This MCP server exposes both APIs as named tools that an LLM can call directly.
Features
- 13 MCP tools covering counter management, goals, reporting, and full Logs API lifecycle
- Authentication via environment variable only (no interactive OAuth)
- Minimal transformation — responses stay close to the Yandex API format
- Safe download behavior: logs parts default to 50KB preview + metadata
- Strict TypeScript, zod validation, clean error messages
- Multi-stage Docker image (node:24-alpine)
- Unit + mock integration tests, live test scaffolding
- GitHub Actions CI and Docker workflows
Supported MCP Tools
Counter Management
Reporting API (aggregated)
For period comparison, pass
date1_b/date2_btoyandex_metrica_get_report. The tool automatically routes to/stat/v1/data/comparison;date1/date2become segment A,date1_b/date2_bbecome segment B. Each result row returnsmetrics: { a, b }.
Logs API (raw export)
Logs API Workflow
The Logs API is asynchronous. After creating a request, poll yandex_metrica_get_logs_request until status = "processed", then download each part listed in log_request.parts (by its part_number).
Download Behavior
Raw log parts can be hundreds of MB. By default yandex_metrica_download_logs_part returns:
Set mode: "full" to get the entire content — only do this for small parts.
Requirements
- Node.js 24+
- Yandex OAuth token with
metrika:readscope
How to get YANDEX_METRICA_TOKEN
- Go to https://oauth.yandex.com/ → Create app
- Fill in any name, select For API access
- Under Access → enable
metrika:read - Click Create app, copy the ClientID
- Open in browser (replace
<ClientID>with yours): - Authorize → copy the
access_tokenfrom the URL fragment (#access_token=...)
How to get YANDEX_METRICA_COUNTER_ID
The counter ID is the numeric ID of your Yandex Metrica tag (счётчик):
- Open https://metrika.yandex.ru — the counter ID is shown next to each tag
- Or look at the URL:
metrika.yandex.ru/dashboard?id=**12345678** - Or use the tool itself: call
yandex_metrica_list_counters— it returns all counters with their IDs
YANDEX_METRICA_COUNTER_IDis only needed for live tests (npm run test:live), not for normal server operation.
Installation
One path that works today: Docker. Nothing to clone, no Node.js. Every MCP client below starts the server with this same command.
-e YANDEX_METRICA_TOKEN without a value forwards the variable from the client's
environment into the container, so the token lives in the client's env block and never
appears in the docker command line or ps output. The client pulls the image on
first start; docker pull ghcr.io/stufently/yandex-metrica-mcp:latest up front just
makes that first start faster.
Smoke test without a token or network — the server must answer initialize and list
13 tools. The image ships a placeholder YANDEX_METRICA_TOKEN so it starts for
introspection; tool calls with it return a "YANDEX_METRICA_TOKEN is not set" error
instead of reaching Yandex:
Image tags on GHCR: latest and main (every push to main), sha-<short>, and
X.Y.Z / X.Y / X on version tags. Pin a version tag (:0.2.3) for reproducible setups.
npm (not published yet)
The package is scoped — both unscoped names (yandex-metrica-mcp and the project's
former name mcp-yandex-metrica) belong to unrelated projects on npm — so it ships as
@stufently/yandex-metrica-mcp (command yandex-metrica-mcp). The first npm release
has not been cut, so npx -y @stufently/yandex-metrica-mcp does not work today. Use
Docker.
From source
See Running from a local build for the client config.
Configuration
Copy .env.example to .env and set your token:
Local Development
Docker
Docker Compose
Verified clients and platforms
Only what has actually been run is listed as verified. Everything else in Client Configuration is a documented config that nobody has checked end to end.
Client Configuration
All configs below are copy-paste ready and use the Docker command from
Installation. Replace your_oauth_token_here with your Yandex OAuth
token and nothing else.
Claude Code
Project file: .mcp.json in the project root.
Add --scope user to make it available in every project, or --scope project to write
.mcp.json. Check with claude mcp list / claude mcp get yandex-metrica.
The same server as JSON in .mcp.json:
Claude Desktop
Config file claude_desktop_config.json: macOS
~/Library/Application Support/Claude/, Windows %APPDATA%\Claude\, Linux
~/.config/Claude/. Restart the app after saving.
Claude Desktop can also install this server in one click from a .mcpb file. Releases
up to v0.2.0 do not include one yet; the bundle is attached starting with the next
tagged release at https://github.com/stufently/yandex-metrica-mcp/releases/latest.
Until then, build it locally with bash scripts/build-mcpb.sh (needs Docker) and open
dist-mcpb/yandex-metrica-mcp-<version>.mcpb.
Releases include checksums.txt with the SHA256 checksum of each .mcpb bundle.
Download it alongside the bundle and verify before installing:
Releases from the next tag on also carry a GitHub build provenance attestation for each
.mcpb, signed in the release workflow. Check that a bundle was built by this
repository's workflow and not swapped afterwards (needs the GitHub CLI):
Cursor
[Add yandex-metrica MCP server to Cursor]
After installing, put your token in place of your_oauth_token_here in ~/.cursor/mcp.json. Or add the block below by hand.
~/.cursor/mcp.json for every project, or .cursor/mcp.json for one project.
Windsurf
File mcp_config.json. On macOS and Linux:
~/.config/devin/mcp_config.json (or $XDG_CONFIG_HOME/devin/mcp_config.json). On
Windows: %APPDATA%\devin\mcp_config.json. Older builds used
~/.codeium/windsurf/mcp_config.json.
Codex CLI
Or by hand in ~/.codex/config.toml (shared by the Codex CLI, IDE extension and desktop app):
Zed
Zed's settings.json (zed: open settings file), under context_servers:
Running from a local build instead of Docker
Works in any client above — swap command/args for:
In Claude Code the same thing via CLI:
Example prompts
- Why did my site lose visits last week?
- Which traffic sources sent the most visits last month?
- What goals are configured on my main counter?
- Compare this month's visits with the same month last year.
- Export raw visits for the first week of January and show a preview.
Common prompts
Once the server is registered, ask in plain language — the client picks the tool.
List what you have access to → yandex_metrica_list_counters
Traffic report over a period → yandex_metrica_get_report
Top traffic sources → yandex_metrica_get_report
Compare two periods → yandex_metrica_get_report with date1_b/date2_b
Goal conversions → yandex_metrica_list_goals + yandex_metrica_get_report
Raw event export → the Logs API chain (evaluate → create → get → download_part → clean)
Architecture
Limitations
- Not read-only — 8 tools read; 5 write: counter create/delete and the Logs API export lifecycle (create, cancel, clean)
- No comparison report tool — use
yandex_metrica_get_reportwithdate1_b/date2_bparams - No drilldown/pivot/bytime tools in v1 — planned for v0.2
- No caching — every tool call hits the Yandex API
- Large log parts — use
mode: "full"carefully; defaults to 50KB preview - Retry with exponential backoff is built-in (3 retries, statuses 429/500/502/503/504)
Testing
CI / Docker Image
GitHub Actions workflows are in .github/workflows/:
ci.yml— lint, typecheck, test, build on every push/PRdocker.yml— build Docker image; push to GHCR on pushes tomainand version tags; on avX.Y.Ztag, also publishserver.jsonto the official MCP Registry asio.github.stufently/yandex-metrica-mcp(GitHub OIDC, no stored secret)mcpb.yml— on avX.Y.Ztag, build the.mcpbDesktop extension and attach it to that GitHub Release. It does not publish to GHCR, npm, PyPI, or the MCP registry.
Image tags produced by docker.yml:
REGISTRY and IMAGE_NAME default to ghcr.io and ${{ github.repository }}.
Security
- Token is passed via environment variable only — never hardcoded
- Token never appears in logs
- Counter create/delete requires
metrika:writescope; all other tools use read-only access - Docker image runs as non-root (
nodeuser)
License
MIT — see LICENSE
Source: README.md at commit dfa9d7a
Tools
0Version history
3- v0.2.3LatestOct 14, 2026
- v0.2.2Oct 10, 2026
- v0.2.1Oct 9, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts