Skip to main content
Glama
meyusufdemirci

App Store Operator

by meyusufdemirci
OverviewSchemaRelated ServersScoreDiscussions
JavaScript

App Store Operator

App Store competitive intelligence, inside Claude.

App Store Operator is an MCP server that brings App Store research directly into your AI assistant. Instead of switching to a dashboard, you ask Claude for ranked keyword results, competitor download and revenue estimates, or App Store Connect-ready In-App Event copy — and get the answer in the same conversation where you are making the decision.

Built for indie iOS developers who want research inside their workflow rather than in another browser tab. Free and open source (MIT). A lightweight alternative to SensorTower, AppTweak, and AppFollow for iOS-only competitive research.

claude mcp add --transport stdio app-store-operator -- npx -y app-store-operator@latest

→ app-store-operator.com · Setup guide

What it does

Searches the App Store for competing apps on a given keyword and pulls detailed analytics from SensorTower — downloads, revenue, ratings, top markets, publisher info, and more.

search_app_store and prepare_iae work with no account at all. research_rivals and get_app_details open a browser once for a free SensorTower sign-in, then reuse that saved session — no paid plan, no API key.

Everything the server exposes — four tools, six prompts, seven resources — is read-only. Nothing writes to your App Store Connect account, to SensorTower, or anywhere but a local cache file.

Related MCP server: meta-ads-mcp-server

Tools

research_rivals

Finds the top 3 apps for a keyword and returns a full metrics report for each.

Parameter

Type

Description

keyword

string

Search term to look up (e.g. meditation, psikoloji)

country

string

Two-letter country code (e.g. us, tr, gb)

Returns for each competitor:

  • App Store & SensorTower URLs

  • Worldwide and last-month downloads & revenue

  • Rating score and rating count

  • Publisher, categories, top markets

  • Release date, last updated, supported languages

  • In-app purchases and ad network presence

Cached for 24 hours, so asking again about the same keyword and country costs nothing and opens no browser.

search_app_store

Searches the App Store for a keyword and returns ranked results as a markdown table — instantly, no SensorTower required.

Parameter

Type

Description

keyword

string

Search term to look up

country

string

Two-letter country code

limit

number

Number of results to return (1–25, default 3)

Use this to discover which apps rank before deciding which to analyse. Follow up with get_app_details for analytics on specific apps.

get_app_details

Fetches SensorTower analytics for one or more app IDs you already have.

Parameter

Type

Description

app_ids

array

Numeric App Store IDs (e.g. from search_app_store)

country

string

Two-letter country code

Returns for each app:

  • Downloads and revenue (worldwide + last month)

  • Rating score and rating count

  • Publisher, categories, top markets

  • Release date, last updated, supported languages

  • In-app purchases and ad network presence

Never cached — every call scrapes fresh, at roughly 10–20 seconds per app ID.

prepare_iae

Generates iOS App Store In-App Event (IAE) copy — 3 variations in the target language, then a final report.

Parameter

Type

Description

keywords

array

Ordered keywords by priority (index 0–2 = Tier 1, 3–6 = Tier 2, 7–9 = Tier 3)

locale

string

Target locale (e.g. en-us, en-gb, de-de, tr, ja, ko)

event_purpose

string

What the event is about and why users should care

audience

string

Target audience (e.g. students, professionals, parents)

event_context

string

Real-world hook tying the event to a moment (e.g. a holiday, season)

goal

string

Primary conversion goal (e.g. attract new users, boost engagement)

tone

string

Copy tone: Engaging, Playful, Motivational, Authoritative, Calm, or Urgent

Returns: a structured brief used to generate 3 copy variations, each with event name (≤30 chars), short description (≤50 chars), and long description (≤120 chars).

Any field SensorTower does not expose, or keeps behind its paywall, comes back as N/A. The server reports the gap rather than filling it, and the prompts below tell the assistant to do the same.

Prompts

Six ready-made workflows that already chain the tools above, so you don't have to describe the sequence yourself. In Claude Code they appear as slash commands; other clients surface them in a prompt picker.

Prompt

Arguments

What it does

competitor_snapshot

keyword, country

Pulls rival analytics for a keyword, then reads out who owns it and how contested it is

keyword_shortlist

seed_keyword, country, count?

Expands a seed keyword into candidates, tests each against live search results, and ranks them attack / watch / skip

app_teardown

app_ids, country

Teardown of known apps — scale, standing, monetisation, reach, momentum, acquisition

positioning_gap

keyword, country, my_app_id

Puts your app on the same measuring stick as the incumbents and separates behind from attackable

metadata_rewrite

app_name, keyword, country, must_keep?

Three name / subtitle / keyword-field variations, character-counted against Apple's limits

in_app_event

event_context, locale, keywords?, audience?, tone?

Runs the full In-App Event flow, asking for whatever prepare_iae still needs

Arguments marked ? are optional. Every prompt tells the assistant not to invent figures and, where SensorTower is involved, not to quietly fall back to a weaker tool when login is required.

Resources

Reference data and local state a client can attach as context without spending a tool call on it.

URI

Type

Contents

asops://guide/tool-selection

markdown

Which tool to use, what each costs, how the SensorTower login works

asops://reference/country-codes

markdown

Two-letter storefront codes by region

asops://reference/aso-fields

JSON

App Store Connect character limits and which fields are indexed for search

asops://reference/iae-fields

JSON

In-App Event limits, artwork sizes, copy rules, keyword tiers

asops://reference/iae-locales

JSON

Every locale prepare_iae accepts — generated from the same table the tool validates against

asops://cache/research

JSON

What has already been researched on this machine, and whether it is still fresh

asops://cache/research/{country}/{keyword}

JSON

One cached research_rivals result, without re-scraping

Nothing here leaves your machine: the reference resources are static, and the two cache resources read ~/.app-store-operator/cache.json.

Requirements

  • Node.js v18+

  • A desktop session for research_rivals and get_app_details. They drive a real, visible Chromium window so you can sign in to SensorTower, so they need a display — they do not work over plain SSH or inside a container. The other two tools have no such requirement.

  • Disk space for Chromium. Installing the package downloads a Playwright Chromium build (a few hundred MB) via a postinstall step. If that step fails, the server installs it on first use instead; you can also run npx playwright install chromium yourself.

Usage

As an MCP server (Claude Code / Claude Desktop / OpenAI Codex)

Claude Code — run this command once:

claude mcp add --transport stdio app-store-operator -- npx -y app-store-operator@latest

Claude Desktop — add to your MCP config:

{
  "mcpServers": {
    "app-store-operator": {
      "command": "npx",
      "args": ["app-store-operator@latest"]
    }
  }
}

OpenAI Codex — run this command once:

codex mcp add app-store-operator -- npx -y app-store-operator@latest

Codex stores MCP servers in ~/.codex/config.toml. If you prefer to edit it directly:

[mcp_servers.app-store-operator]
command = "npx"
args = ["-y", "app-store-operator@latest"]

# Optional but useful for SensorTower scraping flows
startup_timeout_sec = 20
tool_timeout_sec = 180

Then restart Codex or start a new thread, and ask things like:

  • Research rivals for "hairstyle" in the GB App Store

  • Search the App Store for "beard style" in France

  • Prepare an in-app event for a summer hairstyle campaign in en-gb

No installation step needed — npx fetches and runs the package automatically.

The server communicates over stdio and is designed to be invoked by an MCP client. It advertises server-wide instructions during initialize so clients route between the tools correctly, and returns an MCP tool error when SensorTower login is required.

Configuration

Both settings are optional environment variables on the server process.

Variable

Default

What it does

ASO_CACHE_TTL_HOURS

24

How long a research_rivals result stays fresh in the local cache before it is scraped again

ASO_DEBUG_RATINGS

unset

Set to 1 to print SensorTower's ratings panel to stderr when a rating score or count comes back N/A — useful when reporting a scraping bug

In a container

The repo ships a Dockerfile built on Playwright's official image:

docker build -t app-store-operator .
docker run -i --rm app-store-operator

The server speaks JSON-RPC over stdio, so no port is exposed — point your MCP client at the container's stdin/stdout. Note that a container has no display: search_app_store and prepare_iae work there, but the two SensorTower tools cannot open a login window and will fail rather than prompting you to sign in.

How it works

  1. Searches the App Store for the keyword and country, and looks up any app IDs you passed directly against Apple's public iTunes Lookup API

  2. For each app, drives a Chromium browser to scrape SensorTower analytics

  3. Extracts the metrics and returns a compiled report

