Skip to main content
Glama

AirShelf Catalog

Search product catalog

search_catalog
Read-only

Search the AirShelf cross-vendor product catalog by natural-language query. The catalog covers industrial-automation components (sensors, encoders, vacuum handling, motors and drives, circuit protection, machine vision — the largest category by row count), wiring devices (plugs, receptacles, connector bodies, rocker switches), multifunction printers (mfp), barcode printers, laser printers, mechanical keyboards, cybersecurity products, and threat-intelligence platforms. Industrial-automation and wiring-device rows are indexed by manufacturer part number, so a brand or part number in the query ("Pepperl+Fuchs retroreflective sensor", "IN5409") retrieves more reliably than a bare product type; those rows carry no normalized spec facets, so the specs filter does not apply to them. Returns ranked products with prices, specs, and per-row match accounting. Each row includes unverified_specs, the normalized spec names that lack claim-level receipts; never use those as decisive facts. Example queries: "tactile mechanical keyboard under $150", "Toshiba A3 colour multifunction device", "industrial barcode printer for a warehouse", "threat-intelligence platform with dark-web monitoring".

Result fields: • canonical_name — the exact catalog name of the product. • spec_absence_note — spec fields absent from this product's golden record (AirShelf's verified product record); null when nothing is missing. • constraint_match_score and matched_criteria — query constraints supported by claim-level receipts. unverified_criteria names matching catalog values that still need confirmation; missing_criteria names values that are absent or conflict. • parsed.price_availability — all_null = true means every returned price is null. For quote-gated B2B pricing, a null price with a quote path is expected rather than an error; query_had_budget reports whether the query carried one. • result.commercial_data — branch on actionable before using price or stock. Observations older than 24 hours are withheld from result.price/result.inStock and retained only as labelled last_observed history. • parsed.weak_match — the response contains an unresolved constraint, query match, or product-identity warning. parsed.unverified_identity_count counts returned names without an identity receipt. parsed.no_match — no product satisfies a hard constraint, and candidates violating it were excluded server-side.

On a miss or near-miss for a specific brand+model the response may also carry a tier3 block, meaning a real-time lookup for the exact SKU asked about; it can appear alongside fuzzy-neighbour rows. • tier3.status = "resolved" — a single-source reading of the page at tier3.source_url. MPN-confirmed means the live lookup matched the manufacturer part number. Its verification is "live-unverified": confirmed on a live page during this run, but not yet matched to an AirShelf catalog record. A verified row is matched to the catalog record. tier3.cached = true means it came from a recent prior lookup, with fetched_at recording when the page was read. • tier3.status = "abstain" — the lookup could not confirm the product exists as asked, so no specs, price, or availability were established. tier3.guidance describes the quote-request path. • tier3.status = "declined" — an applicable lookup did not run; tier3.reason says why (disabled, rate_limited, daily_cap, negative_cache, error). No specs or availability were established, and none should be inferred. No tier3 block at all means a live lookup was not applicable to this query (no parseable brand+model identity).

Optional market (ISO 3166-1 alpha-2, e.g. "TH") excludes catalog rows whose country-specific URL conflicts with the buyer market and scopes tier3 lookup/cache. A remaining global URL is not local-availability proof: parsed.weak_match stays true and unsatisfied_constraints includes market_availability until every returned row has a matching country receipt. "Available in " still does not guarantee stock.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qYesNatural-language query, at most 200 characters. Supports budget hints (e.g. "under $150").
limitNoMax results
specsNoHard spec facets, e.g. {"form_factor":"desktop","print_speed_ppm":33}. Filters by exact/range spec match.
marketNoBuyer market as an assigned ISO 3166-1 alpha-2 country code (e.g. "TH", "AU"). Conflicting country receipts are excluded; global URLs remain market-unverified.
categoryNoOptional category filter (industrial-automation, wiring-devices, mechanical-keyboards, mfp, barcode-printer, laser-printer, inkjet-printer, cybersecurity, or threat-intelligence-platform)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNo
queryNo
tier3No
parsedNo
reasonNo
statusNo
resultsYes
took_msNo

TDQS

A4.3/5.0
Behavior5/5

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

The description goes far beyond the readOnlyHint/openWorldHint annotations with detailed, non-contradictory behavioral guidance: unverified_specs caveats, weak-match semantics, no-match handling, tier3 lookups, cached lookups, and market-verification limitations. It clearly discloses the behavioral nuances an agent needs to interpret results safely.

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?

The description is long, but the complexity is high and the structure is effective: scope, examples, result fields, tier3 states, market caveats. It is front-loaded with the main purpose and practical query guidance, and it earns most sentences through concrete warnings and field-level semantics, even if slightly dense.

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 tool's complex output semantics, 5 parameters, and output schema, the description is unusually complete. It covers retrieval behavior, ranked match accounting, result field caveats, miss/near-miss handling, tier3 resolution states, and market-dependent verification. Very little is left for an agent to guess.

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 documentation is complete, so the baseline is solid, but the description adds meaningful parameter context: query style and brand/part-number reliability, how specs are limited for certain catalog rows, and the detailed market argument effects. Supporting parameter meaning is strong, though limit and category receive little extra beyond the schema.

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 description clearly states that this tool searches the AirShelf cross-vendor product catalog via natural-language queries, with concrete examples and category coverage. It is specific about what it does, but it does not explicitly differentiate itself from sibling tools such as find_products or research_shopping, so it misses the highest bar.

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?

The description gives strong usage context: natural-language querying, category scope, manufacturer part-number behavior, and how market filtering changes results. It doesn't explicitly state when not to use this tool or which alternative to prefer for different tasks, but the context is clear enough for most selection cases.

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.

TDQS

A4.1/5.0
Disambiguation2/5

The set contains at least two genuinely confusable pairs: find_products vs research_shopping (explicitly cross-referencing each other in their own descriptions, with near-synonymous purposes of discovering products), and get_product vs explain_product vs compare_products, all of which return product records with prices and specs. The descriptions go to great lengths to disambiguate, which flags the very real boundary problem — an agent would struggle to pick correctly without reading thousands of characters.

Naming Consistency4/5

All eight names follow a clear verb_noun snake_case pattern (compare_products, get_product, search_catalog, request_quote, research_shopping). Minor deviations: singular/plural inconsistency across pairs (get_product vs compare_products), and research_shopping reads as a noun phrase rather than verb+object. Otherwise, predictable and clean.

Tool Count5/5

Eight tools is right in the sweet spot for a research/quoting workflow, and each earns its place: search, find, get, compare, explain, merchants, quote, and the heavy research job. The surface is neither bloated with near-duplicate operations nor so thin that the server feels like a stub.

Completeness4/5

The buyer-to-quote lifecycle is covered end to end: discovery (search_catalog, find_products), deep verification (get_product, explain_product, tier3 live lookup), comparison, merchant lookup, and a double opt-in request_quote flow that closes the loop. Minor gaps: no way to list prior quotes placed or track a quote's status after the initial response, and no explicit search-catalog pagination control, but agents can work around these.

Resources