Four App Store Optimization tools. Four concrete workflows any indie iOS developer runs directly inside Claude via MCP server — no browser, no spreadsheet, no context switch.
Last updated: April 2026
App Store Keyword Searchsearch_app_store
TOOL
The job:Show me who ranks for this keyword so I can start tracking them.
An indie developer building or maintaining a keyword tracker needs to know which apps rank for a target keyword before monitoring rank changes. Normally this means opening the App Store manually, searching, and noting app names and IDs. With search_app_store, they ask Claude directly — no browser switch, no copy-paste.
The structured output includes app IDs, names, and ranking positions — exactly the data needed to seed a keyword tracker. Each result is already formatted for the conversation, so the developer can reference app IDs in follow-up calls to get_app_details or research_rivals without leaving Claude.
“Search the US App Store for 'habit tracker' and give me the top 10 apps with their IDs so I can add them to my keyword tracker.”
Outcome: No browser switch. No manual copy-paste. A clean, structured list of ranked competitors in seconds, already inside the conversation where ASO work is happening.
When to use which
Use search_app_storewhen the question is “who ranks here” — use research_rivalswhen the question is “is it worth trying to rank here”.
Rival Market Analysisresearch_rivals
TOOL
The job:Tell me if this market is worth entering and who controls it.
A developer has an idea for a new app — say, a journaling app with AI summaries. Before committing to months of work, they want to know whether the market is crowded, who the dominant players are, and what kind of downloads they pull. research_rivals searches the App Store AND scrapes SensorTower analytics in one call — returning 16 structured fields per app for the top 3 ranked results.
The 16 data fields include download estimates, revenue ranges, rating counts, publisher details, and App Store category rankings. For early-stage market validation, this is the difference between building on assumptions and building on real competitive data — without a SensorTower subscription.
“Research the top rivals for 'AI journal' in the US App Store. I want to understand the market before I decide whether to build this.”
Outcome: A go/no-go signal based on real market data, not guesswork. The 24-hour cache means returning to the same research thread later incurs no additional scraping cost.
When to use which
Use research_rivals when you need market discovery — use get_app_details when you already know which apps to track and need precise, targeted analytics.
Competitor Analyticsget_app_details
TOOL
The job:I already know which apps I'm watching — just give me their numbers.
The developer already knows which apps they are competing with. They do not need another keyword search — they want targeted SensorTower analytics on a specific set of 2–4 apps. Common scenarios: ongoing competitor monitoring and pre-launch benchmarking. App IDs may come from a prior search_app_store call.
Unlike research_rivals, which runs a keyword search and returns the top 3 results, get_app_details accepts a specific list of app IDs and returns SensorTower analytics for each. Use it when tracking a fixed competitor set over time or benchmarking against a specific peer group before launch.
“Get details for these two apps I'm competing against: [App ID 1] and [App ID 2]. I want to see their download and revenue data.”
Outcome: Precision over breadth. When the app IDs are already known, get_app_details is faster and more surgical than running a keyword search.
In-App Event Copywritingprepare_iae
NEW
The job:Write my In-App Event copy in [language], within App Store limits, and give me options.
An indie developer is launching a 30-day summer challenge inside their fitness app and needs to promote it as an iOS In-App Event. App Store Connect requires three character-limited fields: event name (30 chars), short description (50 chars), long description (120 chars). Writing long-form first is a cognitive trap — character limits force heavy edits. prepare_iae returns 3 variations upfront, all limits enforced, so the developer picks the best angle rather than editing down from a single draft.
The tool enforces all App Store Connect field limits automatically. Returning 3 variations rather than one draft removes the most common bottleneck — rewriting a single draft to fit constraints — and replaces it with a selection decision. Available in 14 locales, no translator required.
“Prepare an In-App Event for my fitness app. It's a 30-day summer challenge. Target audience is fitness beginners. Goal is reactivating churned users. Tone: motivational. Give me 3 variations in German.”
Outcome: Submission-ready IAE copy in any supported locale, without hiring a copywriter or translator, without manually counting characters, and without leaving the ASO workflow in Claude.
Do I need a SensorTower subscription to use App Store Operator?
No. App Store Operator handles the SensorTower scraping internally. You do not need a SensorTower account or API key. The server runs locally via npx and caches results for 24 hours to avoid redundant requests.
Which Claude plans support MCP servers?
MCP servers work with Claude Code (all plans) and Claude Desktop (Pro and above). You do not need access to the Claude API — just the standard Claude Code or Claude Desktop installation.
Does App Store Operator work with Google Play or Android apps?
Not currently. App Store Operator is built for the Apple App Store. All four tools — keyword search, rival research, competitor analytics, and In-App Event copy — target iOS apps specifically.
Get started with App Store Operator in Claude.
App Store Operator connects Claude to App Store and SensorTower data — no browser, no API keys, no manual copy-paste.