SensorTower data is scraped via Playwright because it is rendered client-side.

A browser window will open. This is deliberate, not a bug: SensorTower requires a login, so the first run opens a visible window for you to sign in. The session is saved to ~/.app-store-operator/profile and reused on every later call, so you only log in once. If a tool reports not_logged_in, finish signing in on that window and run the tool again.

Results from research_rivals are cached for 24 hours in ~/.app-store-operator/cache.json — override the TTL with the ASO_CACHE_TTL_HOURS environment variable.

Limitations

  • iOS only. Nothing here covers Google Play or Android.

  • Read-only. No tool changes anything in App Store Connect or on SensorTower.

  • research_rivals is fixed at the top 3 results. Use search_app_store (up to 25) and then get_app_details when you need a wider set.

  • Scraping is brittle by nature. SensorTower renders its dashboard client-side and changes its markup without notice; when it does, affected fields return N/A until the selectors are updated. A single app failing never fails the whole call.

  • SensorTower's free tier decides what you see. Paywalled figures come back as N/A.

Privacy Policy

Full policy: https://app-store-operator.com/privacy

App Store Operator runs entirely on your machine. There is no backend, no telemetry, and no analytics — the author collects, receives, and stores nothing about you or your usage.

What each tool sends, and where:

Tool

Account

What leaves your machine

search_app_store

None

Keyword and country code → Apple's public App Store search

prepare_iae

None

Nothing — pure local computation, contacts no external service

research_rivals

Free SensorTower

Keyword and country code → Apple, then SensorTower via your own browser session

get_app_details

Free SensorTower

App Store app IDs → Apple's public lookup API and SensorTower

What is stored locally:

  • ~/.app-store-operator/cache.json — cached results, expiring after 24 hours by default (ASO_CACHE_TTL_HOURS)

  • ~/.app-store-operator/profile — the Chromium profile holding your SensorTower session

You type your SensorTower credentials into SensorTower's own page in a browser window on your machine. The server never reads or stores your password, and the author never receives it.

Deleting everything — no request to the author, nothing to wait for:

rm -rf ~/.app-store-operator

Apple and SensorTower are independent third parties with their own policies. This project is not affiliated with either.

Project structure

src/
├── index.js                    # MCP server setup and request handlers
├── shared.js                   # App Store lookup + SensorTower scraping
├── cache.js                    # 24h local cache (research_rivals only)
├── prompts.js                  # the six prompt workflows
├── resources.js                # reference data + cache resources
└── tools/
    ├── research-rivals.js      # research_rivals tool
    ├── search-app-store.js     # search_app_store tool
    ├── get-app-details.js      # get_app_details tool
    └── prepare-iae.js          # prepare_iae tool
scripts/postinstall.js          # installs Playwright Chromium on install
scripts/sync-version.js         # syncs server.json, manifest.json and CHANGELOG.md on release
test/smoke-test-mcp.js          # stdio smoke test
server.json                     # MCP registry manifest
manifest.json                   # Claude Desktop / MCPB bundle manifest
Dockerfile                      # container build (no display: search + IAE tools only)

Development

No build step and no linter — clone it, npm install, and run npm start to boot the server over stdio.

The smoke test verifies the server boots and exposes everything it should. It checks initialize (including the server instructions and the advertised version), tools/list, prompts/list, prompts/get, resources/list, resources/templates/list, and reads every resource, failing if one declared as JSON does not parse. It makes no network calls and opens no browser:

npm run smoke

Releases are tag-driven: write the notes under ## Unreleased in CHANGELOG.md, run npm version <patch|minor|major> — which syncs the version into server.json and manifest.json and renames that heading to the new version for you — then push with --follow-tags. GitHub Actions runs the smoke test, publishes to npm and the MCP registry, and creates the release from that changelog section. The bump refuses to run while ## Unreleased is empty.

Contributions are welcome — open an issue or a pull request at github.com/meyusufdemirci/app-store-operator.

License

MIT © Yusuf Demirci

Available Tools

4 tools
get_app_detailsGet App AnalyticsA
Read-only

Fetch SensorTower analytics for one or more App Store app IDs. Returns downloads, revenue, ratings, publisher info, markets, and more for each app.

