Skip to main content
Glama

Search Commonplace listings

catalog_search_listings
Read-only

Search live Commonplace inventory by words, category, place (deliver_to alone returns some listings near it, not every one), or any mix. Results are active and buyable. outcome: ok; none; none_within_limits (every match is in hidden); out_of_budget (matches only outside the price range; examples ignore deliver_to); undeliverable (none reaches deliver_to; examples say how far). With deliver_to, each result carries delivery (known, deliverable, driving distance_miles, fee_usd, total_usd). Candidates come from the words or categories plus the catalogue's proximity ranking, not the whole catalogue: to be thorough, also search category_hint and its department. Up to 40 are checked per call, roughly nearest first; with max_distance_miles, one already well past it in a straight line is not checked but counted in too_far (distance_is_straight_line: a lower bound, not a drive). delivery_checked, candidates_considered and candidates_unchecked (could be inside the limits, never checked) say how far it got; next_offset, passed back as offset, checks the rest. cheapest and most_expensive spend all 40 checks and return the best (results_not_shown counts the rest; a limit up to 40 returns them); any sort orders only what was checked. farthest_checked_miles, the longest drive measured, can pass the radius. hidden counts every candidate left out, once each, by reason, with its nearest or cheapest examples. When no title matches, the category the words point to is browsed (no_title_matched) or the outcome is none; matched_on names looser words that matched. more_available: candidates_unchecked (see next_offset), or more_matches_unread: more listings match than one search reads, which offset cannot reach; narrow the words, category or price.

Input Schema

NameRequiredDescriptionDefault
sortNobest_match is relevance order and says nothing about price. With deliver_to, cheapest orders by the delivered total and nearest by driving distance (nearest needs deliver_to).
limitNoHow many listings to return (default 5, at most 40).
queryNoWhat to look for, e.g. "peloton bike+" or "sectional sofa". Words match titles loosely, with only a few everyday synonyms (couch and sofa, fridge and refrigerator) ("hot tub" misses a listing titled Jacuzzi: search its category), though "+" and "plus" count as the same. Optional when category is given: without words, the search browses the category.
offsetNoWith deliver_to: a previous call's next_offset, with the same other arguments, to check the candidates it did not reach (hidden then counts only that call's checks). Use it rather than price bands to be thorough: min_price_usd compares the price before delivery, so bands can miss a listing.
categoryNoOnly these categories: a slug from catalog_list_categories, listing_resolve_category or a result's category_slug, or several separated by commas (sofas,sectionals,general-furniture). A department (furniture) or parent (peloton) covers every category beneath it, and a category covers the older slugs its listings are stored under (peloton-bike returns peloton-bike-2nd-gen listings). With words too, only this category is searched, and words matching nothing in it return none.
deliver_toNoWhere it would be delivered: a 5-digit ZIP or "City, ST". Keeps only items that can be delivered there, which can be far away. To find items near a place, give the place here with max_distance_miles.
max_price_usdNoHighest price, inclusive, in US dollars: buyer_price_usd, or with deliver_to the total with delivery. A listing whose buyer price alone is over it is not a candidate at all. For "under $1,200", pass 1199.99.
min_price_usdNoLowest buyer_price_usd, inclusive, in US dollars. Always compared with buyer_price_usd, with or without deliver_to.
hidden_examplesNoHow many listings each hidden reason shows (default 10 for too_far, 20 for the others); counts are always complete.
max_distance_milesNoWith deliver_to: only items within this many driving miles of it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior5/5

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

With only safety annotations present, the description carries the full behavioral burden and does so richly: it documents outcome values (ok, none, out_of_budget, undeliverable, etc.), candidate sampling (up to 40 checked, proximity ranking), hidden reasons, pagination via next_offset, and what more_available and more_matches_unread mean. This is far beyond the structured fields.

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 description is a single dense block of semicolon-separated clauses covering outcomes, candidates, hidden counts, pagination, and sort semantics. Much of this detail duplicates schema or could be structured more clearly, making it hard to parse despite the front-loaded 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?

Given the absence of an output schema, the description fully explains return-relevant behavior: outcome statuses, delivery fields, hidden reasons, pagination tokens, and candidate limits. An agent has enough context to call this complex search correctly.

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%, so each of the 10 parameters already has its own documented meaning. The description adds some behavioral nuance around deliver_to, max_distance_miles, offset, and sort, but much of the parameter detail remains redundant with the schema, warranting the baseline 3.

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 opens with a specific verb and resource: "Search live Commonplace inventory by words, category, place... or any mix." It also states the result nature ("Results are active and buyable"), which is enough to distinguish it from retrieval-by-id siblings like catalog_get_listing and catalog_list_categories.

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

Usage Guidelines3/5

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

The tool's core usage is implied by "Search live Commonplace inventory", and the description gives parameter-level guidance such as using deliver_to with max_distance_miles or using offset to be thorough. However, it never explicitly states when to use this tool versus alternatives like catalog_get_listing or catalog_list_categories, so the guidance remains implicit.

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