Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

reverb_search

Search and browse Reverb marketplace listings for new and used musical instruments and gear, filtering by query, category, product type, make, or price range.

Instructions

Search or browse Reverb musical-instrument listings. Searches or browses Reverb's (reverb.com) marketplace for new and used musical instruments and gear. query, category, product_type, make, min_price, and max_price are all optional and combine as an AND -- a free-text query can be combined with category/product_type/make/price filters in the same request, or every field can be omitted to browse the full active catalog. category accepts a leaf slug from reverb-categories' own categories[].slug field; product_type is a fixed, closed 14-value enum (listed below) that should be passed together with category from the SAME reverb-categories entry, since a category slug alone is not always globally unique (e.g. "cables" exists under both Accessories and Home Audio). An unrecognized category value is silently ignored by the upstream (returns the unfiltered catalog, not zero results or an error) -- a known upstream quirk. make accepts a manufacturer name from reverb-makes' own makes[] field and is a confirmed, real filter. A query with genuinely zero matches returns a well-formed empty result rather than an error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
makeNoManufacturer name filter, from reverb-makes' own makes[] field
pageNoOne-based page number, defaults to 1
limitNoResults per page, defaults to 24, maximum 50 (the upstream's own silent cap)
queryNoFree-text search query
categoryNoCategory facet filter, from reverb-categories' own categories[].slug field -- pass together with product_type from the same entry
max_priceNoMaximum price (inclusive), in USD
min_priceNoMinimum price (inclusive), in USD
product_typeNoProduct-type filter

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.13

TDQS

A4.5/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 well: it discloses the upstream quirk that an unrecognized category is silently ignored (returning the unfiltered catalog, not zero results or an error), that a genuinely zero-match query returns a well-formed empty result, and that limit has a silent cap. It omits auth requirements and return-shape details, keeping it below a 5.

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?

It is a single dense block that is front-loaded with the core purpose and then layers operational caveats, with no filler sentences. It is somewhat long and could be broken into shorter clauses, but every sentence (quirks, enum pairing, empty-result behavior) carries actionable content.

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, zero-required search tool with no output schema and no annotations, the description covers filters, combination logic, cross-tool facet sourcing, and upstream error quirks, which is nearly everything an agent needs to invoke it correctly. The main remaining gap is any indication of the return format/pagination shape, though page/limit are self-explanatory.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: the AND-combination semantics, the leaf-slug format for category, the requirement to pair product_type with category from the same entry because a slug alone isn't globally unique (e.g. 'cables' appears under two parents), and the sourcing of make from reverb-makes.

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 opening sentence states a specific verb and resource ('Search or browse Reverb musical-instrument listings') and immediately scopes the domain (new and used instruments on reverb.com). It also routes the agent to sibling tools (reverb-categories, reverb-makes) as sources for valid filter values, which implicitly distinguishes this tool from those facet-lookup siblings.

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

Usage Guidelines5/5

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

It explicitly states that all filter fields are optional, that they combine as AND, that free-text can be mixed with facet filters, and that omitting everything browses the full catalog. It further specifies that product_type should be passed together with category from the same reverb-categories entry, giving concrete when/how guidance tied to a sibling tool.

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