Iranian lighting supplier directory: products, brands, and a bilingual Persian/English taxonomy.
Scored across 8 tools
Each tool serves a distinct function: classification, comparison, brand details, product details, lists, search, and consultation. There is no overlap in purpose, and the descriptions clearly differentiate what each tool does, so an agent can reliably select the correct one.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., classify_lighting_term, list_brands, search_products). The verbs are descriptive and the pattern is uniform, making the toolset predictable and easy to navigate.
With 8 tools, the server is well-scoped for its purpose—covering catalog browsing, search, classification, and consultation. Each tool adds clear value without redundancy or bloat, and the count is neither too sparse nor overwhelming.
The surface covers the full read-only workflow: listing categories and brands, getting details, searching products, comparing coverage, classifying terminology, and initiating consultation. There are no dead ends—users can move from broad lists to specific product or brand details and ultimately to a consultation action.
Map any Persian or English lighting phrase onto the canonical taxonomy — «داونلایت توکار», 'trimless plaster frame', 'high bay'. Backed by 522 learned type→category pairs plus rules measured at 95% agreement. Returns null for a phrase that names no category rather than guessing.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | A product type, in Persian or English. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It goes beyond a simple action statement by revealing the model's backing (522 learned pairs, 95% agreement) and, crucially, its failure behavior: returning null rather than guessing when the phrase names no category. This is strong, decision-relevant transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all earning their place: the primary action with examples, the underlying reliability evidence, and the null-return behavior. The most important information is front-loaded, and there is no filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description is complete: it states what input is expected, shows valid examples, explains how the mapping works, and explicitly covers the null case. An agent has everything needed to call the tool correctly and interpret an unexpected result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes 'term' as 'A product type, in Persian or English.' The description adds illustrative examples and clarifies that a 'phrase' is acceptable, but it does not substantially extend the schema's parameter meaning, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Map') and resource ('any Persian or English lighting phrase onto canonical taxonomy'), with concrete examples like «داونلایت توکار» and 'high bay'. This clearly distinguishes the tool from product/brand lookup siblings such as get_product or list_brands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes clear usage context: use this when you have a lighting phrase, in Persian or English, that needs mapping onto a canonical category. It does not explicitly name alternatives or exclusions relative to sibling tools, but the domain and intent are unambiguous enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which suppliers cover a category, with counts, share, and per-facet data coverage. Coverage describes what each supplier's SOURCE stated, never product quality, and a one-supplier category says so rather than pretending to be a comparison.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category slug from list_categories. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds meaningful context by clarifying that coverage reflects what each supplier's SOURCE stated, not product quality, and that a one-supplier category is reported honestly rather than presented as a comparison.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence states the core output, and the second provides an essential caveat about data interpretation. It is front-loaded and each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single enum-constrained parameter and no output schema, the description communicates the key output dimensions: counts, share, and per-facet data coverage. It does not fully define these terms, but the tool is simple enough that an agent can select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter fully with an enum and a description pointing to list_categories. The tool description does not add new parameter-level meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: reporting which suppliers cover a category, with counts, share, and per-facet data coverage. It is specific about the resource and scope, though it does not explicitly differentiate it from siblings like list_brands or get_brand.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: when you want supplier coverage for a category. However, there is no explicit guidance on when to choose this tool over sibling tools such as list_brands, nor any exclusions or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One supplier in full: what they make, the product families they run, and — the field worth the call — doesNotDo, a statement of what they genuinely do NOT make, computed from absence in their product list rather than inferred from their marketing.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Supplier slug from list_brands. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It adds valuable nuance by explaining that doesNotDo is computed from absence in the product list rather than inferred from marketing, and it previews the response contents. It stops short of stating read-only behavior or error behavior, but no write semantics are implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that leads with 'One supplier in full' and spends zero words on filler. Every clause adds information, including the differentiating doesNotDo detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-style tool with no output schema, the description provides a good preview of the response (what they make, product families, doesNotDo). It lacks explicit handling of invalid slugs or a fuller return-shape list, but nothing essential is missing for an agent deciding to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already fully documents the sole slug parameter (including where to get it: list_brands). The description adds no additional parameter semantics, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation and resource: retrieving one supplier profile in full, including product families and the distinctive doesNotDo field. The phrase 'one supplier in full' distinguishes it from sibling list/compare tools such as list_brands and compare_brands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. The wording 'One supplier in full' implies the tool is for detailed single-supplier lookups rather than enumeration, but it never names alternatives or conditions for choosing compare_brands or search_products.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every field on file for one product, by the id search_products returns ('brand/product-slug'), including provenance: whether the fact came from the supplier's own website or from a page of their PDF catalog, and when it was read.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Product id, e.g. 'spl/hangwire-puzzle-hangwire'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the response includes provenance details and read timing, which goes beyond what the schema shows. However, it does not mention error behavior, permissions, or whether this is a safe read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no filler, and the core purpose is front-loaded. The parenthetical and the trailing provenance clause make it slightly dense, but every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter fetch with no output schema, the description adequately previews the return contents, including provenance and timestamp. It does not describe a structured return shape, but the tool's simplicity makes this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already provides an example id. The description adds value by explaining where the id comes from (search_products) and confirming the 'brand/product-slug' format, clarifying the parameter's meaning beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('get one product') and clearly identifies the input as the id returned by search_products, with a concrete format example. This distinguishes it from siblings like get_brand and search_products without needing to inspect the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly implies the tool is used after search_products, since the required id is exactly what search_products returns. It does not explicitly state when not to use it, but the context is clear enough for an agent to infer the appropriate workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every supplier on file with what they cover, how complete their data is, and when it was last read. No contact details — see the server instructions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It states what is included (coverage, completeness, last read) and explicitly excludes contact details, but it does not disclose whether the operation is read-only, requires authentication, or has side effects. It also hints at server instructions but doesn't elaborate. This is partially transparent but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The primary function is stated first, followed by a clear limitation. It is concise, front-loaded, and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description adequately conveys what the tool returns and what it omits. It covers the essential information an agent needs to decide if this tool is appropriate. It could mention the response format (e.g., array) but that is a minor gap given the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no parameter info. Per the rubric, the baseline is 4 for 0 params. The description adds value by specifying the output content (what data each supplier entry includes), which is more than the empty schema conveys. No parameter semantics are needed since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: it lists every supplier on file and specifies the data returned (coverage, completeness, last read). It distinguishes itself from siblings like get_brand (specific brand) and compare_brands (comparison) by covering all suppliers. The verb 'list' and resource 'suppliers' make purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving all suppliers but does not explicitly name alternatives or conditions for when to use this vs. other tools. The note 'No contact details — see the server instructions' provides an exclusion but no explicit pointer to a specific sibling. It gives context but lacks clear when-to-use/when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The 20 canonical categories with Persian and English names, product counts, and which suppliers are in each. Small enough to fetch once and reason over the whole market; flags categories that only one supplier covers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden; it discloses the fixed set size (20), the included fields, and the single-supplier flag behavior. It doesn't overpromise dynamic content or hide side effects, though it doesn't discuss freshness or return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences deliver the content, use case, and a useful heuristic (flags single-supplier categories) with no filler. The most decision-relevant facts are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-param list tool, the description covers what is returned and why an agent might call it. It could be slightly more explicit about the return structure, but the absence of parameters and annotations makes this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so parameter ambiguity is minimal; per the baseline for 0-param tools, a 4 is appropriate. The description adds no parameter details because none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's output: the 20 canonical lighting categories with Persian/English names, product counts, and suppliers. This differentiates it from siblings like list_brands and get_product by specifying the resource and level of detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by noting the result is small enough to fetch once and reason over the whole market, signaling when a broad category overview is needed. It does not explicitly name alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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) 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.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free text in Persian or English, e.g. «چراغ خطی توکار» or 'recessed linear profile'. | |
| brand | No | Restrict to one supplier. | |
| limit | No | Results per page (default 20, max 50). | |
| ip_min | No | Minimum IP rating, e.g. 65 for a wet location. | |
| offset | No | Pagination offset; use nextOffset from the previous call. | |
| category | No | One of the 20 canonical categories — see list_categories. | |
| mounting | No | How it mounts. | |
| has_image | No | Only products with an image on file. | |
| price_tier | No | Model-inferred price band, not a quoted price. | |
| environment | No | indoor, outdoor, or both. 'indoor' also returns fixtures rated for both. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: discloses language handling, return facets, the non-filterability of colour temperature (with reasoning), the split of excluded-reason reporting, and the interpretation caveat about missing products. This is rich behavioral context beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: core function, language support, return shape, a critical caveat, and an interpretation rule. It front-loads the purpose and progressively adds operational detail, with no filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter, no-output-schema tool with no annotations, the description is thorough: it explains what the response contains (normalized facets, matched-on query), how exclusions are reported, and how to interpret absence. Pagination is covered by the schema's nextOffset reference, and remaining parameter semantics are fully documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. The description adds context about colour temperature being returned but not filterable, and explains that q matches on query text, but it does not deepen meaning of individual parameters beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Search'), resource ('the catalog of real products stocked by the suppliers on file'), and language support. It clearly differentiates from siblings by directing the 'does a supplier make it?' question to get_brand, so an agent knows this tool searches products rather than brand capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-not guidance: a product missing from results is NOT evidence a supplier does not make it, and tells the agent to use get_brand's doesNotDo instead. It also indicates accepted input languages. This routes the agent to the correct sibling for a specific scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a described need into a link the person opens themselves, where an adviser builds a brief and matches it against suppliers' real stock. This is how someone actually reaches a supplier: there are no contact details in this server, and this call does not contact anyone. It stores nothing and it REFUSES any personal data — no name, no number, no email. Describe the project, not the person.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | The project in the person's own terms, in Persian or English — space, use, style, constraints. No personal details: the call is refused if it contains a phone number, an email or a handle. | |
| client | No | Optional: a short name for your app, so we can tell which assistants send people here. Self-reported, lowercase slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the call does not contact anyone, stores nothing, refuses personal data, and returns a link for the user to open. These are key behavioral traits (non-contact, non-storing, input validation) clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The main action (turn need into link) is front-loaded, followed by concrete behavioral constraints. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description explicitly states the output is a link the user opens, and covers input constraints and side-effect-free behavior. For a single-required-parameter tool, this is sufficient, though it doesn't detail response format beyond the link.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and describes both parameters in detail, including the personal-data refusal. The description repeats this but adds no new semantic nuance. Baseline of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb (turn a need into a link) and resource (adviser builds a brief, matches supplier's stock). It distinguishes itself from product/brand-focused siblings by emphasizing this is the only route to a supplier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit context: this is how someone actually reaches a supplier, and states there are no contact details in the server. But it doesn't name sibling alternatives or explicitly say 'use this instead of X'. The guidance is clear but not fully explicit about exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
classify_lighting_termcompare_brandsget_brandget_productlist_brandslist_categoriessearch_productsstart_consultationSearch 160k+ Russian B2B products from 8,900+ verified manufacturers (EN/RU).
Search 500+ wire-harness & cable-assembly manufacturers by country, industry, and capability.
Search building products & manufacturers for AI agents: CAD, BIM, specs by CSI from arcat.com
Cross-vendor B2B catalog for AI agents: search, compare, find equivalents, request a quote.
Add one secure layer between your agents and this server.
