Skip to main content
Glama

Every business of one trade near a place, in one fixed order — the shelf

list_cards
Read-only

\uD83D\uDD34 THE TASK CARD IS THE DEFAULT (≤ 2 KB): id, name, distance_miles, phone; time for needed_by (or hours_today); items — up to 5 under query (3 for intent book), placeholders («Info», «Menu») never; budget; terms — the deal’s conditions as published; asked — your properties (confirmed / refuted / unknown); deliver_to; and next {promise[], candidate[], action {do: order | book | check_slot | quote_order | call, via, url | phone | tool, needs[]}}. intent (book / order / quote / info) shapes the items and the action. With properties the answer carries property_counts over the whole niche here and says it plainly when none confirm. detail: "shelf" gives the older shelf card below. needed_by is read THREE ways and says which (needed_by.read_as): on_day («sunday», «today» = the day, not 23:59), open_at («tomorrow 19:00», «now»), slot_after («after 15:00»: open after then; a free slot is never confirmed by hours). With max_price the order is in_budget → budget_unknown → over_budget, each by distance. THE OLDER SHELF CARD (detail: "shelf") CARRIES offering — the thing under query (else the cheapest main thing of the niche) with its title, price, price_type, unit, kind, a one-line note in the page’s own words, match_level (exact = the query’s words AND the question’s kind; kind = the kind alone; partial = the words alone, not the kind; none = nothing) and action_url (ITS OWN basket or page, or null). With a query and no row that matches, offering is null and offering_note says no_match — nothing is substituted. A price written inside the title that disagrees with the price column is shown as price_conflict with both figures and their sources. A price far from every price of its kind across the index is suspect_price: true and never decides a budget. And properties — what this business publishes of every fact any business on the page publishes (confirmed <value>, or refuted for an ask), with properties_unknown naming the page’s other keys it does not (properties_on_page is the full list; a key there and not in a card’s properties is unknown for it). All the cards of one niche inside radius_miles of location, 20 a page (limit up to 50; follow next_page — a stable token, no duplicates, no skips). THE ORDER IS FIXED AND IS NOT A RANKING: plain businesses first, then chains, then marketplaces (nothing is left out); inside each group by distance. For a trade that travels to the customer (movers, plumbers …) the businesses whose PUBLISHED service area covers the place come first, then the ones that say nothing, then the ones that refuse. You choose. niche is a key from list_niches or your own words («barbershop», «flowers», «pizza»): the answer always says matched_niche, confidence, matched_by and the nearest neighbours; when the words are not clearly one niche you get NO cards and the candidates to put back to your user. query only chooses which offering is SHOWN on each card (the cheapest main offering that fits the words; without query, the cheapest main offering of the niche) — it never changes the order. deliver_to adds can_deliver_to: confirmed | refuted | unknown per card from the published area; needed_by adds open_at: yes | no | unknown from the published opening hours (which know nothing about free slots or tables) — and FILTERS: a card leaves only when the business cannot do it by then (closed at that moment for a trade done on site; a published deadline passed for delivery or pickup); a trade that travels to the customer is never judged by its office hours; hours alone with an online door = unknown, kept, marked time. EVERYTHING a filter leaves out is in excluded — id, name, one phrase from the data («closed Sunday (Sunday: Closed)») — the first five always, the rest cut by the answer budget (excluded_cut). A needed_by behind us is an error of the question (needed_by_in_past), not an exclusion. max_price groups the cards in_budget · budget_unknown · over_budget (compared with FIXED prices in the same currency, or a per-unit price with its quantity; a «from» price is a lower bound: above the budget it is over, under it unknown), excludes nobody, and reports in_budget_count; an over_budget card shows no offering (no_match_under_budget). properties (the argument) asks for keys with min/max/equals and adds their three-state answer (confirmed | refuted | unknown) to the card’s properties, filtering nothing. tags FILTERS: only the cards carrying one of the niche’s own tags (list_niches hands them out — Google’s type words such as «steak house», «italian», or a kind on the shelf) are listed, in the same order; a free-text niche that is itself a tag («steakhouse») applies it. Each card is ≤ 1 KB: id, name, niche, offering {id, title, price, price_type, unit, action_url}, distance_miles, phone, type, price_range_primary, can[] (confirmed actions with method widget | form | link | phone | connected — a form and a telephone are two entries; connected = the business’s OWN system takes it through this door: place_order / book_slot / check_availability), can_unknown[], properties {key: "confirmed "} (a CONDITION of the deal — a deposit, a minimum, a cancellation rule — is never cut from a card; descriptive keys go first when the card is over its byte budget), properties_unknown [keys], checked_at, owner_verified, chain, marketplace, and live_data {platform, synced_at, trust} on a business whose items, prices and stock come from its own connected system rather than a page read (confirmed by the system, not a paid placement; the three states still hold — stock the platform does not track is unknown). total: 0 always says why (not scanned here / outside the radius with nearest_beyond_radius / no card with the tag / niche unknown) and is logged (gap_logged). Niches on the shelf today: restaurant (1224) · florist (318) · hair salon (283) · gas station (278) · barber (230) · nail salon (211) · pizza (198) · bakery (197) · medical clinic (195) · print shop (194) · catering (177) · grocery (169) · auto repair (168) · storage (157) · clothing store (155) · pharmacy (149) · oil change (147) · beauty salon (141) · ev charging station (141) · bar (137) · massage (133) · insurance agent (131) · optometrist (120) · appliance repair (119) · pet grooming (119) · furniture (113) · notary (111) · coffee shop (107) · hotel (105) · fuel delivery (102) · event venue (101) · parking (100) · dentist (99) · real estate agent (98) · lawyer (97) · chiropractor (95) · accountant (94) · liquor store (92) · party rental (90) · body shop (89) · movers (86) · veterinarian (85) · plumber (82) · locksmith (80) · pressure washing (78) · pool service (77) · tutoring (76) · jewelry (75) · shipping and packing store (75) · towing (75) · electrician (74) · car wash (73) · tattoo studio (71) · tire shop (71) · car dealer (70) · landscaping (68) · phone repair (68) · auto parts store (67) · physical therapy (67) · roofer (66) · travel agency (66) · car rental (65) · cleaning (65) · photographer (65) · windows and doors (65) · hvac (63) · boat rental (62) · elder care and home care (62) · wedding planner (62) · garden center and nursery (59) · jewelry and watch repair (59) · music lessons (58) · truck tire service (58) · septic and well service (55) · window cleaning (55) · tree service (53) · urgent care (53) · dance studio (52) · tailor (51) · fishing charter and boat tours (50) · bike repair (48) · carpet cleaning (46) · ice cream shop (46) · auto glass (42) · mattress (42) · handyman (40) · yoga (40) · driving school (38) · dry cleaner (36) · pet boarding (35) · daycare (34) · hardware store (34) · pest control (33) · thrift store (31) · garage door (30) · med spa (29) · truck repair (29) · general contractor (27) · junk removal (27) · funeral home (26) · medical equipment rental (25) · pet store (25) · dog walking and pet sitting (24) · butcher and seafood market (23) · swim school (20) · bike and jet ski rental (15) · juice bar (15) · golf course (14) · cinema (13) · painter (12) · escape room (11) · kids play center (11) · tennis and sports courts (10) · meal prep (9) · bowling and billiards (8) · shooting range (8) · babysitting and nanny agency (7) · specialty grocery and farmers market (6) · computer repair (4) · kids sports and activities (4) · martial arts (4) · taxi and transfer service (4) · shoe repair (3) · museum (2) · aquarium (1) · brewery (1) · butcher (1) · motel (1) · services (1) · transportation service (1); known but not scanned anywhere: candle shop, confectionery, garden center, gift shop, party shop, toy store.

