Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

datasets_apps_charts_search

Search the app-charts dataset. Searches daily top-chart snapshots scraped from the iOS App Store and Google Play, stored in a search index (one document per chart × snapshot × rank).

Instructions

Search the app-charts dataset. Searches daily top-chart snapshots scraped from the iOS App Store and Google Play, stored in a search index (one document per chart × snapshot × rank). With no date the latest snapshot is returned (today's chart); pair app_id with sort=date_desc for an app's rank over time. Store enum: ios, android. Chart type enum: top_free, top_paid, top_grossing, new. Platform enum (Apple device platforms, ios charts only): phone, pad, mac. Sort enum: rank, rank_desc, date_desc. Billing: this search costs 1 credit per record returned, with a minimum of 2 (an empty result costs 2, a full page of 100 costs 100).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoFull-text query over chart-entry title and developer, max 256 characters
dateNoSnapshot date filter yyyy-MM-dd; defaults to the latest snapshot
pageNoPage number, defaults to 1
sortNoSort enum: rank, rank_desc, date_desc
storeNoStore enum: ios, android
app_idNoExact app filter — iOS numeric track id or Android package; pair with sort=date_desc for rank history
countryNoExact storefront country filter, max 128 characters
categoryNoStore category/genre filter, max 128 characters; empty for the overall charts
platformNoApple device-platform filter, iOS charts only; see platform enum above
page_sizeNoPage size, defaults to 20 and maxes at 100; page * page_size must be <= 10000
chart_typeNoChart enum: top_free, top_paid, top_grossing, new
collectionNoRaw store collection id filter (e.g. topgrossingapplications, GROSSING), max 128 characters

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.17.5
    • addedInput schema / properties / chart_type / enum
      Added value: +[
+  "top_free",
+  "top_paid",
+  "top_grossing",
+  "new"
+]
    • addedInput schema / properties / sort / enum
      Added value: +[
+  "rank",
+  "rank_desc",
+  "date_desc"
+]
    • addedInput schema / properties / store / enum
      Added value: +[
+  "ios",
+  "android"
+]
  2. Changed1 schema field changed
    • addedInput schema / properties / platform
      Added value: +{
+  "description": "Apple device-platform filter, iOS charts only; see platform enum above",
+  "type": "string"
+}
  3. Addedv1.2.0

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses data provenance/granularity, the default-snapshot behavior, and an unusual cost model (1 credit per record, minimum 2, empty result costs 2, full page of 100 costs 100). This cost disclosure is materially valuable for invocation planning and is not derivable from the schema.

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 core purpose, then defaults, then a compact enum block, then billing last — a sensible order. Slightly redundant with the schema on enum values, which costs a little density, but every sentence is functional.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-param, no-annotation, no-output-schema tool, the description supplies the key missing context: document granularity, snapshot defaulting, and per-record billing. Return-field structure and pagination beyond what the schema states aren't covered, leaving a minor gap.

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 schema already documents all 12 parameters. The description mostly repeats the enum values (store, chart_type, platform, sort) that already live in the schema; the only added nuance ('platform is Apple device platforms, ios charts only') is also restated in the schema's platform description. 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?

States a specific verb+resource ('Search the app-charts dataset') and immediately characterizes the underlying data ('daily top-chart snapshots scraped from the iOS App Store and Google Play, one document per chart × snapshot × rank'). This granularity lets an agent distinguish it from sibling datasets_apps_search without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides concrete usage context: the default behavior with no `date` (latest snapshot) and the pattern for rank history ('pair `app_id` with `sort=date_desc`'). It stops short of explicitly stating when to prefer this over sibling search tools, so it is clear context but not full when/when-not guidance.

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