Use this when you already have app IDs (e.g. from search_app_store) and want detailed analytics for only a subset of them — avoiding unnecessary scrapes for apps you don't need. Use research_rivals instead for a single convenience call that searches and fetches analytics together. Do not use this for Google Play or Android apps — it takes numeric iOS App Store IDs only.

Requires a SensorTower account. The server opens a real Chromium window on the user's machine; the first run needs the user to log in there, and the session is reused from then on. If there is no session the call returns an error result carrying {"error": "not_logged_in"} and leaves the window open — tell the user to log in, then call again. Results are never cached, so every call scrapes fresh and costs roughly 10–20 seconds per app ID.

Returns JSON:

{
  "country": "us",
  "fetchedAt": "2026-04-21T10:00:00.000Z",
  "apps": [
    {
      "rank": 1,
      "name": "App Name",
      "appStoreUrl": "...",
      "sensorTowerUrl": "...",
      "downloads": "<5K",
      "revenue": "<$5K",
      "rating": { "score": "4.7", "count": "1,234" },
      "publisher": "Publisher Name",
      "categories": "Health & Fitness",
      "topMarkets": "United States, United Kingdom",
      "releaseDate": "Jan 1, 2020",
      "lastUpdated": "Mar 15, 2026",
      "languages": "English, Spanish",
      "inAppPurchases": "Monthly · $9.99",
      "publisherCountry": "United States",
      "advertisingNetworks": "N/A"
    }
  ]
}

Fields missing or gated behind a paywall will be "N/A". A single app failing to scrape is not fatal — that app comes back with "N/A" fields rather than failing the whole call.

ParametersJSON Schema
NameRequiredDescriptionDefault
app_idsYesList of numeric App Store app IDs, as strings (e.g. ["123456", "789012"]). Each is the digits from an apps.apple.com URL's `id` segment, without the `id` prefix.
countryYesTwo-letter App Store country code (e.g. us, gb, tr)

TDQS

A4.6/5.0
Behavior5/5

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

Discloses behavioral traits beyond annotations: opens a real Chromium window, requires user login, session reuse, no caching, ~10-20 second cost per app ID. Explains error handling (non-fatal per-app failures, 'not_logged_in' error) and that missing/gated fields return 'N/A'. No contradiction with annotations.

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?

Well-structured with clear sections: purpose, usage guidelines, behavioral notes, and return format. Some redundancy (e.g., 'not for Google Play' repeated). Could be slightly trimmed but overall efficient.

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?

Very complete for a complex tool: provides full JSON return format, explains missing/gated fields, partial failures, use of Chromium, login flow, and performance characteristics. No output schema is needed given this level of detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions. The description adds minor context (app IDs come from 'search_app_store', must be numeric without 'id' prefix) but does not significantly extend beyond schema. Baseline 3 is appropriate.

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?

The description clearly states it fetches SensorTower analytics for one or more App Store app IDs, listing specific data points (downloads, revenue, ratings, etc.). It distinguishes itself from siblings like 'search_app_store' (for searching) and 'research_rivals' (combined search+analytics).

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 when to use (when app IDs are known) and when not (not for Google Play/Android). Provides alternatives ('research_rivals') and prerequisite: SensorTower account login. Also explains first-run login requirement and how to handle 'not_logged_in' error.

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

prepare_iaePrepare In-App Event CopyA
Read-only

Prepare an iOS App Store In-App Event (IAE) — generate copy variations and a final report.

Use this when the user wants to create or draft an in-app event, prepare IAE metadata, or generate App Store event copy. Accepts user-supplied keywords and event parameters, then returns a structured brief. Do not use it for ordinary App Store listing metadata (title, subtitle, description) — it covers In-App Event fields only.

Runs entirely locally: no network calls, no App Store or SensorTower lookup, and no keyword research of its own — the caller supplies the keywords (reach for research_rivals or search_app_store first if you still need to find them). Returns immediately.

