AppTail – ASO & Keyword Research

Discover Keywords

discover_keywords

Terms an app could be tracking but is not, merged from every source and each labelled with where it came from: what tracked competitors rank for, what the store's similar apps rank for, what those competitors put in their own titles and subtitles, what the store's own mining surfaced, and — reading the listing cold — what the app's own title, subtitle and description suggest. The last is the only source that works on an app added minutes ago; listing is the only one that can surface a phrase nobody has ranked for yet, and it offers a phrase only when two or more rivals publish it and Apple reports somebody searching it. Pass contains to also match terms already in AppTail's database. Already-tracked and already-dismissed terms are never returned. This is a list of candidates, not a measure of coverage: for how much of a niche's vocabulary the account is missing, and which holes matter most, call get_landscape and read term_gap. Discovery can persist shared suggested keyword records, cache generated suggestions, and queue background popularity collection. It does not add those terms to account tracking.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Max suggestions, most-searched first. Default 60, capped at 200. The answer always says how many there were.
`app_id`	Yes	Apptail app id to suggest for. get_account for the user's own apps. Suggestions are derived from this app's listing, its rivals and its neighbours, so they are only meaningful for the app they were asked about.
`source`	No	Which sources to read. Omit for all five that need no argument — `competitors`, `similar`, `listing`, `store`, `ai`. `corpus` is a text match against terms AppTail already holds and does nothing without `contains`, which is why "all" does not silently include it. An unknown name is refused rather than ignored.
`country`	No	Storefront to suggest for (e.g. US, DE). Defaults to the app's primary storefront — which is only one of them: an app localized into several languages is searched for in several storefronts, so call once per entry in get_app's `listing_storefronts`. Discovery is per storefront and never a blend: a German term is not a translation of an English one — `spritverbrauch` beats `kraftstoffverbrauch` by a margin no dictionary would tell you.
`contains`	No	Only terms containing this text. With `source: ["corpus"]` this is a search of AppTail's keyword database. Note it searches terms AppTail holds, not the App Store: a phrase nobody has ever tracked returns nothing, and to start tracking a brand-new term you pass it straight to add_keywords.

Output Schema

TableJSON Schema

Name	Required	Description
`count`	Yes	Suggestions returned.
`total`	Yes	Suggestions found before the cap.
`app_id`	Yes	The app these suggestions are for.
`country`	Yes	The storefront they apply to.
`sources`	Yes	Sources actually read. A source not listed here was not consulted.
`app_name`	No	Its name.
`by_source`	Yes	How many suggestions each source produced, keyed by source name; a source with none is absent. Read this before reporting an empty answer. Five of the six need something on file — rivals, the store's similar-apps list, a mining job that runs fortnightly — so zero beside `competitors` is a fact about the account, not about the niche, and the fix is add_competitors rather than a different question.
`truncated`	Yes	True when `count` is below `total`. Say the list is partial rather than presenting it as everything worth tracking.
`console_url`	No	The app's keyword screen in the console, where the same list can be reviewed and added by hand.
`suggestions`	Yes	The terms, most-searched first. Add them with add_keywords using their `keyword_id`, never their text.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description goes further, disclosing the actual side effects — persisting shared suggested keyword records, caching suggestions, queueing background popularity collection — and clarifies the boundary that it does not modify account tracking.

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 with the core definition and the get_landscape alternative before the caveats. It runs long for a single description and repeats a few points already in the schema, but nearly every sentence carries decision-relevant information.

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?

An output schema exists, so return values need no explanation. The description still covers all the complexity an agent needs: the five default sources, why corpus is excluded from 'all', the never-returned already-tracked/dismissed terms, and the per-storefront constraint.

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 real meaning beyond the schema: `listing` is the only source that can surface an unranked phrase and only when two-plus rivals publish it, `corpus` requires `contains`, and storefront selection is never a blend. Some of this duplicates the schema text, hence not a 5.

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 — unearthing candidate terms an app could track but is not — and enumerates the provenance of each candidate. It is clearly distinguishable from get_keywords (tracked terms) and get_landscape (coverage gaps), which it names explicitly.

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?

Routes the agent to siblings by condition: get_landscape/`term_gap` for coverage measurement, add_keywords to actually track a new term, and it explicitly states discovery does NOT add terms to tracking. It also tells the agent to call once per storefront using get_app's `listing_storefronts`.

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?