yandex-metrika-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| YANDEX_METRIKA_TOKEN | Yes | Your Yandex Metrika OAuth token with metrika:read scope |
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
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_countersA | List Yandex Metrika counters available to the token. Returns each counter's id, name and site so you can pick a |
| queryA | Run a Reporting API query against a Metrika counter (aggregated stats). Pass Metrika field names directly. Common ones: Metrics (comma-separated): ym:s:visits, ym:s:users, ym:s:pageviews, ym:s:bounceRate, ym:s:avgVisitDurationSeconds, ym:s:newUsers Dimensions (comma-separated, optional — groups the result): ym:s:date, ym:s:lastTrafficSource, ym:s:startURL, ym:s:deviceCategory, ym:s:regionCountry, ym:s:UTMSource date1 / date2: YYYY-MM-DD or relative (today, yesterday, NdaysAgo). filters: Metrika filter expression, e.g. "ym:s:deviceCategory=='mobile'". sort: field to sort by; prefix with '-' for descending, e.g. "-ym:s:visits". Returns the raw Reporting API response (query meta, totals and data rows). |
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 2 tools
The two tools have clearly non-overlapping purposes: one discovers available counters, the other runs queries against a specific counter. An agent can easily choose the right tool.
list_counters follows a verb_noun pattern while query is a bare verb, which is a minor inconsistency. However, both are concise and readable, and the query description clarifies its role.
With only two tools, the server is minimal but not unreasonable for a read-only analytics API wrapper. It is serviceable yet feels slightly thin compared to more complete analytics integrations.
The pair covers the core workflow: list counters to obtain an ID, then query reporting data from that counter. Missing capabilities like retrieving counter metadata or metadata schemas are minor gaps for this read-only domain.