Skip to main content
Glama
5iNeX

yandex-api-mcp

by 5iNeX

audience.hf.segment_perf

Analyze best-effort performance for a Yandex Audience segment by combining Direct and Metrica data over a date range and chosen grain.

Instructions

Human-friendly: best-effort segment performance via Direct+Metrica.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
grainNoday|week|month (default: day).
date_toYesYYYY-MM-DD.
goal_idsNo
date_fromYesYYYY-MM-DD.
account_idNoProject profile id (resolves to Direct Client-Login and optional Metrica counter defaults).
counter_idNo
segment_idYes
include_raw_refsNoInclude raw_refs (default: true).
direct_client_loginNoOverride Direct Client-Login for this call (agency multi-project support).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.4/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. 'Best-effort' hints that results may be partial or unreliable and 'Human-friendly' implies a formatted rather than raw output, but auth requirements, rate limits, failure modes, and whether the two data sources are merged or fallback are all undisclosed.

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

Conciseness3/5

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

It is a single short sentence with no padding, but it is under-specified rather than concise. The 'Human-friendly:' prefix front-loads a marketing qualifier instead of the operation's defining behavior.

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

Completeness2/5

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

For a 9-parameter tool with 3 required args, no output schema, and no annotations, a one-line description is far from complete. It leaves the agent unable to distinguish this tool from the many sibling audience.hf.* reporting tools or to use its parameters correctly.

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

Parameters2/5

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

Schema coverage is a moderate 67%, and the description adds no parameter meaning at all. It gives no hint about grain, goal_ids, include_raw_refs, account_id/counter_id resolution, or the direct_client_login override, so the agent cannot compensate for the undocumented fields.

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

Purpose3/5

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

The description names a resource ('segment performance') and the underlying data sources ('Direct+Metrica'), which is more than a tautology. However, the qualifiers 'Human-friendly' and 'best-effort' are vague, and it does not distinguish this tool from siblings like audience.hf.get_segment_summary or audience.hf.segment_health.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no mention of competing tools (segment_health, get_segment_summary, overlap_matrix). The agent is left to infer whether this is a summary, a time series, or a per-goal breakdown.

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

Deploy Server

Other Tools