Skip to main content
Glama
Sign In
Apify Public Data & Leads

Apify Public Data & Leads

by jlucasmcrell
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Apple App Store Search, App Details & Top Charts

apple_app_store_data
Read-only

Search Apple App Store keywords, fetch exact app records by ID or URL, and pull top-free, top-paid and top-grossing charts for any country in one call for ASO research and market tracking.

Instructions

Get Apple App Store data from Apple's own public endpoints in one call: keyword search results, exact app records by id or URL, and the top-free / top-paid / top-grossing charts for any store country. Each row carries app id, bundle id, name, developer, price, rating and rating count, genre, version, release/update dates and the App Store URL.

Behavioral Transparency:

  • Execution: Network call executed synchronously in the cloud via Apify Actor 'captainhandsome/apple-app-store-scraper'.

  • Side Effects: Reads Apple's public iTunes endpoints and creates a billed Actor run and dataset on your Apify account. No login, no API key, no browser.

  • Authentication: Requires APIFY_TOKEN environment variable.

  • Latency & Limits: Typically 2-10 seconds; starts from $0.002 per row plus a small per-run start fee. One call returns at most 100 rows, and every row the Actor produces is billed, so keep keywords x countries x limit (plus charts x countries x limit) at or below 100.

Usage Guidelines:

  • When to use: Use for ASO keyword research, app market and chart tracking, competitor app metadata, or building app datasets for analysis and AI pipelines.

  • When NOT to use: Do not use for app reviews, for Google Play or other stores, or for private analytics such as downloads and revenue, which Apple does not publish.

  • Named alternatives: Use 'app_store_reviews_search' for iOS customer reviews and ratings; use 'google_play_reviews_search' for Android apps.

Honest limits: chart rows come from Apple's legacy top-charts feed and therefore have no rating or version fields (rating is null); keyword search returns whatever Apple returns for that country, and a run that returns zero rows fails loudly instead of charging for an empty dataset.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "apple_app_store_data"
  }
}

Input Schema

NameRequiredDescriptionDefault
chartsNoAlso collect these top charts for each country.
app_idsNoNumeric Apple app ids ('284882215') or apps.apple.com URLs to get exact app records instead of search results.
countriesNoTwo-letter App Store country codes (us, gb, de, jp, ...). Each country is queried separately; defaults to us.
search_termsNoApp Store search keywords. Each keyword returns up to limit_per_term apps per country. Leave out (or pass []) when you only want app details or charts; nothing is searched then.
limit_per_termNoMaximum apps returned per keyword. Each row is billed; defaults to 25.
limit_per_chartNoMaximum entries returned per chart. Each row is billed; defaults to 25.

Output Schema

NameRequiredDescriptionDefault
runNo
errorNo
statusYes
resultsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.6.0

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses the synchronous cloud Actor run, that a billed run and dataset are created on the caller's account, the APIFY_TOKEN requirement, typical 2-10s latency, per-row pricing plus a start fee, and a 100-row billing ceiling. It also flags a real data caveat (legacy chart feed rows have null rating/version) and that zero-row runs fail rather than charge, none of which the annotations convey.

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?

Front-loads the capability sentence, then uses labeled sections (Behavioral Transparency, Usage Guidelines, Honest limits) that an agent can scan quickly. Slightly long and some content overlaps the schema, but nearly every sentence carries decision-relevant information.

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?

For a multi-mode, billed, network-bound tool with an output schema, the description covers cost model, auth, latency, row caps, mode selection, and known data gaps. An agent has everything needed to decide whether to call it and how to size the call without reading the Actor source.

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 already 100%, so the baseline would be 3, but the description adds cross-parameter meaning the schema cannot: the keywords x countries x limit budget must stay at or below 100 billable rows, and search_terms can be omitted to run charts/details only. That interaction between limit_per_term, limit_per_chart, and countries is genuinely useful call-planning information.

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?

Opens with a specific verb (get) and enumerates three distinct resources it covers: keyword search results, exact app records by id or URL, and top-free/top-paid/top-grossing charts. It also lists the row fields returned, so an agent can match it to a data need without opening the schema.

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 separates 'When to use' (ASO research, chart tracking, competitor metadata, dataset building) from 'When NOT to use' (reviews, Google Play, private download/revenue analytics) and names the two sibling tools to use instead. This is the full when/when-not/alternative triad.

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

Deploy Server

Other Tools