Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

datasets_apps_reviews_search

Search the app-reviews dataset. Searches user reviews scraped from the iOS App Store and Google Play, stored in a search index (one document per review). Store enum: ios, android.

Instructions

Search the app-reviews dataset. Searches user reviews scraped from the iOS App Store and Google Play, stored in a search index (one document per review). Store enum: ios, android. Sort enum: recent, score_desc, score_asc, helpful_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 review text, title and author, max 256 characters
pageNoPage number, defaults to 1
sortNoSort enum: recent, score_desc, score_asc, helpful_desc
storeNoStore enum: ios, android
app_idNoExact app filter — iOS numeric track id or Android package, max 128 characters
countryNoExact storefront country filter, max 128 characters
min_scoreNoMinimum star rating, 1 through 5
page_sizeNoPage size, defaults to 20 and maxes at 100; page * page_size must be <= 10000

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.17.5
    • addedInput schema / properties / sort / enum
      Added value: +[
+  "recent",
+  "score_desc",
+  "score_asc",
+  "helpful_desc"
+]
    • addedInput schema / properties / store / enum
      Added value: +[
+  "ios",
+  "android"
+]
  2. Addedv1.2.0

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden and does meaningful work: it discloses the index structure (one document per review) and, unusually, an exact billing model (1 credit per record, minimum 2, empty result costs 2, full page of 100 costs 100). It still omits auth requirements, rate limits, and result-field shape, so it falls short of full behavioral disclosure.

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 compact and front-loads the core purpose, then the corpus, then the billing constraint in a single sentence. The enumeration of store and sort values duplicates the schema and is the only wasted text; otherwise every sentence earns its place.

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 an 8-parameter search tool with no annotations and no output schema, the description covers the essentials an agent needs: what corpus is searched, filterable dimensions, and the cost model that governs pagination choices. It does not describe the shape of a returned review document, which is the remaining gap given no output schema exists.

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 8 parameters, and the enumerations for store and sort are simply repeated verbatim in the description. The one genuine addition beyond the schema is the cost implication of page_size/page combinations, which is marginal. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Search the app-reviews dataset') and clarifies the underlying corpus: user reviews scraped from the iOS App Store and Google Play, one document per review. It implicitly separates this from the app-metadata siblings by naming the reviews dataset, but never names an alternative sibling explicitly, so it stops short of a 5.

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

Usage Guidelines3/5

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

Usage is implied by the dataset scoping (this is the tool for review text queries, not app metadata), and the billing note gives a cost-based reason to be selective. However, there is no explicit when-to-use/when-not guidance and no routing to alternatives such as datasets_apps_search or the per-store review tools, leaving the agent to infer the boundary.

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