Input Schema

NameRequiredDescriptionDefault
pageNothe `next_page` token of the previous answer
tagsNoFILTER by the niche’s own tags, as list_niches gives them («steak house», «italian», «dish»): a card without one of them is left out; the order does not change. Spelling is folded («steakhouse» = «steak house»).
limitNocards per page. Default 10.
nicheYesa niche key from list_niches, or the trade in your own words
queryNowords that pick the offering SHOWN on each card («red roses», «balayage»); the order of the cards does not depend on it
detailNotask (default): the short card under the task; shelf: the older ≤ 1 KB shelf card
intentNowhat the user means to do: shapes the items shown and the ONE action in `next` (book → book / check_slot / call; order → order / quote_order / call; quote → quote_order / call; info → call)
locationYesa 5-digit US postcode (best), a city ("Tampa, FL") or "lat,lng". Required: the shelf is a place.
max_priceNothe most for ONE offering, in USD: groups the cards in_budget · budget_unknown · over_budget (nobody is left out) and picks the shown offering inside it (exact, then kind, then partial matches); fixed prices compare; a «from» price above the budget is over, under it budget_unknown
needed_byNowhen: «sunday» / «today» / «2026-11-08» (open that day), «tomorrow 19:00» / «now» (open at that minute), «after 15:00» / «tomorrow after 3pm» (open after then; a free slot only where the source knows slots) — on each business’s own clock; adds `time` {asked_as, day, hours, state, why} and LEAVES OUT only the cards refuted for the way the trade is done (see excluded)
deliver_toNowhere it must be brought (a postcode is best): adds can_deliver_to per card — confirmed when the published area names the place, refuted when the business says no, unknown otherwise
propertiesNofacts to read off each card without filtering: property_states {key: "confirmed <value>" | "refuted" | "unknown"}
radius_milesNoDefault 10.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Far beyond the annotations (which only say readOnly and closed-world), the description discloses the fixed non-ranking order (plain → chain → marketplace, then distance), that travel-to-customer businesses sort by published service area, pagination via a stable `next_page` token with no duplicates or skips, the byte budgets, and that everything filtered out appears in `excluded` with a five-item minimum plus `excluded_cut`. It also explains `gap_logged` on zero results and the live_data trust profile, which an agent cannot infer from any structured field.

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 definition is a single undifferentiated block of roughly 1,500+ words with no headings or line breaks, mixing the tool's purpose, parameter behavior, return-card anatomy, and a 130-item niche inventory with counts. The opening leads with card-field minutiae rather than the tool's job, and the appended catalog dump ('Niches on the shelf today: restaurant (1224) · florist (318) …') is almost certainly not needed to invoke the tool correctly.

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?

