Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
APPLYRA_API_KEYYesYour Applyra API key, generated at https://www.applyra.io/dashboard/api

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_applicationsA

List all tracked mobile applications. Returns each app with its store metadata: title, description, app_id (bundle ID), store (ITUNES or GPLAY), country, lang (BCP-47), icon URL, screenshots, developer name, genre, version, rating score, number of ratings, the count of tracked keywords, and aso_health (the listing audit: global score plus its coverage, targeting and appeal axes, or null on an app the audit has not reached yet; get_aso_health returns the breakdown behind it). Usually the first call of a workflow: the numeric internal ID it returns is what track_keywords, add_competitor, get_app_score_history and the other app-scoped tools expect, whereas add_application takes the store bundle ID instead. Read-only.

add_applicationA

Track a new mobile application by its store bundle ID. The app metadata is fetched from the store, an initial visibility score is computed, and the app is linked to the user workspace. Counts against the plan app cap.

list_keywordsA

List tracked keywords with ASO metrics. Returns each keyword with: keyword text, store, country, lang, difficulty_score (0-100), traffic_score (0-100), current_rank, ahead/behind (the apps ranked immediately above and below yours), the top 5 apps ranking for this keyword (in ranking order, rank 1 to 5), is_favorite flag, and the tracking start date. current_rank comes from the latest daily ranking snapshot and is null when the app is not in the top 100 for that keyword, in which case ahead and behind are null too. A null rank always means "not ranked", never "unknown": the tool errors out rather than returning partial rank data. Paginated.

inspect_keywordA

