Crawlora MCP

datasets_chrome_extensions_search

Read-only

Search stored Chrome Web Store extension, theme, and legacy app snapshots by query and filters. Costs 1 credit per record returned (minimum 2), so keep page_size to what you need. Results are historical dataset records, not live store pages; use the related item endpoint for one snapshot’s details.

Input Schema

Name	Required	Description
`q`	No	Full-text query, max 256 characters
`page`	No	Page number, default 1
`sort`	No	Sort enum: relevance, users_desc, rating_desc, reviews_desc, updated_desc, trending_desc. Documented values: relevance, users_desc, rating_desc, reviews_desc, updated_desc, trending_desc.
`status`	No	Status enum: active, removed. Documented values: active, removed.
`category`	No	Exact Chrome Web Store category
`developer`	No	Exact displayed developer name
`item_type`	No	Item type enum: extension, theme, app, unknown. Documented values: extension, theme, app, unknown.
`min_users`	No	Minimum displayed user count
`page_size`	No	Page size, default 20, max 100
`min_rating`	No	Minimum rating, 0 through 5
`permission`	No	Exact declared permission
`collects_data`	No	Filter by public data-collection disclosure
`developer_email`	No	Exact disclosed developer email
`manifest_version`	No	Manifest version enum: 2, 3. Documented values: 2, 3.
`min_rating_count`	No	Minimum rating count
`has_broad_host_access`	No	Filter by broad host access

Output Schema

Name	Required	Description	Default
`data`	Yes	The tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

Changed16 schema fields changedOct 7, 2026

addedInput schema / properties / category / description
```
Added value: +"Exact Chrome Web Store category"
```

addedInput schema / properties / collects_data / description

Added value: +"Filter by public data-collection disclosure"

addedInput schema / properties / developer / description
```
Added value: +"Exact displayed developer name"
```
addedInput schema / properties / developer_email / description
```
Added value: +"Exact disclosed developer email"
```
addedInput schema / properties / has_broad_host_access / description
```
Added value: +"Filter by broad host access"
```

addedInput schema / properties / item_type / description

Added value: +"Item type enum: extension, theme, app, unknown. Documented values: extension, theme, app, unknown."

addedInput schema / properties / manifest_version / description

Added value: +"Manifest version enum: 2, 3. Documented values: 2, 3."

addedInput schema / properties / min_rating / description
```
Added value: +"Minimum rating, 0 through 5"
```
addedInput schema / properties / min_rating_count / description
```
Added value: +"Minimum rating count"
```
addedInput schema / properties / min_users / description
```
Added value: +"Minimum displayed user count"
```
addedInput schema / properties / page / description
```
Added value: +"Page number, default 1"
```
addedInput schema / properties / page_size / description
```
Added value: +"Page size, default 20, max 100"
```
addedInput schema / properties / permission / description
```
Added value: +"Exact declared permission"
```

addedInput schema / properties / q / description

Added value: +"Full-text query, max 256 characters"

addedInput schema / properties / sort / description

Added value: +"Sort enum: relevance, users_desc, rating_desc, reviews_desc, updated_desc, trending_desc. Documented values: relevance, users_desc, rating_desc, reviews_desc, updated_desc, trending_desc."

addedInput schema / properties / status / description

Added value: +"Status enum: active, removed. Documented values: active, removed."

First observedOct 7, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already cover readOnlyHint/openWorldHint, but the description adds genuinely non-obvious behavior: a credit cost model (1 credit per record, minimum 2) and a warning to keep page_size minimal, plus the historical-vs-live data caveat. This is real added context beyond the annotations, though rate-limit/response-shape details are absent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tightly packed sentences: purpose first, then the cost/caveat that most affects invocation, then disambiguation toward the item endpoint. No filler and the highest-impact constraint (cost) is front-loaded after the purpose.

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?

An output schema exists so return values need no explanation, and all 16 parameters are fully documented in the schema. The description supplies the missing behavioral pieces (cost, historical data caveat, sibling routing), leaving nothing critical for correct invocation.

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 the baseline is 3, but the description adds value the schema lacks by tying page_size to a per-record credit cost and advising the agent to right-size it. It doesn't add semantics for the other 15 filters (q, sort, status, etc.), which remain schema-only.

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 (Search) and resource (stored Chrome Web Store extension/theme/legacy app snapshots) with a query-and-filter scope. It also distinguishes itself from live-store siblings by explicitly framing results as historical dataset records, so an agent can separate it from chromewebstore_search 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 Guidelines4/5

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

Clearly routes the agent: use this for historical dataset records rather than live store pages, and use the related item endpoint for a single snapshot's details. It gives a solid when-to-use and one named alternative, but doesn't address the other datasets_chrome_extensions_* siblings (facets, trending, history, changes).

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

All Crawlora MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.