Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

reverb_price_guide_search

Search Reverb's Price Guide catalog by brand or model to find gear model slugs for price lookups. Use free-text queries like "fender stratocaster" and get matching model results.

Instructions

Search Reverb's Price Guide model catalog. Searches Reverb's Price Guide (reverb.com/price-guide) for gear models by free-text brand/model query (e.g. "fender stratocaster"). Each result's slug is the value reverb-price-guide's own slug parameter accepts. query is full-text relevance search, not an exact match -- unlike reverb-search's own query, a nonsensical query is not guaranteed to return an empty result; the upstream can fall back to loosely related or generically popular models instead, so a low result count should be treated cautiously rather than read as "no real matches.".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoResults to return, defaults to 24, maximum 100
queryYesFree-text brand/model search query

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.13

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses that query is full-text relevance rather than exact match, that nonsensical queries may still return loosely related or generically popular models, and that low counts are not reliable. It omits auth/rate-limit details but the query-behavior disclosure is substantive.

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?

Purpose is front-loaded in the first sentence, followed by the slug handoff and the query-behavior caveat. The final sentence is long and em-dash heavy, but each clause adds distinct, non-redundant information.

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 two-parameter search tool with no output schema, it covers purpose, query semantics, result interpretation, and the linkage to the sibling reverb_price_guide. Nothing critical is missing, though it doesn't address the limit default/maximum in prose (schema handles that).

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; the description lifts this by clarifying what `query` actually does (relevance search, not exact match) and what the returned slug means for downstream calls. The `limit` parameter is left entirely to the schema, keeping it from a 5.

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?

The description names a specific verb and resource ('Search Reverb's Price Guide model catalog') and scopes it to gear models by brand/model text. It is distinguishable from siblings because it explicitly frames results as slugs consumed by reverb_price_guide, and contrasts its query behavior with reverb_search.

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?

It clearly implies the workflow: search here, then pass a returned slug to reverb-price-guide's slug parameter, and it warns that results should be treated cautiously on low counts. It stops short of an explicit 'use this when X, not Y' statement, so 4 rather than 5.

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