Deep-analyze any keyword (even ones you don't track). Returns difficulty_score (0-100), traffic_score (0-100), KEI with score and level (e.g. "good"), the top 20 apps currently ranking for it (with rank, app_id, title, icon, genre, rating), related keyword suggestions from search and keyword sources, and whether you already track this keyword. Inspecting a keyword you already track does not consume the inspection quota.

list_keyword_inspectionsA

List the keywords you have previously inspected, with their last inspection date and current difficulty/traffic scores. Useful to revisit past keyword research without consuming the inspection quota again.

get_keyword_rank_historyA

Get the daily rank history of one tracked keyword, with one series per app that tracks it. Returns keyword, store, country, lang, the resolved from/to dates, and apps[] entries holding app_id, app_title and history[] of { date (YYYY-MM-DD), rank }, where rank is null on days the app did not rank. Defaults to the last 30 days. The window is capped at 400 days and at the plan history depth: a start date beyond it returns a PLAN_LIMIT error. Reversed dates are swapped and future dates are clamped to today. Pass keyword_id from list_keywords, and app_id to narrow the output to one app. For the visibility of a whole app rather than one keyword, use get_app_score_history.

set_keyword_favoriteA

Mark or unmark a tracked keyword as favorite for a specific app. Favorites are stored per tracking row (profile + app + keyword), so a keyword tracked across multiple apps has independent favorite states. Both keyword_id and app_id come from list_keywords results.

track_keywordsA

Track up to 20 new keywords for one of your applications in a single call. Each keyword triggers an immediate ranking fetch. Already-tracked keywords return a per-keyword error in results; previously removed keywords are reactivated automatically. Use app_id from list_applications results.

untrack_keywordA

Stop tracking a keyword for the specified app (soft delete). The historical ranking data is preserved; re-adding the same keyword reactivates the row. Idempotent: calling on an already-removed row returns success.

get_app_score_historyA

Get the daily visibility score history of one application. The visibility score (0-100) summarises how discoverable the app is across its tracked keywords. Returns app_id, app_title, the resolved from/to dates, and history[] of { date (YYYY-MM-DD), score }, where score is null on days with no snapshot. Defaults to the last 30 days. The window is capped at 400 days and at the plan history depth: a start date beyond it returns a PLAN_LIMIT error. Reversed dates are swapped and future dates are clamped to today. Pass the numeric internal ID from list_applications, not the store bundle ID. For one keyword rank over time, use get_keyword_rank_history.

get_aso_healthA

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.

check_metadataA

Check draft listing text against the stores' own rules, before spending a run measuring it. Per field: the length as the STORE counts it (UTF-16 code units, which is not what a character count gives you in most languages), the limit, what is left, and warnings[]. warnings[].level is "error" (the store would refuse this as it stands), "warning" (it costs you something, or a reviewer may object) or "info" (worth knowing, often counter-intuitive: emoji are allowed in a Google Play description but banned in the app name). warnings[].rule names the policy when one fired: "price", "ranking", "play-program", "call-to-action", "kids", "rival-platform", or null for a limit or formatting warning. THE TWO STORES ARE NOT SYMMETRICAL, and this is the most actionable thing the tool tells you: Google NAMES forbidden words and rejects, so the same term is an error there; Apple publishes no list and a reviewer decides, so it is a warning. A draft can be perfectly valid on one store and refused on the other. valid is false only when at least one field carries an ERROR: a draft can be valid and still carry warnings worth acting on, so read them. notes[] carries anything wrong with the request itself, such as sending a keywords field to Google Play, which has none. On the iOS keywords field it also returns keywords{terms, duplicates, too_short, phrases, wasted_on_spaces, wasted_on_duplicates}: phrases are multi-word entries, which Apple splits apart and recombines itself, so they gain nothing over their words. It is pure arithmetic over the text you pass, with no store lookup, so it answers instantly: run it on every draft you write, in a loop if that helps, and call simulate_metadata only once it comes back valid.

simulate_metadataA

Score a listing that does not exist yet, on the same engine that audits the real ones, and see the gain or loss against the app's current score. WITH app_id: every field you leave out is read from that app's live listing AND its real context (rating, screenshots, age, languages), so { app_id, title } is a complete request and the delta is meaningful. This is the mode to use to answer "is my draft better than my listing". WITHOUT app_id: you must pass store, country and lang, and the context defaults to a listing NOBODY HAS PUBLISHED: no rating, no screenshot, one language. That deliberately floors the appeal axis, so the global score is NOT comparable to a real app's score and you must not present it as one. Compare the coverage axis instead, or pass context yourself to describe the app you have in mind. context works in both modes: any key you send overrides, any key you omit keeps the app's value (or the blank default). Returns app (null without app_id), aso_health with the three axes and the tier, delta against the app's stored score (null for a draft from scratch, and each axis is independently null when it was never computed), flags[], the saved run, and notes[] for anything wrong with the request that did not stop it (a kw_field sent for a Google Play listing, which has none, is ignored and reported there). words_probed is how many words the run weighed; words_fetched is how many of those had to be read from the store for the first time. words_fetched: 0 means everything was already known and the call was fast; a high one is why a call took several seconds, and it warms the cache for everyone afterwards. Expect a few seconds per call. Check the draft with check_metadata first, and change something meaningful between two calls rather than polling it. Re-read a past run in full with get_metadata_simulation, or list them with list_metadata_simulations.

list_metadata_simulationsA

List the listing drafts already scored on this account, newest first, whether they were run from here or from the Metadata Simulator in the dashboard. Each row holds the draft TITLE ONLY, its market, the score it reached with the three axes, the app score it was measured against, whether it differed from the live listing, and how many times it has been re-run. It does NOT carry the subtitle, keywords field or description: pass a row's "id" to get_metadata_simulation to read a draft in full. Use this to find a past score without re-running it.

get_metadata_simulationA

Read one saved listing draft in full: the four fields it was scored on, the context it assumed, the score it reached, and the findings behind it. This is what list_metadata_simulations cannot carry, and it is what makes a past run worth picking up: the text is here. Pass the "id" of a row from list_metadata_simulations, or the "saved.id" a simulate_metadata call returned. Read-only and instant.

list_competitorsA

List competitor tracking pairs. Each pair holds your app (id, app_id, title, icon, store only) and the competitor app with its full store metadata (title, description, url, icon, screenshots, developer_name, genre, version, score, ratings), plus both apps' visibility scores (app_score vs competitor_score, 0-100) for direct ASO comparison. Use list_applications to get the full metadata of your own app.

add_competitorA

Add a competitor app to one of your applications, identified by the competitor's store bundle ID. The competitor metadata is fetched from the store and ranking entries are backfilled for every keyword tracked on the main app.

remove_competitorA

Remove a competitor relationship by its internal relation ID (the id field returned by list_competitors or add_competitor — note that this is the relation row id, not the competitor app id).

run_autocompleteA

Fetch autocomplete suggestions from the App Store or Google Play for a given prefix (1-60 characters). Useful to discover what users are searching for that starts with a given seed. Consumes one autocomplete query and one API request.

list_autocomplete_historyA

List the autocomplete queries you have previously run, with the prefix, store, country, lang, suggestion count and last query date.

run_niche_analysisA

Run a niche analysis on a topic: discovers relevant keywords, clusters them into sub-niches, and scores each cluster's opportunity. Returns clusters with their keywords, opportunity scores, intent type, and an app concept suggestion. Cache hits (recent identical analyses, less than 7 days old) are returned instantly without consuming the niche analysis quota. Fresh analyses can take a few minutes.

list_niche_analysesA

List the niche analyses previously run, with topic, store, country, lang, cluster count, keyword count, top opportunity score and creation date. Paginated through page and per_page. Read-only: it re-reads work already done, so call it before run_niche_analysis to check whether a topic was already covered. It returns summary rows only, not the clusters and keywords themselves.

top_chartsA

Get a store top-chart ranking (App Store or Google Play) for a country, category and collection, with daily rank movement. Returns the snapshot date and ranked apps (rank, app_id, apple_id, title, developer, icon, rating, price, currency, delta vs. yesterday, is_new). Category: pass "OVERALL" (default) for the overall chart, or a store category value (iTunes genre id e.g. "6014" for Games, or a Google Play category e.g. "GAME"). Collection: free (default), paid, or grossing.

list_top_chart_categoriesA

List the categories and collections supported by the top_charts tool, per store. Use a returned category "key" (e.g. "OVERALL" for the overall chart, or a store value like "6014" / "GAME") and a collection (free, paid, grossing) as inputs to top_charts.

get_account_usageA

Get current account usage and plan limits: number of applications, keywords, competitors, keyword inspections, niche analyses, autocomplete queries and metadata simulations used vs. allowed, plus API request count for the current billing period.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.2/5.0

Scored across 25 tools

Disambiguation5/5

Each tool targets a distinct resource+action, and descriptions actively differentiate near-neighbors (e.g. get_keyword_rank_history vs get_app_score_history, check_metadata vs simulate_metadata, list vs get_metadata_simulation). The keyword-inspection pair (inspect_keyword vs list_keyword_inspections) is also cleanly split between analysis and history. No two tools appear to do the same thing.

Naming Consistency4/5

Overwhelmingly consistent snake_case verb_noun pattern (add_competitor, list_applications, run_niche_analysis, get_aso_health), with a few related variants like track_keywords/untrack_keyword that still read clearly. The only real deviation is top_charts, which drops the verb prefix. Minor, but it breaks the otherwise uniform convention.

Tool Count4/5

25 tools is on the heavy side, but the ASO domain is genuinely broad (apps, keywords, competitors, metadata auditing/simulation, niche analysis, top charts, account usage), and each tool maps to a distinct function with little redundancy. Slightly over what's ideal but defensible for the scope.

Completeness4/5

Coverage is strong: full add/list/remove for competitors, complete track/untrack/list/favorite for keywords, validate+simulate+retrieve lifecycle for metadata, and run/list for niche analyses and charts. The main gap is app lifecycle management—there is no remove_application or update_application, so a tracked app can be created but not edited or deleted.

Maintenance

ActivityMaintained
ResponsivenessNo issues