Skip to main content
Glama

AppTail – ASO & Keyword Research

Get App

get_app
Read-only

Everything AppTail holds about one app, at the depth you ask for. The base answer is the store listing in one storefront — the localised title and subtitle a shopper in country actually reads, the price and its currency, version, category, release dates, the publisher's ids. include adds sections: prices (what it costs in every storefront), ratings (every storefront's rating and vote count, pooled honestly, plus a daily series and per-storefront movement with history_days), charts (the charts it currently ranks in), popularity (organic reach), developer (the publisher and its portfolio), versions (release cadence) and screenshots. Works for ANY app in the store, not only the user's own. It does NOT return impressions, downloads or revenue — get_performance does, and only for the user's own connected apps.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
app_idYesApptail app id. get_account for the user's own apps, search_apps for any other app in the store. Not the numeric id in an App Store URL (that is apple_app_id).
countryNoStorefront to read the listing in (e.g. US, GB, DE). Defaults to the app's primary storefront. Title, subtitle, price, rating and screenshots all differ per storefront, so this changes the answer rather than filtering it — the `name` you get back is the title as published *there*, which for a localised app is not the title in any other market. `ratings.overall`, `ratings.by_country`, `ratings.history` and the `prices` section ignore it — they are every storefront — and `charts` is returned for all of them regardless.
includeNoExtra sections to read. Omit for the listing alone, which is the cheap answer. `ratings`, `charts` and `popularity` need a Starter or Pro plan and are refused by name without one — the rest are free. Ask for what the question needs and nothing else: each section is a query.
history_daysNoWith `include: ["ratings"]`, also return the rating and the vote count day by day, this many days back from today, **and how each storefront moved over that window** — `ratings_gained` and `rating_change` on every row of `ratings.by_country`. Capped at 365. Ask for it whenever the question is whether a rating is *moving* or *where* it is moving: an average slides for weeks before enough people write about it, and a cross-section cannot tell a market that has always been low from one that fell this month. Ignored without the `ratings` include.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
iconNoAbsolute URL of the app icon.
nameNoThe app's title **as published in `country`** — the string a shopper in that storefront reads, which is also the string Apple indexes. It is not a translation of one canonical name: an app localised for Mexico has a different title there, and `get_app(country: "mx")` returning the US one is what makes an agent report a localised app as "not localized". Falls back to the app's canonical name when this storefront has not been crawled yet, and is null only while a freshly imported app is still being processed.
tierNoApptail activity tier for `country`: 1 = currently charting, 2 = shipped more than two updates in the last 180 days.
priceNoDownload price in `country`, in that storefront's own currency and in major units — 9.99, never 999. 0 means free, which is what most apps are; `currency` names the money. Null when this storefront has no listing on file.
storeNoWhich store the app belongs to.
app_idYesApptail app ID. This is the `app_id` every other tool expects.
chartsNoCharts the app currently ranks in, across all countries and categories. Present only with `include: ["charts"]`; empty means it charts nowhere.
pricesNoWhat the app costs to download, per storefront. Present only with `include: ["prices"]`. This is the download price alone: `has_inapps` says whether there is more to pay after that, and get_app does not return in-app purchase tiers.
countryNoStorefront the metrics below were read from. Defaults to `primary_country`.
is_mineNoTrue when this is one of the asking account's own apps. Null when the call carried no account — get_top_charts answers without a token — which is "not known here", not "no".
ratingsNoPresent only when `ratings` is in `include` — a section you did not ask for is absent from the answer entirely, which is not the same as it being empty.
versionNoLatest published version string.
currencyNoISO code of the currency `price` is in, derived from `country`. A price without it is a number, not an amount — several storefronts print a "$" and mean different money.
includesYesThe sections actually read. A section absent from this list is absent from the answer because nobody asked for it — which is not the same as it being empty.
subtitleNoThe subtitle under the title in `country` — thirty characters Apple indexes as heavily as the title, and the field most competitors leave generic. Null when the storefront listing has none, which is itself worth saying: an empty subtitle is unspent keyword weight.
versionsNoRelease history. Present only with `include: ["versions"]`. Cadence is the one competitor signal readable straight off the store: four releases in six weeks then eight months of nothing is a team that moved on.
bundle_idNoStore bundle identifier, e.g. "com.burbn.instagram".
developerNoThe publisher and its portfolio — with the cap on `top_apps` declared. Present only with `include: ["developer"]`; null there when AppTail holds no profile for the publisher.
has_inappsNoWhether the app offers in-app purchases.
popularityNoOrganic reach in `country`. Present only with `include: ["popularity"]`, and **null there when no storefront could be resolved** — a key that is present and null means "asked for, nothing to read", which an absent key does not.
seller_urlNoPublisher's marketing website.
console_urlNoWhere to open this app in the AppTail console — the owner's own dashboard when `is_mine`, the research view otherwise. Null where this environment serves no console. End an answer about an app with it.
screenshotsNoPresent only with `include: ["screenshots"]`, and null there when no storefront could be resolved.
support_urlNoSupport page URL.
apple_app_idNoApple's own numeric app ID, as it appears in App Store URLs. Not interchangeable with `app_id`.
developer_idNoApptail developer ID. Pass this as `developer_id` to get_developer_info. Null if we hold no profile for the publisher.
rating_countNoNumber of ratings in `country`.
release_dateNoDate the app first appeared in the store (YYYY-MM-DD).
rating_averageNoMean star rating (1-5) in `country`. Null if the app has no ratings there yet.
primary_countryNoLowercase ISO country code of the app's main storefront, e.g. "us".
primary_categoryNoStore category ID. Pass this as `category` to get_top_charts.
privacy_policy_urlNoPrivacy policy URL.
store_developer_idNoThe store's own publisher ID, as it appears in store URLs. Not interchangeable with `developer_id`.
listing_storefrontsNoOne storefront per language the listing is localized in, `primary_country` first, e.g. ["ru", "us"]. An app published in two languages is searched for in two storefronts; keyword discovery and tracking are per storefront, so cover each of these rather than only `primary_country`.
is_tracked_competitorNoTrue when the account already tracks this app as a competitor of one of theirs. False on a high-ranking rival is a suggestion worth making: add_competitors starts watching it. Null when the call carried no account.
primary_category_nameNoHuman-readable name of `primary_category`, e.g. "Health Fitness".
current_version_release_dateNoDate the current version shipped (YYYY-MM-DD). Useful as an update-cadence signal.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Offers substantial disclosure beyond the readOnly/openWorld/destructive annotations: plan gating ('ratings, charts and popularity need a Starter or Pro plan and are refused by name without one'), cost behavior ('each section is a query'), a hard cap (history_days capped at 365), and an explicit non-goal (no impressions, downloads or revenue). This is exactly the extra context annotations cannot carry.

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

