sensortower-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SENSORTOWER_API_KEY | Yes | Your SensorTower API key |
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 |
|---|---|
| sensortower_api_usageA | Monthly request quota for your user and organisation. This call is FREE and is the only endpoint that genuinely validates the API key -- /v1/{os}/apps returns 200 with full metadata even for a garbage token, so a revoked key looks healthy there and fails everywhere else. Call this first when anything returns 401. |
| sensortower_referenceA | Valid category ids, chart types, ad networks, review tags, sentiments, keyword types, audience segment formats and the metric-to-breakdown table -- plus the mapping from the OpenAPI contract's /v1/facets/metrics?suffix path keys to the real bundle= or metric= parameter. Entirely offline: 0 requests. Read this before guessing an enum; every /api/docs/static/*.json file the contract links to is dead. |
| sensortower_raw_getA | Escape hatch: any SensorTower path with arbitrary query parameters, raw JSON back. Handles auth, token redaction, gzip and retries. Use this for the ~50 endpoints without a dedicated tool -- ad creatives, network analysis, churn, cohort retention, session metrics, SDK data, webstore revenue, downloads-by-source. Do NOT pass auth_token. Deliberately sending a bogus enum value is the cheapest way to discover the valid ones: the 422 body enumerates them. |
| sensortower_app_metadataA | Name, publisher, categories, rating, version and -- critically -- the 24-hex unified_app_id that every unified endpoint (overlap, audience insights) requires. Batches up to 100 ids per request. Two traps: this endpoint does NOT validate the API key (a garbage token still returns 200), and an unknown id returns an empty list rather than an error. |
| sensortower_app_estimatesA | Download and revenue estimates per app, country and period. The three per-OS key sets (iOS iu/ir/au/ar, Android u/r, unified spelled out) are collapsed into app_id/country/date/downloads/revenue_usd, and revenue is converted from CENTS to USD. Widen the date range rather than looping: one request covering three months costs exactly what one covering a day costs. |
| sensortower_app_active_usersB | Active-user estimates for one or more apps over a date range. |
| sensortower_app_rankA | mode=current gives every category rank an app holds right now (one app id). mode=history gives the daily rank series for a specific category and chart type (needs category + chart_type_ids; get valid values from sensortower_reference). An unknown app id returns 422 'App not found.' here, unlike sensortower_app_metadata. |
| sensortower_app_version_historyA | mode=versions lists app version releases (the API returns a dict keyed by "YYYY-MM-DD HH:MM:SS UTC"; it is flattened here into dated rows, newest first). mode=store_listing lists which store-listing fields changed on which date (the API returns [date, {mostly nulls}] pairs; only the non-null fields are kept). |
| sensortower_app_demographicsA | Age and gender split of an app's users, with a category baseline for comparison. This is the App Analysis version and is generally licensed; the Audience Insights equivalent is a separate subscription. |
| sensortower_app_in_app_purchasesA | The top IAP SKUs for an app, with price and duration. iOS only -- there is no Android path for this endpoint. |
| sensortower_app_overlapA | Which other apps this app's users also use. Takes a 24-hex unified_app_id ONLY -- a store id returns an empty 200 and still costs a request. Get the unified id from sensortower_app_metadata. The API returns opaque ids; names are resolved for you (one extra request per 100 results). |
| sensortower_app_retentionA | Cohort retention over daily, weekly or monthly buckets, via /v1/facets/metrics. Note that plain |
| sensortower_top_chartsA | The App Store / Google Play top chart for one category, country and date. The API returns bare app ids in rank order with no names and no rank numbers -- both are added here. Get valid category and chart_type values from sensortower_reference; a bad value returns a 422 whose body is PLAIN TEXT listing the valid ones. |
| sensortower_top_appsA | The estimate-based leaderboard. measure=downloads|revenue queries the sales-estimate leaderboard; measure=dau|wau|mau queries the active-user one. Revenue comes back in CENTS and is converted to *_usd here. The 213-key custom_tags blob -- 94% of each row -- is dropped unless you ask for it. On iOS device_type is de-facto required, so it defaults to iphone. |
| sensortower_top_publishersB | Publisher-level leaderboard by downloads or revenue. Each row nests an apps[] array, and custom_tags hides inside those nested app records too -- both levels are stripped unless keep_custom_tags is set. |
| sensortower_store_summaryA | Category-level download and revenue totals over time -- the whole category, not per-app. games=true switches to the games_breakdown endpoint (same shape, game genres instead of store categories). Revenue converted from cents. |
| sensortower_market_sizeA | Market-wide totals sliced by a dimension -- category, region, device, game genre, art style, and so on. metric=store gives downloads and revenue (bundle=mobile_store_estimates), metric=usage gives active users and time spent (bundle=mobile_usage_estimates). Any breakdown ending in ,date needs date_granularity. |
| sensortower_top_advertisersA | Share-of-voice leaderboard for a network and category. role=advertiser lists who is buying; role=publisher lists who is showing. Supply app_id to look up one app's position instead of the whole board (returns page, rank and sov). Note the network vocabulary is per-endpoint: 'Facebook' is rejected here but valid on network_analysis. |
| sensortower_top_creativesB | The most-seen ad creatives for a network and category. Payloads are large and full of asset URLs -- use fields/limit aggressively. |
| sensortower_featuredA | scope=today returns the Apple "Today" tab stories (newest first). scope=category returns the apps featured in one category's sections. Both are iOS only -- there is no /v1/android/featured/... path, it returns an HTML 404. A category-week is roughly 1 MB before artwork URLs are stripped, so keep the date range short. |
| sensortower_featured_historyA | mode=creatives lists every featuring the app received, with position and download attribution. mode=impacts aggregates occurrences and downloads by country or type; its *_series arrays carry NO dates (index 0 is start_date, one element per day), so set series=true to have them zipped back onto real dates. Invalid filters here return a 200 with empty arrays rather than a 422, so an empty result may just mean a bad filter. |
| sensortower_keywordsA | by=keyword answers 'which apps rank for this term' (bundle=aso_keyword_research). by=app answers 'which terms does this app rank for' (bundle=aso_top_keywords) -- that bundle defaults to ALPHABETICAL order, so this tool always sends order_by=est_keyword_downloads:desc unless you override it. |
| sensortower_keyword_historyC | mode=timeseries gives one metric per keyword per day (this path takes metric=, NOT bundle=). mode=rank_overview gives how many of an app's keywords sit in each rank bin (1, 2-3, 4-5, 6-10, ...). |
| sensortower_reviewsA | Reviews with rating, sentiment, tags, version and language. The API also returns a |
| sensortower_ratingsC | Rating counts and averages. bundle=ratings_incremental gives per-period new ratings; ratings_cumulative gives the running total. Plain |
| sensortower_review_breakdownA | Aggregate review counts. by=rating answers 'how do the stars break down', by=sentiment 'how happy are they', by=tag 'what are they complaining about'. Each accepts a plain breakdown or one prefixed with date, region, language or app_version. |
| sensortower_search_adsA | by=term: who is buying ads on a search term. by=app: which terms an app buys, with traffic and share of voice. by=history: one app's daily share of voice on one term (the API returns a dict keyed by app-id string; it is flattened here). iOS only -- Apple Search Ads has no Android equivalent. |
| sensortower_audience_demographicsA | The age/gender grid for an audience segment (metric=est_audience_demographic_share, breakdown=age,gender). Shares over the whole segment sum to 1.0. The optional age and gender filters SUBSET WITHOUT RENORMALISING -- filtered rows keep the same values they had in the full grid, so they will not sum to 1. Age values in the response are bucket starts: 18=18-24, 25=25-34, 35=35-44, 45=45-54, 55=55+. |
| sensortower_audience_affinityA | Affinity of one audience segment for personas, social ad channels, ad categories, advertisers (brands), app categories or other apps. Pick the dimension and this maps it to a valid metric/breakdown pair. MOST OF THESE ARE LICENSED SEPARATELY: a 401 saying 'not authorized for the user' means your subscription does not cover that metric, not that the key is bad -- do not retry, pick another dimension. Note also that breakdown validation runs BEFORE the authorization check, so a 422 tells you nothing about entitlement. |
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 29 tools
Each tool maps to a distinct resource+action, and the descriptions explicitly pre-empt the trickiest overlaps (app_demographics vs audience_demographics licensing split, reviews vs ratings vs review_breakdown, app_active_users vs top_apps leaderboards). A few boundaries remain thin (app_retention vs app_active_users, featured vs featured_history) but descriptions make them selectable.
Every tool uses a uniform sensortower_ snake_case prefix followed by a readable noun phrase, with grouping prefixes (app_*, top_*, audience_*, keyword*) that telegraph the resource family. No mixed conventions or ambiguous verbs anywhere.
29 tools is on the heavy side, but the descriptions justify most of them as distinct curated endpoints over a very large analytics API, with sensortower_raw_get explicitly serving the ~50 uncovered endpoints. Still, at nearly 30 dedicated tools it sits above the comfortable range and invites selection errors.
The surface covers apps, estimates, ranks, demographics, retention, IAP, overlap, charts, leaderboards, publishers, store/market aggregates, advertisers/creatives, featured, keywords, reviews/ratings, search ads and audience segments. The raw_get escape hatch plus the offline reference tool close any residual gaps.