Skip to main content
Glama

get_aso_health

Read-only

Audit how well a tracked app's store listing is written: get a 0-100 ASO health score across coverage, targeting and appeal, plus maturity tier, flags and release timeline.

Instructions

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. 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

TableJSON 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), "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. Addedv1.5.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true; the description adds substantial behavioral context the annotation cannot: the audit is auto-maintained and read from a stored snapshot, report is null when never audited (explicitly 'not a score of zero'), fields[].text is truncated with a truncated flag, and verdicts shift meaning with tier. This is exactly the extra context annotations leave uncovered.

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 front-loaded: the core purpose and attribution rationale come first, followed by output-field semantics and then the sibling routing. It is long, but with no output schema nearly every sentence carries return-value semantics that would otherwise be unavailable, so little is wasted.

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 and only a readOnly annotation, the description must carry the full return-value burden, and it does: it enumerates axes, tier behavior, field states, truncation, verdict enum, ungraded/unsearched counters, assessable=false, and the null-report case. An agent has everything needed to call it and interpret the result.

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 the baseline is 3, but the description adds guidance beyond the schema by explaining include_words is off by default and 'detail you rarely need to answer how a listing is doing,' which helps an agent decide whether to set it.

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 ('Get the full ASO Health audit of one tracked app') and immediately scopes it against the ranking concern ('how well its listing is WRITTEN, as opposed to how it currently ranks'). Names the exact field contents it returns, so an agent can distinguish it from list_applications and get_app_score_history without opening anything.

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 states the call is cheap and safe to repeat ('reads a stored result and answers in milliseconds: call it as often as you need'), removing hesitation about frequency.

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