With no output schema, the description carries the full burden of describing return values and it does so exhaustively: card fields, `property_counts`, `offering`/`no_match`/`price_conflict`/`suspect_price`, `can[]` vs `can_unknown[]`, `time` state objects, and `total: 0` diagnostics. For a 13-parameter tool with complex filtering and ordering semantics, an agent has essentially everything it needs.

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, but the description genuinely adds meaning: `needed_by` is read three ways with named `read_as` states, `query` only picks the displayed offering and never reorders, `max_price` produces a three-way budget grouping without excluding anyone, and `tags` filters while preserving order. The marginal gap is that most of these points are already in the schema text, so it is reinforcement rather than wholly new semantics.

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?

The core statement — 'All the cards of one niche inside `radius_miles` of `location`, 20 a page' — is a specific verb+resource with scope, and it distinguishes itself from siblings like get_card/find_business by describing a listing rather than a lookup. However, that sentence is buried mid-paragraph behind several hundred words describing the return shape, so an agent skimming the opening does not immediately learn what the tool does.

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 gives explicit routing rules: use `list_niches` to obtain a niche key, `detail: "shelf"` for the older card, and it explains that an unclear niche yields NO cards plus candidates to put to the user. It also explains which parameters filter vs. order vs. only style. What it lacks is a direct comparison to sibling tools such as `find_business` or `search_catalog` — when a listing of a niche is preferable to a business lookup is left 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.