AppMetrica MCP lets an AI agent query AppMetrica analytics, export raw logs, inspect apps/metrics/push campaigns, and create push campaigns when write mode is enabled; the README also documents funnel, segment, dashboard/workspace, and experimental web-session tools.
List and get applications and app details.
Run aggregated reports by metrics, dimensions, date range, limit, and drilldown into parent dimension values.
Browse the metric/dimension catalogue with known traps and namespace grammar.
Export raw Logs API data for events, crashes, and installations, with date, field, event-name filtering and async polling.
List push campaigns with status filters, get campaign stats, and create push campaigns if APPMETRICA_ALLOW_WRITE=true.
Read-only by default; write operations are disabled unless explicitly enabled.
README-documented extras include time series, funnels, segments, event audit, dashboards/workspaces, 13 Logs API tables, Management API status, and experimental web_* workspace tools.
Rate limits: 30 requests/sec and 5,000 requests/day per OAuth token.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@appmetrica-mcp List my AppMetrica applications"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for AppMetrica — Yandex's mobile analytics platform. Gives Claude direct access to your app's analytics: reports, funnels, dashboards, raw event logs, crash data, and push notification campaigns — and can create funnels and segments in AppMetrica itself.
Update 0.3.0 (October 2026). The server now builds analytics in AppMetrica, not only reads it: saved funnels and segments through the Management API, and real workspaces/dashboards through an experimental logged-in Chrome session (
web_*tools, one-timenpx appmetrica-mcp login). Also new: time series (get_report_bytime), a docs-derived catalogue of 197 metrics, all 13 Logs API tables,audit_eventsand theanalytics_setupworkflow prompt. Full list in CHANGELOG.md.
AppMetrica keeps mobile product analytics (users, sessions, events, funnels, retention, revenue, crashes) behind a web UI and several HTTP APIs. This MCP server puts all of it behind one set of tools, so an AI agent such as Claude can answer and act on questions like:
"How did DAU, new users and crash-free sessions change this week?"
"Build a funnel from first launch to purchase and save it in AppMetrica."
"Which events does the app send, which ones are dead, and what is missing for a registration funnel?"
"Create a workspace with audience, revenue and funnel widgets for the marketing team."
"Export raw purchase events for September and compare countries."
It works with Claude Code, Claude Desktop and any other MCP client, and is listed in the official MCP Registry as io.github.pavellunev/appmetrica-mcp.
Related MCP server: ya-metrics-mcp
Reporting API — aggregated metrics (users, sessions, revenue, crashes, events, ...) with dimension breakdowns, time series (bytime), filters, sorting and sampling control
Funnels — step-by-step funnel reports for saved web-UI funnels or ad-hoc steps, with absolute/relative conversion; create, update and delete saved funnels
Dashboards & Workspaces — preset or custom widget sets computed from the Reporting API; named widget sets saved locally as workspaces
Web session (experimental) — create and manage real AppMetrica workspaces (dashboards) and widgets through a logged-in headless Chrome session (web_* tools; the public API cannot do this)
Segments — list saved segments and apply them to any report via segment_id; create, update and delete segments
Event audit — audit_events compares registered events with real volumes and reports instrumentation gaps
Workflow prompt — analytics_setup walks an agent through analysing an app, building funnels/segments/dashboards and listing instrumentation gaps
Logs API — raw exports for all 13 tables (events, crashes, errors, installations, sessions, deeplinks, postbacks, clicks, push tokens, profiles, revenue, e-commerce, ad revenue)
Management API — applications, event names, conversions, Logs API status
Push API — view campaigns and statistics; create campaigns when write mode is enabled
Safe by default — write operations (push campaigns, funnels, segments) are disabled unless you explicitly opt in
Node.js 22+
An AppMetrica account with at least one application
A Yandex OAuth token (see below)
Optional, only for the experimental web_* tools: Google Chrome and a one-time npx appmetrica-mcp login (see Web session)
npx appmetrica-mcp authThe wizard opens a Chrome window on the Yandex consent page (the same Chrome profile the web-session tools use, so after the first time you are already logged in), you click Разрешить, and the wizard takes the confirmation code from the page URL itself — nothing to copy. The token is saved to ~/.config/appmetrica-mcp/credentials.json (mode 0600; Yandex tokens live about a year, after that just run auth again) and the server picks it up automatically — no APPMETRICA_OAUTH_TOKEN needed. At the end the wizard offers to log in to the AppMetrica web session as well (only needed for the web_* workspace tools).
Details:
Standard OAuth 2.0 authorization-code flow with PKCE against the bundled public appmetrica-mcp OAuth app; no client secret is involved.
Needs Google Chrome (or APPMETRICA_BROWSER_PATH / APPMETRICA_BROWSER_CHANNEL). Without it, or over SSH, use npx appmetrica-mcp auth --manual: your default browser opens the same page, Yandex shows the code and you paste it into the terminal.
Your own Yandex OAuth app instead of the bundled one: set APPMETRICA_OAUTH_CLIENT_ID (Redirect URI https://oauth.yandex.ru/verification_code, AppMetrica read/write access). If that app also registers http://127.0.0.1:8742/callback, --loopback runs a local callback server instead of Chrome (APPMETRICA_OAUTH_PORT changes the port).
The MCP server itself never opens a browser: if no token is found, tools answer with a short "run npx appmetrica-mcp auth" message.
Use the Russian OAuth portal (oauth.yandex.ru) — the international version (oauth.yandex.com) does not expose AppMetrica scopes in its UI.
Go to oauth.yandex.ru/client/new, name the app, choose Web services and set the Callback URI to https://oauth.yandex.ru/verification_code.
Under Доступы (Access) → AppMetrica enable Чтение данных AppMetrica (required) and Запись данных AppMetrica (optional, for write tools). Copy the ClientID.
Open https://oauth.yandex.ru/authorize?response_type=token&client_id=CLIENT_ID, log in, authorize, copy access_token from the redirect URL and pass it as APPMETRICA_OAUTH_TOKEN.
Tokens do not expire by default; revoke them anytime at passport.yandex.ru/profile/access. An env token always wins over the saved credentials file.
claude mcp add appmetrica -- npx -y appmetrica-mcp
npx appmetrica-mcp auth # one-time browser login (or pass -e APPMETRICA_OAUTH_TOKEN=... instead)To enable write operations (push campaigns, creating/updating/deleting funnels and segments):
claude mcp add appmetrica \
-e APPMETRICA_ALLOW_WRITE=true \
-- npx -y appmetrica-mcpAdd to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"appmetrica": {
"command": "npx",
"args": ["-y", "appmetrica-mcp"],
"env": {
"APPMETRICA_ALLOW_WRITE": "true"
}
}
}
}git clone https://github.com/pavellunev99/app_metrica_mcp
cd app_metrica_mcp
npm install
npm run buildVariable | Required | Default | Description |
| No | — | Yandex OAuth token; optional when |
| No |
| Where |
| No | bundled public app | Your own Yandex OAuth app ClientID for |
| No |
| Port of the |
| No |
| Set to |
| No |
| JSON file where local workspaces (saved dashboard widget sets) are stored |
| No |
| Chrome profile directory that holds the Yandex login for the experimental |
| No | — | Path to a Chrome/Chromium executable (overrides the channel) |
| No |
| Browser channel for the web session: |
| No |
| Idle time after which the headless web session closes Chrome and frees the profile (so |
Tool | Description |
| List all AppMetrica applications in your account |
| Get details for a specific application by ID |
| List client event names of an application (use them as funnel steps) |
| List configured conversions (attributed events) |
| Check whether the Logs API is enabled for the account |
Tool | Description |
| Aggregated metrics for a date range, with |
| The same as a time series ( |
| Drill down into a dimension value for detailed breakdown |
| Metric/dimension catalogue (197 metrics, 188 dimensions): compact overview, or |
| Event instrumentation audit for a period: registered vs active vs zero-volume events, optional |
Tool | Description |
| List saved segments (id, name, expression) |
| Get one segment with all fields |
Tool | Description |
| List saved funnels with decoded steps and options |
| Per-step devices and conversion for a saved funnel ( |
Tool | Description |
| Run preset widgets ( |
| List preset widgets with their metrics |
| List locally saved workspaces |
| Get a workspace with its widget specs |
| Create or update a local workspace (local file only) |
| Delete a local workspace (local file only) |
Unofficial tools that drive the AppMetrica web UI's internal API through a logged-in headless Chrome — see Web session. Every tool needs npx appmetrica-mcp login once; tools marked Write also need APPMETRICA_ALLOW_WRITE=true.
Tool | Access | Description |
| Read | Check the web session: logged in, Yandex login, profile directory |
| Read | List the app's AppMetrica workspaces (system + custom) |
| Read | One workspace: groups, headers and widgets with names, metrics, dimensions |
| Read | Web preset widgets ( |
| Read | Report namespaces with their Reporting API prefix; with |
| Write | Create a workspace with |
| Write | Add a row of widgets to a workspace ( |
| Write | Add a section header row |
| Write | Rename a workspace |
| Write | Remove a widget by |
| Write | Delete a custom workspace (system |
| Write | Create an AppMetrica workspace from a local one ( |
Tool | Description |
| Export raw custom event logs |
| Export raw crash logs |
| Export raw installation logs |
| Export any Logs API table (13 tables), with field validation; |
Tool | Access | Description |
| Read | List push notification campaigns with optional status filter |
| Read | Get delivery statistics for a campaign |
| Write | Create a push campaign (requires |
All of these require APPMETRICA_ALLOW_WRITE=true (and an OAuth token with write access); otherwise they return an error and send no request.
Tool | Description |
| Create a saved funnel ( |
| Rename / re-comment a funnel, or rebuild its steps and options (the rest of the saved funnel is kept) |
| Delete a saved funnel |
| Create a segment from |
| Change a segment's |
| Delete a segment |
| Create a push campaign (see Push Notifications) |
| Experimental web-session tools (see Web session); they use the Chrome login, not the OAuth token |
What can and cannot be created. Funnels and segments are created through the Management API and show up in the AppMetrica web UI. Dashboards and workspaces are not creatable through the public API: the web UI keeps them behind an internal GraphQL endpoint that needs a cookie session and CSRF token, which an OAuth token cannot use. The experimental web_* tools work around this with a logged-in Chrome session (see Web session); otherwise use the local workspaces and presets (see Dashboards & workspaces); the analytics_setup prompt also outputs a "web dashboard blueprint" you can build by hand.
Saved funnels support only what the web funnel editor can show: client-event steps (several events per step = any of them, at most one event parameter key/value per step, applied to every event of the step) and install steps. Other step kinds (crash, purchase, session_start, ...) and several parameters per step are rejected — run those ad hoc with get_funnel_report. Segments are created from events only (users who did all of them): the API derives the segment expression from the web editor's filter JSON, so other condition types (device, geo, version, profile…) have to be created in the web UI. For ad-hoc filtering use the filters parameter of the report tools.
Prompt | Arguments | Description |
|
| End-to-end workflow: audit the app's events (last 28 days), scan the source code for AppMetrica event calls, design and verify 3-6 funnels (saved with |
get_funnel_report mirrors the web "Funnels" report. It reads the per-step metrics ym:uf:devicesInStep1..N (ym:sf: for single-session funnels) from the Reporting API: the number of devices that completed each step in sequence. Absolute conversion is relative to step 1, relative conversion to the previous step.
Saved funnel — list_funnels shows funnels created in the web UI; pass funnel_id and the saved pattern is used as-is (for funnels saved with "events between steps" off the restriction is rebuilt from the editor steps, as the web UI does). Funnel options below are ignored in this mode.
Ad-hoc funnel — pass steps. A step is a list of client events (any of them), optional event_params (key == value), or another kind: install, session_start, crash, error, purchase, ad_revenue, deeplink, any_event. Use list_events to find event names.
Options (ad-hoc): foreground_only (default true), single_session (default false), events_between_steps (default true; false joins steps with next and sends funnel_restriction), window_seconds.
Breakdowns — dimensions (full keys or bare suffixes like date, appVersion, operatingSystemInfo, regionCountry), filters, segment_id, group (day/week/month, adds one bytime request for a series).
Ad-hoc example:
{
"app_id": 12345,
"date_from": "2026-09-01",
"date_to": "2026-09-30",
"steps": [
{ "title": "Open", "events": ["app_open"] },
{ "title": "Paywall", "events": ["paywall_shown"] },
{ "title": "Purchase", "kind": "purchase" }
],
"dimensions": ["operatingSystemInfo"]
}AppMetrica's web workspaces and the "Обзор" dashboards are served by an internal, cookie-authenticated endpoint that the public API (OAuth token) cannot reach. This MCP therefore builds dashboards itself (to manage the real web workspaces use the experimental Web session tools; web_push_workspace copies a local workspace there):
Presets — get_dashboard runs named widgets computed from the Reporting API: audience, installs, installs_by_country, engagement, app_versions, events, crashes, errors, anr, revenue, ad_revenue, ad_revenue_by_type, conversions, traffic, push, funnels (every saved funnel) and retention (not available in the public API — returns an unavailable note). Default set: audience, installs, engagement, crashes, events. list_dashboard_presets shows the metrics of each.
One request per widget, run sequentially and never mixing namespaces; a failing widget returns {name, error} instead of failing the whole dashboard. Keep the quota in mind (30 requests/second, 5000/day). group turns widgets without breakdown into time series, currency (default USD) applies to revenue widgets, segment_id restricts every widget to a saved segment.
Workspaces — save_workspace stores a named widget set in a local JSON file (default ~/.config/appmetrica-mcp/workspaces.json, override with APPMETRICA_WORKSPACES_FILE); get_dashboard(workspace=...) runs it. A widget has a name and exactly one of preset, metrics (custom, single namespace; optional dimensions, filters, segment_id, limit) or funnel_id. A workspace may define a default app_id. Workspace tools only touch the local file — they are not gated by APPMETRICA_ALLOW_WRITE and never write to AppMetrica.
What it does. The web_* tools list, create, edit and delete the real AppMetrica workspaces (dashboards) and their widgets — the part of the product the public API cannot manage. The web UI talks to an internal GraphQL endpoint (POST https://appmetrica.yandex.ru/api) that accepts only a Yandex cookie session plus a CSRF token embedded in the page; an OAuth token is rejected. The MCP therefore drives that endpoint through a real Google Chrome (playwright-core, persistent profile) and reuses your login.
Login (once).
npx appmetrica-mcp login # opens Chrome; log in to Yandex, the window closes by itself
npx appmetrica-mcp session-status # prints {"logged_in": true, "login": "...", ...}After that every web_* call reuses the saved profile headlessly (the first call starts Chrome, about 7 seconds; the session is shared by all calls and closed when the server exits). Yandex renews the session on every visit and the CSRF token is refreshed automatically, so a re-login is only needed when Yandex invalidates the session — the tools then answer with a "not logged in" error that tells you to run npx appmetrica-mcp login. A Chrome profile can be opened by one Chrome at a time, so the headless session closes Chrome after 2 minutes without web_* calls (APPMETRICA_BROWSER_IDLE_MS) and as soon as it finds itself logged out — run login whenever the tools are idle; if Chrome reports the profile is in use, wait a couple of minutes or stop the server.
Security note. The profile holds a full Yandex session for that account (not a scoped token) and Chrome stores it with a basic keychain, so treat the profile directory like a credential: keep it on your own machine and prefer a dedicated Yandex account that only has access to the AppMetrica apps you need. web_session_status reports the account name (yandex_login); no other cookie or token value is ever returned.
Environment variables. APPMETRICA_BROWSER_PROFILE (profile directory, default ~/.config/appmetrica-mcp/chrome-profile), APPMETRICA_BROWSER_PATH (Chrome/Chromium executable) and APPMETRICA_BROWSER_CHANNEL (chrome by default; chromium, msedge, ...). Requirement: Google Chrome installed (or a browser given by APPMETRICA_BROWSER_PATH).
Widgets. Every tool that takes widgets accepts the same WidgetInput, exactly one of:
{ "preset": "AudienceMulti" } — a web preset widget (ids from web_list_widget_presets, e.g. Installs, Audience, Crashes, CrashFreeSessions, Revenue, AppVersion, PushSent); optional view_kind.
{ "funnel_id": 267628 } — a saved funnel (list_funnels) as a Funnels widget (default view FunnelFirstStep).
{ "name": "...", "metrics": ["ym:u:users"], "dimensions": ["ym:u:appVersion"], "segment_id": 5, "view_kind": "Table" } — a custom widget. The report namespace is derived from the first metric's prefix (ym:u: → Audience, ym:r2: → Revenue, ym:ce2: → Events, ...; for prefixes shared by several namespaces Cohort is used for ym:i: and UserAcquisition for ym:ts:) or given explicitly with namespace (web_list_report_namespaces). Metric and dimension ids are validated against the namespace; an unknown id fails with a list of similar ones.
view_kind values: Timeline (default), TimeColumn, Table, Pie, MultiTimeColumn, FunnelFirstStep; other strings are passed through unchanged. A group is { "header": "text", "widgets": [...] }; a group with both becomes a header row followed by a widgets row. AppMetrica limits a workspace to 20 widgets and 40 groups, an app to 20 dashboards.
{
"app_id": 12345,
"name": "Product overview",
"groups": [
{ "header": "Audience" },
{ "widgets": [{ "preset": "AudienceMulti" }, { "preset": "NewUsers" }] },
{ "header": "Funnels" },
{ "widgets": [{ "funnel_id": 267628 }] },
{ "widgets": [{ "name": "Users by version", "metrics": ["ym:u:users"], "dimensions": ["ym:u:appVersion"], "view_kind": "Table" }] }
]
}web_create_workspace creates the whole workspace with one request and returns {dashboard_id, name, url, groups}.
Local workspace → AppMetrica. web_push_workspace(app_id, workspace, name?) takes a workspace saved with save_workspace and creates it in AppMetrica: one header row (the widget name) plus a row of web widgets per local widget. Local presets map to web presets where there is a clear counterpart — audience → AudienceMulti, installs → Installs, engagement → UserTimeSpent + AvgSessionTime + UserSessionsCount, app_versions → AppVersion, crashes → CrashFreeSessions + Crashes, errors → ErrorLogsIos + ErrorLogsAndroid, revenue → RevenueTotal + RevenuePurchases, ad_revenue → AdRevenue + AdRevenueARPU + AdRevenueECPM, traffic → Clicks + Installs + InstallConversion, push → PushSent + PushReceived + PushOpened, retention → RetentionDynamics, funnels → one Funnels widget per saved funnel. installs_by_country, events, conversions, anr, ad_revenue_by_type and local custom metrics widgets become custom widgets; local funnel_id widgets become Funnels widgets. Widgets that cannot be created (unknown metric ids, no saved funnels) are skipped and listed in skipped; notes lists what could not be carried over (filters, segment_id on preset widgets).
Limitations.
This is an unofficial, internal API used by the web client: it may change without notice and break the tools. The GraphQL documents are kept in src/web/operations.ts; to refresh them record real traffic with node scripts/record-graphql.mjs (after npm run build; it opens Chrome with the logged-in profile and records everything you do) and update the fragments/operations in src/web/operations.ts accordingly.
Needs Google Chrome and a Yandex login on the machine running the MCP server.
Mutations require APPMETRICA_ALLOW_WRITE=true. System dashboards (<appId>/General, ...) cannot be deleted by web_delete_workspace.
Yandex may rate-limit the web endpoint (HTTP 429): wait a minute and retry.
Reporting API — data, data/bytime, data/drilldown; filters, sorting, segments (segment_id), currency and sampling parameters; funnel step metrics via funnel_pattern.
Logs API — all 13 tables: events, crashes, errors, installations, sessions_starts, deeplinks, postbacks, clicks, push_tokens, profiles_v2, revenue_events, ecommerce_events, ad_revenue_events.
Management API — applications, events list, conversions, segments and saved funnels (read, and create/update/delete in write mode), Logs API status.
The metric/dimension catalogue and the Logs API field lists come from the official docs and are stored in src/catalog.generated.ts. Regenerate it with node scripts/update-catalog.mjs.
Once connected, you can ask Claude things like:
"List my AppMetrica applications"
"Show DAU and sessions for app 12345 over the last 7 days"
"Export crash logs for app 12345 from 2024-01-01 to 2024-01-07"
"What push campaigns are currently active for app 12345?"
"Show me new user counts broken down by app version"
"Show the conversion of my saved funnels for app 12345 last month"
"Build a funnel app_open -> paywall_shown -> purchase for iOS users in September"
"Give me an overview dashboard for app 12345 for the last 14 days, weekly"
"Save a workspace 'weekly' with audience, crashes and revenue widgets"
"Audit the events of app 12345 for the last month and tell me which ones are dead"
"Create a funnel app_open -> paywall_shown -> purchase_completed and a segment of users who saw the paywall" (needs APPMETRICA_ALLOW_WRITE=true)
"Run the analytics_setup prompt for app 12345 on ~/Projects/MyApp"
"Create an AppMetrica workspace 'Product overview' for app 12345 with audience, crash-free sessions and my paywall funnel" (experimental web session; needs APPMETRICA_ALLOW_WRITE=true)
AppMetrica enforces the following limits on all API requests:
30 requests / second per OAuth token
5,000 requests / day per OAuth token
The client retries automatically on 429 and 5xx responses with exponential backoff (1s → 2s → 4s, up to 3 attempts).
MIT
Create a new push notification campaign in AppMetrica. Requires APPMETRICA_ALLOW_WRITE=true to be set.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | AppMetrica application ID | |
| name | Yes | Campaign name | |
| message | Yes | Push notification message content | |
| audience | No | Audience targeting options | |
| schedule | No | Schedule options for the campaign |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only discloses the write permission requirement. Missing details on side effects, idempotency, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loads the purpose, then adds a critical requirement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite good schema coverage, the description lacks information about return values, success indicators, or validation. With no output schema and 5 parameters including nested objects, more context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with adequate descriptions for all parameters. The description does not add additional meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (create), resource (push notification campaign), and platform (AppMetrica). The description is specific and distinguishes from sibling tools like list_push_campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions a required precondition (APPMETRICA_ALLOW_WRITE=true). However, it does not discuss when to use this tool versus alternatives or 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.
Export raw crash logs from AppMetrica for a given application and time range. Use this for per-crash-name breakdowns — get_report only exposes the total ym:cr:crashes count. Same async/rate-limit behaviour as export_events: poll up to ~60s, retry after a few minutes for wide ranges, run sequentially.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | AppMetrica application ID | |
| date_from | Yes | Start date YYYY-MM-DD | |
| date_to | Yes | End date YYYY-MM-DD | |
| fields | No | Comma-separated fields to return. Defaults: crash_name,crash_datetime,crash_receive_datetime,appmetrica_device_id,app_version_name,os_version,device_model,country_iso_code | |
| limit | No | Maximum number of crash records to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses async behavior, polling timeout, retry advice, and sequential execution. Lacks explicit statement on read-only or side effects, but these are implied by export/log context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a clear purpose: purpose, usage differentiation, behavioral notes. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, behavior, and links to sibling export_events. Missing return format (raw logs? CSV?) and prerequisites like authentication. Still reasonably complete given no annotations or output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description does not add semantic detail beyond schema descriptions for parameters like fields or limit. No enrichment provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'export', resource 'raw crash logs', and scope 'for a given application and time range'. It also distinguishes from sibling get_report by noting 'per-crash-name breakdowns' versus total count.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool over get_report ('Use this for per-crash-name breakdowns') and provides async/rate-limit behavior guidance ('poll up to ~60s, retry after a few minutes for wide ranges, run sequentially').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export raw event logs from AppMetrica Logs API. Revenue and in-app purchase data is stored in the event_json field as structured JSON. Default fields: event_name, event_datetime, event_json, appmetrica_device_id, app_version_name, os_version, device_model, country_iso_code, city. To get subscription/purchase data: filter by event_name (e.g. "subscription_purchase") and parse event_json field.
Logs API is asynchronous — the first request usually returns "data not ready" and the result must be re-polled (this wrapper waits up to 60s, so a busy or wide query may need a manual retry after a few minutes). Start with 1-day windows; multi-day exports take noticeably longer to materialise. Run export_events sequentially — 4+ parallel calls hit HTTP 429.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | AppMetrica application ID | |
| date_from | Yes | Start date YYYY-MM-DD | |
| date_to | Yes | End date YYYY-MM-DD | |
| event_name | No | Filter by specific event name (e.g. subscription_purchase) | |
| fields | No | Comma-separated fields to return. Defaults: event_name,event_datetime,event_json,appmetrica_device_id,app_version_name,os_version,device_model,country_iso_code,city | |
| limit | No | Maximum number of events to return (default 1000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavior: async with re-polling (60s wait), rate limiting (429), default fields, revenue data structure in event_json, and performance characteristics. Comprehensive disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured paragraphs. Front-loaded with main purpose, then details. Every sentence adds value with zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 6 parameters, description covers async behavior, rate limits, defaults, filtering, and performance advice. Complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% so baseline 3. Description adds value: explains that event_name filters (e.g., 'subscription_purchase'), event_json contains structured JSON, and lists default fields. Adds meaningful context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Starts with 'Export raw event logs from AppMetrica Logs API', clearly stating verb (export) and resource (raw event logs). Distinguishes from sibling export tools like export_crashes and export_installations by specifying events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage tips: start with 1-day windows, run sequentially, avoid 4+ parallel calls due to HTTP 429. Also explains async nature and re-polling. Does not explicitly compare to alternatives, but context implies this is for events.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export raw installation logs from AppMetrica for a given application and time range. Same async/rate-limit behaviour as export_events: poll up to ~60s, retry after a few minutes for wide ranges, run sequentially.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | AppMetrica application ID | |
| date_from | Yes | Start date YYYY-MM-DD | |
| date_to | Yes | End date YYYY-MM-DD | |
| fields | No | Comma-separated fields to return. Defaults: installation_id,install_datetime,appmetrica_device_id,app_version_name,os_version,device_model,country_iso_code,city | |
| limit | No | Maximum number of installation records to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important behavioral traits: async, polling up to ~60s, retry for wide ranges, sequential execution. However, it does not detail output structure or potential error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. First sentence clearly states purpose, second provides essential behavioral guidance. Highly efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema, the description covers key behavioral aspects (async, rate limits) and references export_events for deeper context. Missing explicit return structure, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is already documented. The description adds no additional meaning beyond the schema, thus baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Export', the resource 'raw installation logs', and the scope 'from AppMetrica for a given application and time range'. It effectively distinguishes from sibling tools like export_events and export_crashes by specifying the data type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear behavioral context by referencing export_events' async behavior (poll, retry, sequential), but does not explicitly state when to use this tool versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific AppMetrica application by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | AppMetrica application ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only states 'Get detailed information' without disclosing that it's read-only, effects of missing IDs, or any behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description is adequate but vague about what 'detailed information' entails. Could specify types of data returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add meaning beyond the schema's parameter description ('AppMetrica application ID'). Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get), the resource (detailed information about a specific AppMetrica application), and the method (by its ID). It is distinct from sibling tools like list_applications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied but not explicitly contrasted with alternatives like list_applications. No when-not-to-use guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve drilldown statistics for a specific parent dimension value in AppMetrica. Useful for hierarchical data exploration.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | AppMetrica application ID | |
| parent_id | Yes | Parent dimension value ID for drilldown | |
| metrics | Yes | Metric keys to retrieve | |
| date_from | Yes | Start date in YYYY-MM-DD format | |
| date_to | Yes | End date in YYYY-MM-DD format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only implies a read operation ('Retrieve') without mentioning any behavioral traits such as permissions, idempotency, rate limits, or data scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous words. The first sentence front-loads the action and resource, making it efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five required parameters and no output schema. The description fails to explain the return format, pagination, or error scenarios, leaving the agent underinformed about the tool's complete behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All five parameters have descriptions in the input schema (100% coverage), so the description adds little beyond stating the overall purpose. The baseline of 3 is appropriate as the schema handles parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the resource 'drilldown statistics for a specific parent dimension value in AppMetrica', distinguishing it from sibling tools like list_applications or get_report. However, it does not explicitly differentiate from other data retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Useful for hierarchical data exploration' provides implied usage context, but there is no explicit guidance on when to use this versus alternatives, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get summary statistics for a specific push notification campaign in AppMetrica.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | AppMetrica application ID | |
| campaign_id | Yes | Push campaign (group) ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It identifies the operation as a read ('get'), but fails to mention if it's safe to call repeatedly, requires specific permissions, or affects any state. This is insufficient for a complete behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, compact and to the point. It contains no unnecessary words. However, it could be slightly improved by including a brief description of the output, but it is still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description should provide more context about what 'summary statistics' entails and the nature of the response. It does not describe the return format or any constraints, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters (app_id and campaign_id), so the description does not need to repeat them. The description adds no extra meaning beyond the schema, which aligns with the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves summary statistics for a specific push notification campaign in AppMetrica. It uses a specific verb ('Get') and resource ('summary statistics'), making the purpose clear. However, it does not explicitly differentiate from sibling tools like list_push_campaigns or create_push_campaign, so it falls short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, no prerequisites or exclusions are mentioned. The description only states what it does, not when it should be chosen over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve aggregated statistics from AppMetrica. Call list_metrics first for the catalogue with namespace grammar and known-bad keys. Quick reference: ym:u:* users · ym:s:* sessions · ym:cr:* crashes · ym:ge:* general events · ym:i:* installs · ym:pc:* push campaigns Common 4002 traps: ym:u:sessions, ym:u:crashes, ym:u:revenue do not exist — use ym:s:, ym:cr:, and event_json from export_events instead. Retention / per-user push opens / per-event aggregates are not exposed via get_report at all (use export_events / export_crashes, or the AppMetrica UI). Mixing ym:u:/ym:s:/ym:cr: in one metrics= call has been observed to work; mixing more distant prefixes (e.g. ym:ge:+ym:pc:) is unsupported per docs.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | AppMetrica application ID | |
| metrics | Yes | Metric keys to retrieve, e.g. ['ym:u:users', 'ym:s:sessions', 'ym:cr:crashes'] | |
| dimensions | No | Dimension keys for breakdown, e.g. ['ym:u:date', 'ym:u:appVersion'] | |
| date_from | Yes | Start date in YYYY-MM-DD format | |
| date_to | Yes | End date in YYYY-MM-DD format | |
| limit | No | Maximum number of rows to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description compensates by detailing behavior (working and non-working metric combinations, error codes). Could explicitly state read-only nature but clearly implies retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose and includes dense, useful information. Slightly long but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 params and no output schema, description covers prerequisites, common errors, and usage boundaries. Lacks return format explanation but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; description adds value with quick reference to metric keys and common traps, though parameter semantics for dimensions and limit could be enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves aggregated statistics from AppMetrica, specifies metric key prefixes, and distinguishes from sibling tools like export_events and export_crashes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends calling list_metrics first, lists common error traps (4002), and notes when not to use this tool (e.g., retention, per-user data) and what alternatives to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all AppMetrica applications available to the authenticated user. Returns application IDs, names, platforms, and creation dates.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It is clear that the tool is read-only and returns a list of applications with specified fields. It does not mention pagination or limits, but given zero parameters, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 17 words with no fluff. It efficiently communicates the tool's purpose and output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no parameters and no output schema, the description covers the essential information: what it does and what it returns. It could hint at sorting or filtering defaults, but is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100% vacuously. The description does not need to add parameter meaning beyond the schema, and it correctly omits any parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'AppMetrica applications', and specifies the return fields (IDs, names, platforms, creation dates). This distinguishes it from sibling tools that deal with other operations like creating campaigns or exporting data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all applications available to the user, but does not explicitly contrast with alternatives like get_application for a single application. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Catalogue of AppMetrica Reports API metric and dimension keys for get_report / get_drilldown, with namespace grammar and known traps. Each entry has status="verified" (confirmed live) or status="documented" (from AppMetrica docs / R-client examples but not yet probed by this MCP). This is NOT exhaustive — AppMetrica does not publish a public metadata endpoint and the docs are SmartCaptcha-gated. Unknown keys fail with HTTP 4002 (metric) or 4001 (dimension).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses non-exhaustive nature, status field meaning, error codes for unknown keys, and namespace grammar. With no annotations, this provides necessary behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three sentences that front-load purpose, then add status and limitation details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter metadata catalog, the description covers purpose, contents, status, and error handling. Lacks explicit output format but is sufficient given no output schema and low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema, so baseline of 4 applies. Description adds no parameter info as none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it is a catalogue of metric and dimension keys for get_report/get_drilldown, with statuses and grammar. This distinguishes it from sibling reporting tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage: consult this tool to discover valid keys before calling get_report or get_drilldown. No explicit when-not-to-use, but context with siblings makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List push notification campaigns (groups) for an AppMetrica application. Optionally filter by campaign status.
| Name | Required | Description | Default |
|---|---|---|---|
| app_id | Yes | AppMetrica application ID | |
| status | No | Filter campaigns by status: active, paused, or finished |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral context. It only states the core function (list with optional filter) without disclosing side effects, authentication needs, rate limits, or error handling. This is insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no extraneous information. The main action is front-loaded, and the optional filter is mentioned naturally. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain what the tool returns (e.g., fields, structure). It is minimal but adequate for a simple list operation, though more detail on response format would improve agent utility.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with 100% coverage. The description adds 'Optionally filter by campaign status' which is redundant with the schema. No new semantic nuance beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists push notification campaigns for AppMetrica, using specific verb 'list' and resource 'campaigns'. It distinguishes from sibling tools like create_push_campaign (creation) and other list tools (list_applications, list_metrics), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It lacks explicit when-to-use or when-not-to-use context, leaving the agent to infer usage solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.3create_push_campaignexport_crashesexport_eventsexport_installationsget_applicationget_drilldownget_push_statsget_reportlist_applicationslist_metricslist_push_campaignsScored across 11 tools
Each tool targets a distinct resource or operation: export tools handle different data types (events, crashes, installations), report tools vary in granularity (report vs drilldown), and push campaign management is separated into create, list, and stats. No significant overlap.
All tool names follow a consistent verb_noun pattern in snake_case: create_, export_, get_, list_. Verbs are uniform and nouns clearly describe the resource or data type.
11 tools cover the core functionalities of the AppMetrica domain: application listing/detail, report generation, raw data export, and push campaign management. The count feels well-scoped without unnecessary redundancy.
The tool surface provides read operations (get, list, export, report) and a create operation for push campaigns. Missing update/delete for campaigns and apps, but the analytics reporting and data export are thoroughly covered. Minor gaps that agents can work around.
MCP server for querying and analyzing data from ad platforms, analytics tools, and spreadsheets
Clamp Analytics MCP server: traffic, revenue, funnels, cohorts, errors, and search, for AI agents.
MCP server for Appcircle mobile CI/CD platform.
Hosted MCP server for Google Ads and LinkedIn Ads analysis.
