Skip to main content
Glama

Crawlora MCP

datasets_chrome_extensions_facets

Read-only

Return filter-value counts for stored Chrome Web Store items under the supplied search filters.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNo
pageNo
sortNo
facetYes
statusNo
categoryNo
developerNo
item_typeNo
min_usersNo
page_sizeNo
min_ratingNo
permissionNo
collects_dataNo
developer_emailNo
manifest_versionNo
min_rating_countNo
has_broad_host_accessNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesThe tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that counts are computed over 'stored' items filtered by the supplied search filters, which is useful scoping context. It does not disclose how pagination/sort affect the facet output or what the response shape is, but with annotations carrying the safety burden a 3 is appropriate.

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?

A single tightly written sentence with the operation front-loaded and zero filler. It is efficient, though the brevity is partly the source of the parameter opacity rather than purely a virtue.

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

Completeness2/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 not be explained. However, for a 17-parameter tool with zero schema description coverage and no enumeration of the filter fields, the description leaves too much unspecified for an agent to construct a correct call.

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

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

17 parameters at 0% schema description coverage, so the schema contributes essentially nothing about their meaning. The description only gestures at 'supplied search filters' and implies the required 'facet' arg, but never explains what any parameter does or which filters influence the counts. It fails to compensate for the coverage gap.

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?

States a specific verb ('Return'), resource ('filter-value counts for stored Chrome Web Store items'), and scope ('under the supplied search filters'). This is clearly distinguishable from an item-fetch or search tool, though it never names the sibling (datasets_chrome_extensions_search) it complements.

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

Usage Guidelines2/5

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

No when-to-use guidance, no statement of when this is preferable to the sibling search tool, and no mention of prerequisites. The purpose implies it builds facet counts, but an agent gets no routing advice or exclusions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources