Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

datasets_apps_charts_facets

Discover app-chart facet values and counts using search filters, returning up to 50 buckets ordered by count to explore store, chart type, category, country, and date distributions.

Instructions

Discover values in the app-charts dataset. Returns up to 50 chart-rank facet buckets ordered by count, using the same filters as datasets_apps_charts_search. Page and page_size do not change the aggregation. A snapshot_date facet without date spans all history; other facets use the search date scope, including the latest-snapshot default when applicable and full history for a single app or date_desc sort. Facet enum: store, collection, chart_type, platform, category, country, app_id, snapshot_date, free. Store enum: ios, android. Chart type enum: top_free, top_paid, top_grossing, new. Platform enum: phone, pad, mac.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "facet": "<facet>"
    },
    "name": "datasets_apps_charts_facets"
  }
}

Input Schema

NameRequiredDescriptionDefault
qNoFull-text query
dateNoChart snapshot date, yyyy-MM-dd
freeNoFilter by free/paid status
pageNoResult page, 1-based
sortNoValidated search sort; bucket order stays count-desc, and time-series date_desc keeps its search history scope
facetYesFacet field
storeNoStore enum: ios, android
app_idNoExact store app id
countryNoStorefront country
categoryNoExact store category
platformNoApple device platform enum (iOS charts only): phone, pad, mac
page_sizeNoPage size, default 20 and max 100
chart_typeNoChart type 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. Addedv1.17.20

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations supplied, the description carries the whole burden and does substantial work: a 50-bucket cap, count-desc ordering, pagination being aggregation-neutral, and the snapshot_date-vs-other-facet date-scope distinction including the latest-snapshot default. It stops short of stating read-only/mutation status explicitly or describing the shape of a bucket (value + count), leaving small behavioral gaps.

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?

Behavior is front-loaded in the first two sentences, and the date-scope nuance follows in one dense but readable sentence. The trailing enumerations of facet, store, chart_type, and platform duplicate the schema verbatim and could be trimmed without losing meaning.

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 14-parameter, no-annotation, no-output-schema tool this is a strong definition: aggregation cap, ordering, pagination neutrality, and date-scope rules are all covered. The remaining gap is that with no output schema, the description never says what a bucket actually contains beyond being count-ordered, and it does not address invalid facet values or how q/free interact with facet selection.

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

Parameters4/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 real semantics the schema does not: that page/page_size have no effect on buckets, that sort keeps count-desc bucket order, and how date scope resolves differently for snapshot_date versus other facets. The enum restatements duplicate what the schema already enumerates, adding little.

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 and resource ('Discover values in the app-charts dataset') and immediately characterizes the output: up to 50 chart-rank facet buckets ordered by count. It also contrasts with the sibling `datasets_apps_charts_search` by noting the identical filter surface but different aggregation behavior, so an agent can distinguish the two without opening a 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?

Implies the right usage path by saying filters match `datasets_apps_charts_search` while page/page_size 'do not change the aggregation', which steers an agent to this tool for value discovery rather than record retrieval. It lacks an explicit 'use X instead when' exclusion, so the routing is clear but not fully spelled out.

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