Skip to main content
Glama

Search lighting products

search_products

Search the catalog of real products stocked by the suppliers on file. Accepts Persian or English. Returns normalized facets (mounting, indoor/outdoor, IP, colour temperature, and wattage/lumen where stated) plus what the query matched on. Colour temperature is returned but is NOT filterable: a fixture is usually sold in several, and the row carries the one its source printed. The response always reports what the filters excluded and why, split into 'not stated in our data' and 'did not match' — a product missing from a result is NEVER evidence that a supplier does not make it; use get_brand's doesNotDo for that.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoFree text in Persian or English, e.g. «چراغ خطی توکار» or 'recessed linear profile'.
brandNoRestrict to one supplier.
limitNoResults per page (default 20, max 50).
ip_minNoMinimum IP rating, e.g. 65 for a wet location.
offsetNoPagination offset; use nextOffset from the previous call.
categoryNoOne of the 20 canonical categories — see list_categories.
mountingNoHow it mounts.
has_imageNoOnly products with an image on file.
price_tierNoThe price band the SUPPLIER declared for its whole range. Self-declared and per brand, not per product, and not a quoted price — no supplier on file publishes prices.
environmentNoindoor, outdoor, or both. 'indoor' also returns fixtures rated for both.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / brand / enum
      Previous value: -[
      -  "spl",
      -  "mazinoor",
      -  "nooran",
      -  "shoa",
      -  "candle"
      -]New value: +[
      +  "spl",
      +  "mazinoor",
      +  "nooran",
      +  "shoa",
      +  "candle",
      +  "setareh-shomal",
      +  "eslight",
      +  "beco"
      +]
  2. Changed1 schema field changed
    • changedInput schema / properties / brand / enum
      Previous value: -[
      -  "spl",
      -  "mazinoor",
      -  "nooran"
      -]New value: +[
      +  "spl",
      +  "mazinoor",
      +  "nooran",
      +  "shoa",
      +  "candle"
      +]
  3. Changed1 schema field changed
    • changedInput schema / properties / price_tier / description
      Previous value: -"Model-inferred price band, not a quoted price."New value: +"The price band the SUPPLIER declared for its whole range. Self-declared and per brand, not per product, and not a quoted price — no supplier on file publishes prices."
  4. First observed

TDQS

A4.4/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden and does so well: it discloses the return payload (normalized facets plus match reasons), the non-filterable constraint on colour temperature and the reason, and that the response reports excluded results split into 'not stated in our data' vs 'did not match'. That is substantive behavior an agent could not infer from the schema.

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?

Front-loads what the tool does, then layers the facets, the filterability caveat, and the exclusion semantics. Every sentence carries information, though the exclusion/absence passage is dense and could be tightened slightly.

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 and ten parameters, the description supplies what is missing: the shape of the response (facets, match reasons, exclusion report) and the interpretive rule for missing products. An agent has everything needed to call and correctly interpret this tool.

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 the schema already documents all ten parameters including the price_tier caveat and enum meanings; baseline is 3. The description adds the important caveat that colour temperature is returned but not filterable, which clarifies a capability boundary rather than a parameter's syntax.

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?

States a specific verb+resource ('Search the catalog of real products stocked by the suppliers on file') and immediately scopes it to the actual supplier catalog, distinguishing it from generic search. The agent can tell it apart from get_product (single lookup) and list_categories (taxonomy listing) without opening a schema.

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?

Routes the agent explicitly: for 'does a supplier make X', use get_brand's doesNotDo instead, and it sets the crucial rule that absence from results is never evidence of non-manufacture. It does not cover the other siblings (compare_brands, list_categories) or state when a keyword search is preferred, so it falls short of a full when/when-not map.

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