AppTail – ASO & Keyword Research

Get Performance

get_performance

Read-only

Read measured App Store Connect impressions, store views, downloads, sales and proceeds for apps connected to the authenticated account. Supports an owned app or portfolio, documented time windows, period comparisons and breakdowns by storefront or traffic source. Returns the actual reporting window, connection coverage and caveats. Does not provide private analytics for apps outside the account.

Input Schema

TableJSON Schema

Name	Required	Description
`to`	No	End date, `YYYY-MM-DD`, inclusive. Send it alone and the window is the three years before it.
`from`	No	Start date, `YYYY-MM-DD`, inclusive. Overrides `period` when both are sent. Send it alone and the window runs to today.
`grain`	No	Bucket size for the series. Omit and it is chosen to fit the window — a day for a month, a week for a year. A grain too fine or too coarse for the window is ignored rather than refused.
`scope`	No	`portfolio` (the default) sums every app the account owns; `app` reports one, and then `app_id` is required. Hidden apps are in the portfolio sum only if the account has not hidden them — they are excluded, matching what the console shows.
`split`	No	Break the totals down. `country` gives one row per storefront Apple named; `source` gives Apple's own attribution — App Store search, browse, app and web referrers. `source` reports the attribution associated with measured downloads. Rows need not add up to the total; the caveats say so.
`app_id`	No	Apptail app id, required when `scope` is `app`. Must be one of the user's own apps — get_account lists them. Measured analytics require an authorised App Store Connect connection for the account.
`period`	No	The window to report on. A calendar month as `2026-07`, a calendar year as `2026`, `last_month`, `this_month`, `last_year`, or a trailing window: `today`, `7d`, `14d`, `30d`, `90d`, `180d`, `365d`, `730d`, `1095d`. Defaults to `30d`. A calendar period is compared against the calendar period before it — July against June, not against the 31 days ending 30 June. Three years is the ceiling.
`compare`	No	What to read the window against. `previous` (the default) is the period immediately before — for a calendar month that is the calendar month before, not the same number of days. `year_ago` is the same dates a year earlier, for comparison with the corresponding period in the previous year.
`include_apps`	No	On `portfolio` scope, also return one row per app so a portfolio move can be attributed to the app that caused it. Default false.

Output Schema

TableJSON Schema

Name	Required	Description
`apps`	Yes	One row per app, when `include_apps` was set on a portfolio call. Empty otherwise.
`grain`	Yes	Bucket size the series came back at.
`scope`	Yes	Which scope answered: `portfolio` or `app`.
`split`	Yes	Which breakdown was returned: `none`, `country` or `source`.
`series`	Yes	The same metrics bucketed across the window, oldest first. Empty when nothing is connected.
`totals`	Yes	Window totals, one entry per metric, each carrying where it came from and what it may be compared with.
`window`	Yes	The window actually read, which is not always the one asked for: an inverted range is swapped, a range past three years is shortened, and first-party figures are pulled back to the last day App Store Connect reported. Quote these dates, not the requested ones.
`app_ids`	Yes	The apps behind these figures.
`caveats`	Yes	Sentences the reader has to hear before the numbers mean what they look like they mean — apps left out, a window shortened, a breakdown that does not sum. Pass these on; do not summarise them away.
`coverage`	Yes	What the totals do and do not cover. Quote this whenever `connected` is below `apps`.
`truncated`	Yes	True when `split_rows` is shorter than `split_total`. Say so rather than presenting the returned rows as the whole breakdown.
`split_rows`	Yes	The breakdown, biggest by downloads first. Empty when `split` is `none`.
`split_total`	Yes	How many rows the breakdown has in total, which can exceed the number returned.
`data_through`	No	Last day App Store Connect has reported across these apps. Apple lands analytics one to two days late, so this is usually a day or two behind today; a gap of a week or more is a broken connection rather than a lag.
`requested_window`	Yes	What the call asked for, when that differs from what was read. Compare with `window` before quoting a total as covering the period the user named.
`comparison_window`	No	The window `previous` on each metric was measured over. Null when `compare` was `none`.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 2, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint=false), and the description adds real behavioral context beyond them: it returns the actual reporting window, connection coverage, and caveats, and it discloses that hidden apps are excluded from the portfolio sum to match the console. It does not discuss rate limits or auth requirements beyond connection mention.

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?

Three tight sentences: what it reads, what it supports, what it returns, and what it excludes. Front-loaded with the resource set and free of filler.

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 9-parameter read tool with an output schema, this covers scope, exclusions, comparison/split capabilities, and even return caveats. Nothing material to correct invocation is missing.

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

Parameters3/5

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

Schema description coverage is 100% with unusually rich per-parameter documentation (grain fallback behavior, period/compare semantics, split row caveats), so the schema already carries the semantics. The description only gestures at 'documented time windows', 'period comparisons' and 'breakdowns by storefront or traffic source', which adds little beyond what the schema says.

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?

States a specific verb (read) and concrete resource set (impressions, store views, downloads, sales, proceeds) scoped to App Store Connect apps on the authenticated account. It is clearly distinct from mutation siblings like add_app or reply_to_reviews, though it does not explicitly contrast itself with the closest read siblings (get_signals, get_app).

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?

Gives clear context: owned app or portfolio, documented time windows, comparisons, and breakdowns, plus an explicit exclusion ('Does not provide private analytics for apps outside the account'). It points at get_account for obtaining app ids. It stops short of naming a specific alternative tool for other kinds of reporting.

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

All AppTail – ASO & Keyword Research tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?