Conciseness4/5

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

Front-loads the core answer, then layers includes, then exclusions and the alternative tool. Dense but every sentence carries routing, cost or scope information. Length is justified by a 4-parameter tool with a 7-value enum, though a few phrases ('pooled honestly') are decorative rather than informative.

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?

Given an output schema exists, return fields need not be explained, and the description fully covers what an agent needs: scope, storefront semantics, section gating, plan requirements, cost, caps, and the excluded performance metrics. Nothing needed to call it correctly is missing.

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 coverage is 100%, so baseline is 3, but the description adds narrative meaning: `country` 'changes the answer rather than filtering it', and sections are grouped by what question they answer (e.g. `popularity` = organic reach, `versions` = release cadence). Some content overlaps the already-rich schema, preventing a 5, but it does more than echo structured fields.

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

Purpose5/5

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

States a specific verb and resource ('Everything AppTail holds about one app') with an explicit scope boundary: the base answer is 'the store listing in one storefront', and `include` adds named sections. It also explicitly distinguishes itself from get_performance and clarifies it works for 'ANY app in the store, not only the user's own', which separates it from the user-scoped siblings.

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

Usage Guidelines5/5

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

Gives explicit when-to-use routing: get_account for the user's own apps, search_apps for any other app, get_performance for impressions/downloads/revenue. It also states when to use each include section and, crucially, when to omit them ('omit for the listing alone, which is the cheap answer'), plus which sections need a paid plan.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources