Skip to main content
Glama

Crawlora MCP

shop_app_search

Read-only

Shop.app product search.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum products to return, default 20, maximum 50.
queryYesRequired. Shop.app search keywords, e.g. sneakers.
on_saleNoRequest sale products only, default false.
in_stockNoRequest in-stock products only, default true.
deep_searchNoEnable Shop.app deep search mode, default false.

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.4/5.0
Behavior2/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 nothing beyond that: no note about result volume, pagination, rate limits, or the behavior of the deep_search/on_sale/in_stock filters.

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

Conciseness2/5

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

The single sentence is short, but brevity here is under-specification rather than conciseness — it wastes the entire budget on restating the name instead of conveying scope, filters, or expected output.

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?

For a 5-parameter tool sitting in a crowded ecosystem of near-identical search endpoints, a four-word description is not enough to call it correctly. The output schema exists, so return values needn't be explained, but scope and disambiguation are missing.

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% (limit, query, on_sale, in_stock, deep_search are all documented in the schema), so the baseline is 3. The description adds no meaning beyond the schema, which is acceptable here but not additive.

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

Purpose3/5

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

The description names a verb and resource ('product search') on Shop.app, which is clearer than a bare tautology. But it offers no differentiation from the many sibling search tools (shop_app_product, shop_app_shop_products, shop_app_categories, plus every brand_*_search), so an agent cannot tell when this is the right entry point.

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?

There is no when-to-use guidance, no mention of prerequisites, and no routing to alternatives such as shop_app_categories or shop_app_suggestions for browsing rather than keyword search. Usage is left entirely to inference.

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