Skip to main content
Glama

Get the ASO Health audit

get_aso_health
Read-only

Get the full ASO Health audit of one tracked app: how well its listing is WRITTEN, as opposed to how it currently ranks. Returns app (id, app_id, title, store, country, lang) so a score is always attributable, global (0-100), the three axes, the maturity tier with its label, every field, the terms it targets, flags[], and timeline[] of past releases with their score. THE AXES: coverage = how much searched vocabulary the indexed fields carry; targeting = whether the terms it aims at are winnable AT THIS APP'S SIZE; appeal = rating, screenshots and freshness. TIER drives targeting: 1 Emerging, 2 Growing, 3 Established. The verdict threshold moves with it, so the same term can be "ambitious" for a tier 2 app and "out-of-reach" for a tier 1 one, and a tier 3 app can reasonably aim higher. Say that when you explain a verdict. fields[].state is "scored", "empty" (blank on the store) or "missing" (the iOS keywords field, which Apple never publishes: we only know it if the user gave it to us). fields[].key stays "subtitle" on Google Play, where the store calls that field the short description: use the store's name when you talk to the user. fields[].text is TRUNCATED to a preview and fields[].truncated says so; the full text is on list_applications. targeting.keywords[].verdict is "reachable", "ambitious" or "out-of-reach"; traffic and difficulty are both 0-100. targeting.ungraded counts searched terms we have no competition data for; targeting.unsearched counts words nobody types, listed in unsearched_words. phrases[] lists the searched PHRASES the listing forms across its indexed fields (text, traffic 0-100, words with the field each comes from): a word nobody types alone still earns coverage when it completes one, and removing it breaks the phrase. targeting.assessable is false when the listing holds no searched term at all, and then there is no targeting to judge. report is null on an app the audit has never reached, which is not a score of zero. The audit is kept up to date automatically, so this reads a stored result and answers in milliseconds: call it as often as you need. For visibility over time instead, use get_app_score_history; to score a listing that does not exist yet, use simulate_metadata.

Input Schema

NameRequiredDescriptionDefault
app_idYesThe application INTERNAL id: the "id" field of list_applications (numeric, e.g. "344"). Not its "app_id" field, which is the store bundle id.
include_wordsNoAdd the per-word table of every indexed field: name, traffic (0-100), difficulty (0-100), occurrences and status. STATUS values: "earning" (real search demand, and this field is credited for it), "already-used" (an earlier field already claimed it; the stores index a word once), "not-searched" (indexed, but nobody types it here), "in-phrase" (nobody types it alone, but it completes a searched phrase, named in its "phrase" with the traffic of that phrase; it earns coverage like a keyword), "pending" (no search data yet on this storefront), and on the Google Play long description "covered" / "missing" (does it repeat what the title and short description target) and "extra-reach" (a searched word it carries that no other field does). occurrences is only counted on the Google Play long description, where repetition is visible; it is null elsewhere, because a word is either in the field or not. Off by default: it is detail you rarely need to answer how a listing is doing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / include_words / description
      Previous value: -"Add the per-word table of every indexed field: name, traffic (0-100), difficulty (0-100), occurrences and status. STATUS values: \"earning\" (real search demand, and this field is credited for it), \"already-used\" (an earlier field already claimed it; the stores index a word once), \"not-searched\" (indexed, but nobody types it here), \"pending\" (no search data yet on this storefront), and on the Google Play long description \"covered\" / \"missing\" (does it repeat what the title and short description target) and \"extra-reach\" (a searched word it carries that no other field does). occurrences is only counted on the Google Play long description, where repetition is visible; it is null elsewhere, because a word is either in the field or not. Off by default: it is detail you rarely need to answer how a listing is doing."New value: +"Add the per-word table of every indexed field: name, traffic (0-100), difficulty (0-100), occurrences and status. STATUS values: \"earning\" (real search demand, and this field is credited for it), \"already-used\" (an earlier field already claimed it; the stores index a word once), \"not-searched\" (indexed, but nobody types it here), \"in-phrase\" (nobody types it alone, but it completes a searched phrase, named in its \"phrase\" with the traffic of that phrase; it earns coverage like a keyword), \"pending\" (no search data yet on this storefront), and on the Google Play long description \"covered\" / \"missing\" (does it repeat what the title and short description target) and \"extra-reach\" (a searched word it carries that no other field does). occurrences is only counted on the Google Play long description, where repetition is visible; it is null elsewhere, because a word is either in the field or not. Off by default: it is detail you rarely need to answer how a listing is doing."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint/destructiveHint/openWorldHint, so the safety profile is covered. The description adds substantive behavior beyond that: the result is stored and the audit refreshes automatically, so reads are sub-millisecond and non-rate-limited; report is null (not zero) for apps the audit never reached; targeting.assessable is false when no searched term exists.

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?

Dense and reasonably front-loaded — purpose first, then return shape, then axes/tier semantics, then sibling routing at the end. It is long and occasionally repetitive (the tier/verdict point is restated), but virtually every sentence is substantive, which matters because there is no output schema to carry the return-shape burden.

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?

With no output schema, the description carries the full return-value burden and does so thoroughly: it enumerates every reported structure (global, three axes, tier, fields[], phrases[], targeting{}, flags[], timeline[]) and explains sentinel states (empty/missing/truncated/unsearched/assessable). An agent can interpret the payload correctly without further documentation.

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 coverage is 100%, so both parameters are already documented in-schema, including the detailed include_words status vocabulary. The description adds only marginal parameter value (the 'attributable score' framing around app_id and the 'off by default, rarely needed' framing of include_words). Baseline 3 is correct when the schema does the heavy lifting.

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?

The first sentence states a specific verb and resource and draws a sharp contrast: 'how well its listing is WRITTEN, as opposed to how it currently ranks.' It also implicitly separates itself from the two sibling tools it names later, so an agent can distinguish it from get_app_score_history and simulate_metadata without opening any schema.

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?

Explicitly routes the agent: 'For visibility over time instead, use get_app_score_history; to score a listing that does not exist yet, use simulate_metadata.' It also gives a use-freely signal ('call it as often as you need') and warns that report=null is not a zero score, removing the main misinterpretation risk.

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