After receiving the tool output, you MUST:

  1. Generate 3 distinct copy variations in the target language (from locale.language), each differing meaningfully in angle, tone, or keyword emphasis. For each variation produce:

    • Event name (hard limit: 30 chars — count every character; trim at word boundary if over)

    • Short description (hard limit: 50 chars — same rules)

    • Long description (hard limit: 120 chars — same rules) Display every field with its exact character count and ✓ / ✗ indicator. Fix any ✗ before showing the user. Keyword placement: Tier 1 keywords must appear in short description and long description; embed in event name only if it fits naturally. Prioritize keywords toward the beginning of each field. Copy rules: active voice, present tense, no pricing claims or % discounts, no competitor names, all three fields independently meaningful. If locale is not en-US, add an English translation line under each localized field so the user can verify meaning.

  2. Ask the user to choose one variation.

  3. After the user picks a variation, print the output table and the final summary report using this exact format:

Output table:

CHOSEN VARIATION — <locale.appleCode>
─────────────────────────────────────
Event name        : <text> (<N>/30)
Short description : <text> (<N>/50)
Long description  : <text> (<N>/120)
─────────────────────────────────────
Next step: upload event artwork in App Store Connect
  • Event card image : 2160 × 1080 px
  • App icon overlay : 1024 × 1024 px

Final summary report:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
IN-APP EVENT REPORT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
IAE locale       : <locale.appleCode> (<locale.language> — <locale.country>)
Keyword store    : <locale.store> store
Target audience  : <audience>
Event context    : <event_context>
Goal             : <goal>
Tone             : <tone>
─────────────────────────────────────
Keywords used    : <Tier 1 placed> | <Tier 2 placed>
Event name       : <text> (<N>/30 chars)
Short description: <text> (<N>/50 chars)
Long description : <text> (<N>/120 chars)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
CHECKLIST
[ ] IAE locale is <locale.appleCode>
[ ] Event name ≤ 30 chars
[ ] Short description ≤ 50 chars
[ ] Long description ≤ 120 chars
[ ] No pricing claims or % discounts
[ ] No competitor names
[ ] Event artwork assets prepared (1024×1024 + 2160×1080)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Flag any checklist item that is not yet satisfied.

Returns JSON with the structured brief for generating copy.

ParametersJSON Schema
NameRequiredDescriptionDefault
goalYesPrimary conversion goal (e.g. increase conversions, attract new users, boost engagement).
toneYesCopy tone.
localeYesTarget locale/language for the IAE copy (e.g. en-us, en-gb, de-de, fr-fr, tr, ja, ko, zh-hans). An unlisted value returns an `unknown_locale` error naming the supported ones.
audienceYesTarget audience (e.g. students, professionals, parents, casual users).
keywordsYesOrdered list of keywords by priority (index 0–2 = Tier 1 must-use, 3–6 = Tier 2, 7–9 = Tier 3). Maximum 10.
event_contextYesReal-world hook tying the event to a moment (e.g. a holiday, season, product milestone).
event_purposeYes1–2 sentences describing what the event is about and why users should care.

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds that the tool 'runs entirely locally: no network calls, no App Store or SensorTower lookup, and no keyword research of its own' and 'returns immediately.' This provides behavioral context beyond the annotations (e.g., local execution, no external calls) and aligns with read-only semantics. No contradiction found.

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?

The description is very long, but it is structured with headers, numbered steps, and code blocks. Every section provides necessary procedural detail (exact character limits, output format, checklist). It is front-loaded with the purpose and usage. While verbose, the complexity of the tool justifies the length, and the organization makes it scannable.

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, the description carries the full burden of explaining return values. It provides exact output table and final report formats, character limits, keyword placement rules, translation requirements, and the checklist. It covers every step from invocation to final output, leaving no ambiguity for an agent to execute correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds substantial semantics: it explains keyword tiering (index 0–2 = Tier 1, etc.), how locale subfields (appleCode, language, country, store) are derived, and how tone and other parameters influence copy generation. It also gives specific character limits and placement rules. This goes well beyond the schema's simple descriptions.

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?

The description opens with a specific verb and resource ('Prepare an iOS App Store In-App Event') and immediately distinguishes it from ordinary listing metadata. It also explicitly excludes usage for App Store listing fields, which differentiates it from siblings like search_app_store and get_app_details. This is a clear, differentiated purpose.

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?

The description gives explicit when-to-use criteria ('when the user wants to create or draft an in-app event') and when-not-to-use ('Do not use it for ordinary App Store listing metadata'). It also routes the agent to sibling tools for keyword discovery ('reach for research_rivals or search_app_store first'). This is textbook usage guidance.

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

