@applyra/mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| APPLYRA_API_KEY | Yes | Your 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
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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 |
| 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. |
| 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 |
| 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 |
| 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
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 25 tools
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.
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.
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.
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.