Yandex Metrika MCP

Overview Schema Source Related Servers Discussions Admin

Yandex Metrika: export report

metrika_export_report

Idempotent

Exports all Yandex Metrika report rows to CSV or JSON in the background and returns a job for polling, resuming, or reading the file.

Instructions

Exports all rows of a Yandex Metrika report to a CSV or JSON file in the background and returns a job. Requires idempotency_key; the same key returns the same job. To continue an interrupted export pass only connection_id and resume_job_id. Poll metrika_get_job until completed, then read with metrika_read_artifact or give the user file_path.

Input Schema

Name	Required	Description
`sort`	No	Field IDs; prefix with '-' for descending. Default: first metric descending.
`format`	No	csv (default), csv_excel_safe (BOM + formula guard for Excel) or json (exact values).
`period`	No	Either {preset} or {start, end}. Dates are in the counter time zone. Default: last_7_complete_days.
`preset`	No	Ready-made report. Mutually exclusive with metrics/dimensions.
`filters`	No	Conditions combined with AND.
`metrics`	No	Metric IDs (e.g. ym:s:visits, ym:s:goal<ID>visits) when no preset is used.
`accuracy`	No	strict (default): fail instead of returning sampled data. balanced: accept sampling with a warning.
`goal_ids`	No	Goal IDs (not names) from metrika_describe_counter; adds goal columns to a preset.
`counter_id`	No	Counter ID as a string, from metrika_list_counters.
`dimensions`	No	Dimension IDs.
`connection_id`	Yes	Connection ID from metrika_status (e.g. conn_demo).
`resume_job_id`	No	Continue an interrupted export. Pass only connection_id and resume_job_id.
`idempotency_key`	No	Required for a new export. Repeating the same key returns the same job.

Output Schema

Name	Required	Description	Default
`kind`	Yes
`error`	Yes
`query`	Yes
`stage`	Yes
`state`	Yes
`format`	Yes
`job_id`	Yes
`progress`	Yes
`warnings`	Yes
`artifacts`	Yes
`created_at`	Yes
`updated_at`	Yes
`finished_at`	Yes
`next_action`	Yes
`connection_id`	Yes
`schema_version`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 9, 2026

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds substantial behavior beyond the annotations: the export runs in the background, returns a job, requires idempotency_key, returns the same job for the same key, and can be resumed with only connection_id and resume_job_id. This is consistent with idempotentHint=true and readOnlyHint=false, and it discloses the polling and artifact-read workflow.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four compact sentences, front-loaded with the core action and followed by the operational workflow. Every sentence carries useful information without repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex asynchronous export tool with an output schema, the description covers job creation, idempotency, resume behavior, polling, and artifact consumption. The remaining report-shaping details are documented in the comprehensive input schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description adds important conditional meaning: idempotency_key is required for a new export, and resuming requires only connection_id and resume_job_id. It does not explain every report option, but those are already covered by the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it exports all rows of a Yandex Metrika report to a CSV or JSON file as a background job. The scope and async job return are clear, though it does not explicitly contrast this tool with sibling metrika_run_report.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear next-step guidance: poll metrika_get_job until completed, then read with metrika_read_artifact or give the user file_path. It also explains the resume path, but does not explicitly say when to choose this over metrika_run_report or metrika_run_timeseries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server