research_rivalsResearch App Store RivalsA
Read-only

Search the App Store for a keyword and fetch SensorTower analytics for the top results — all in one call. Results are cached for 24 hours so repeat queries are instant.

Use this for a quick competitive overview when you want everything in one step. Use search_app_store + get_app_details separately when you need more than 3 results, a custom limit, or selective fetching of specific apps. Do not use this for Google Play or Android apps — it covers the iOS App Store only.

Requires a SensorTower account. On a cache miss the server opens a real Chromium window on the user's machine; the first run needs the user to log in there, and the session is reused from then on. If there is no session the call returns an error result carrying {"error": "not_logged_in"} and leaves the window open — tell the user to log in, then call again. A cache miss scrapes three apps and typically takes 30–60 seconds; a cache hit returns immediately and opens no browser.

Trigger phrases: "rival research", "research rivals", "competitor analysis", "find competing apps", "check competitors", "what apps compete with", "App Store competitors", "rivals for keyword".

Returns JSON:

{
  "keyword": "meditation",
  "country": "us",
  "fetchedAt": "2026-04-21T10:00:00.000Z",
  "cached": false,
  "apps": [
    {
      "rank": 1,
      "name": "App Name",
      "appStoreUrl": "https://apps.apple.com/us/app/id123456",
      "sensorTowerUrl": "https://app.sensortower.com/overview/123456",
      "downloads": "<5K",
      "revenue": "<$5K",
      "rating": { "score": "4.7", "count": "1,234" },
      "publisher": "Publisher Name",
      "categories": "Health & Fitness",
      "topMarkets": "United States, United Kingdom",
      "releaseDate": "Jan 1, 2020",
      "lastUpdated": "Mar 15, 2026",
      "languages": "English, Spanish",
      "inAppPurchases": "Monthly · $9.99",
      "publisherCountry": "United States",
      "advertisingNetworks": "N/A"
    }
  ]
}

Fields missing or gated behind a paywall will be "N/A". A single app failing to scrape is not fatal — that app comes back with "N/A" fields rather than failing the whole call. When cached is true, the data was served from the local cache and no scraping occurred.

Present results as a clean report for each app:

#1 — {name}

  • App Store: {appStoreUrl}

  • SensorTower: {sensorTowerUrl}

  • Downloads: {downloads}

  • Revenue: {revenue}

  • Rating: {rating.score} ({rating.count} ratings)

  • Publisher: {publisher}

  • Categories: {categories}

  • Top Markets: {topMarkets}

  • Worldwide Release Date: {releaseDate}

  • Last Updated: {lastUpdated}

  • Languages: {languages}

  • In-App Purchases: {inAppPurchases}

  • Publisher Country: {publisherCountry}

  • Advertised on Any Network: {advertisingNetworks}

ParametersJSON Schema
NameRequiredDescriptionDefault
countryYesTwo-letter App Store country code (e.g. us, gb, tr)
keywordYesThe keyword to search in the App Store (e.g. psikoloji, meditation)

TDQS

A4.7/5.0
Behavior5/5

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

Discloses caching (24h), browser opening on cache miss, login requirement, error handling for not_logged_in, time estimates, and behavior when apps fail. No contradiction with annotations (readOnlyHint and openWorldHint are consistent with reading data and client-side side effects).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear sections: purpose, caching, usage, prerequisites, behavior, output example, and presentation format. Every sentence adds value and it is front-loaded with the main action.

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?

Covers all necessary context: complexity of combined APIs, caching, authentication, browser opening, error states, time expectations, and output interpretation. Despite no output schema, the detailed JSON example and field notes ensure completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both parameters; the description adds minimal extra beyond schema (examples like 'psikoloji, meditation' and reaffirms country code format), so baseline 3 is appropriate.

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?

The description clearly states the tool combines App Store search and SensorTower analytics in one call, and distinguishes from sibling tools (search_app_store + get_app_details) by specifying it is for quick overviews with 3 results.

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 provides when to use (quick competitive overview, one step) and when not to use (need more than 3 results, custom limit, selective fetching), and notes it only covers iOS App Store.

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

search_app_storeSearch the App StoreA
Read-only

Search the App Store for a keyword and return ranked results as a detailed table — instantly, no browser required.

Use this when you want to discover which apps rank for a keyword before deciding which ones to analyse in depth.

  • Follow up with get_app_details to fetch SensorTower analytics for specific app IDs.

  • Use research_rivals instead for a single convenience call that searches and fetches analytics together.

  • Do not use this for Google Play or Android apps — it covers the iOS App Store only.

Unlike research_rivals and get_app_details, this needs no SensorTower account, opens no browser window, and returns in about a second. It also carries no downloads or revenue figures — those only come from the SensorTower tools.

Returns markdown (not JSON): one table per result, ranked, with every App Store field available including the numeric app ID that get_app_details takes. Unavailable fields read "N/A". A keyword with no matches returns just the header line and no tables.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoNumber of results to return (1–25, default 3). Values above 25 are clamped to 25.
countryYesTwo-letter App Store country code (e.g. us, gb, tr)
keywordYesThe keyword to search in the App Store (e.g. meditation, psikoloji)

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint, openWorldHint), the description explains the return format (markdown tables), handling of missing fields ("N/A"), no-match behavior (header only), performance (no browser, ~1 second), and data limitations (no downloads/revenue). No contradiction with annotations.

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?

The description is well-structured with a clear opening, bullet points for usage, and separate paragraphs. It is slightly long but every sentence adds value, making it efficient for its purpose.

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?

Given the tool has three parameters, no output schema, and annotations present, the description covers all necessary aspects: return format, error behavior, data limitations, and sibling tool references. It is fully adequate for an agent to understand when and how to use the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not reiterate parameter details, but the schema already thoroughly documents limit (with defaults and clamping), country (pattern), and keyword (minLength). No additional meaning is needed.

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?

The description clearly states the tool searches the App Store for a keyword and returns a ranked table. It identifies the specific verb (search), resource (App Store), and output (ranked table), and distinguishes it from siblings by noting iOS-only coverage and the absence of downloads/revenue figures.

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?

Explicit guidance is provided: use this to discover rankings before deep analysis, follow up with get_app_details, or use research_rivals for a combined call. It also warns against using for Google Play/Android, which effectively sets exclusion criteria.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0
Disambiguation5/5

The four tools have clearly distinct purposes: search_app_store for discovery, get_app_details for analytics on specific IDs, research_rivals as a combined convenience wrapper, and prepare_iae for in-app event copy generation. Each description explicitly tells when to use it versus the alternatives, eliminating ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case: research_rivals, search_app_store, get_app_details, prepare_iae. Verbs (research, search, get, prepare) clearly indicate actions, and nouns (rivals, app_store, app_details, iae) identify the target. No mixing of casing or verb styles.

Tool Count5/5

Four tools is well-scoped for an iOS App Store operations server. The primary workflows are covered: discovering apps (search_app_store), retrieving analytics (get_app_details), a combined research shortcut (research_rivals), and creating in-app events (prepare_iae). No bloat or redundancy; each tool earns its place.

Completeness4/5

The tool surface covers the main research and IAE copy generation workflows thoroughly. Minor gaps exist: no tool for managing App Store listing metadata (title, description), and no explicit handling of Google Play, but the tool descriptions clearly scope the server to iOS App Store research and IAE. The explicit boundary is acceptable, though a listing-management tool would round out the 'Operator' name.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Related MCP Connectors

Related MCP Servers

  • saas-brain-mcp

    Mohd16kaif
    F
    license
    Not graded
    quality
    D
    maintenance
    Open-source MCP server for Claude AI that connects Stripe and Supabase to enable natural language SaaS analytics, including churn analysis, subscription tracking, and revenue insights.

  • meta-ads-mcp-server

    jonathanposovatz
    A
    license
    A
    quality
    D
    maintenance
    MCP Server for the Meta Marketing API. Gives Claude Desktop direct access to your ad account data — campaign performance, creative analysis, audience breakdowns, and budget pacing.
    10
    398
    1
    MIT

  • App Store MCP Server

    LaurMost
    A
    license
    A
    quality
    A
    maintenance
    An open-source MCP server for live Apple App Store competitor research, enabling AI agents to search apps, fetch metadata, compare competitors, and retrieve reviews and top charts as structured JSON.
    7
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/meyusufdemirci/app-store-operator'

If you have feedback or need assistance with the MCP directory API, please join our Discord server