Maison Éclaire

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

The annotations already declare this is a read-only, idempotent, non-destructive, closed-world operation. The description adds useful scope context such as delivery across Morocco, budget currency, and occasion-based suitability, but it does not describe recommendation behavior, result limits, or other operational details beyond the safety profile.

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 definition is a single front-loaded sentence that communicates the main purpose, categories, budget, occasions, and delivery scope efficiently. The category and occasion lists add useful specificity rather than filler, though the sentence is dense.

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 read-only tool with four parameters, annotations, and an output schema, the description provides enough context to understand what the tool returns and when it is relevant. It remains slightly incomplete because it does not clarify usage relative to sibling tools or explain the lang/limit parameters.

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 only 50%, and the description partially compensates by explaining budget in MAD and listing occasion examples. However, it does not add meaning for the lang or limit parameters, leaving a gap for those undocumented fields.

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 resource: curated gift ideas from Maison Éclaire, covering specific product categories, budgets, occasions, and delivery across Morocco. It is distinguishable from a generic product search, though it does not explicitly name or contrast with the sibling tools such as search_products.

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?

Usage is implied by the mention of budgets and occasions, but there is no explicit when-to-use/when-not-to-use guidance or comparison with search_products or list_categories. An agent can infer this is for gift recommendations, but the routing rationale is not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real context beyond that: variants and prices appear only 'when in stock', and the payload is localized per lang. It doesn't cover not-found behavior for an invalid slug, which is the one remaining gap.

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 front-loaded sentence that names the tool's subject first, then parenthetically supplies the slug source. No filler or repeated annotation boilerplate.

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?

With an output schema present, the description needn't enumerate return fields, and annotations plus full schema coverage carry the structural burden. Everything needed to call it correctly is present; only edge-case behavior (unknown slug, missing variant) is unspecified.

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%: slug format/URL hint and the lang enum (fr/en/ar with default fr) are fully documented in the schema. The description's 'localized name and description' and URL-based slug provenance largely restate that, adding little syntax or format detail beyond the schema.

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 and resource ('Full details of one Maison Éclaire product') and immediately narrows scope to a single product identified by slug. It also names the sibling that produces slugs (search_products), so an agent can tell it apart from the list/search tools 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.

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

Makes clear this is the single-product detail lookup and tells the agent where the required slug comes from (search_products results or a /produit/<slug> URL). It doesn't explicitly state when NOT to use it (e.g. browsing vs. detail), but the intended context is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already establish readOnly, idempotent, closed-world behavior, so the description only needs to add domain context. It does that by scoping the content to Morocco, naming the specific policy areas, and implicitly signalling this is the authoritative source to consult before answering policy questions; it says nothing about caching or freshness, which is a minor gap for a static-info tool.

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, no repetition: the first front-loads the content inventory, the second states the usage condition. Nothing is wasted and the ordering matches how an agent would scan it.

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?

With an output schema present, the description need not describe return shape. It covers what content is available, the geographic scope, and the condition under which to call it — enough for correct invocation of a one-optional-parameter read-only 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?

There is a single optional `lang` parameter with 100% schema coverage and an enum of fr/en/ar already documented in the schema. The description neither mentions language selection nor the default, so the schema does all the work; baseline 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 enumerates exactly what the tool returns: delivery fees and times for Morocco, free-delivery threshold, minimum order, cash-on-delivery, returns policy and WhatsApp contact. It is unmistakably a store-policy lookup and cannot be confused with the product/category/gift siblings, though it never states an explicit verb such as 'retrieve' or 'get'.

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?

'Use before telling a user how ordering, delivery or returns work' gives a clear trigger condition tied to the agent's user-facing answer. It does not name exclusions or alternatives, but the siblings cover a disjoint domain (products, categories, gifts), so ambiguity is low.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint, idempotentHint, and closed-world behavior, so safety is covered. The description adds useful content scope (the gift card and build-your-box pages are included) but nothing about ordering, count semantics, or freshness of the published-product counts. It does not contradict the annotations.

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 front-loaded sentence that puts the resource first and then the returned fields. The parenthetical category list is long but genuinely informative about coverage; no filler sentences.

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?

With an output schema present, the description needn't detail return structure, and one optional fully-documented parameter keeps the surface small. The remaining gap is usage routing: nothing tells the agent this is the natural first call before search_products.

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 single optional `lang` parameter has a full enum with default documented in the schema, so the baseline 3 applies. The description never mentions the language parameter, but it does not need to given the schema does the work.

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 resource (the Maison Éclaire shop categories) and enumerates exactly what comes back: category names, URLs, and published product counts. That level of detail distinguishes it cleanly from get_product and search_products, though it never uses an explicit verb like "list."

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?

Usage is only implied: an agent can infer this is the browsing/entry-point tool for the catalog before narrowing with search_products or get_product. There is no explicit "use this when" statement, no when-not condition, and no sibling is named as an alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior. The description adds domain context about the catalogue and Morocco delivery, but does not disclose ranking, pagination, or other behavioral details beyond what structured fields provide.

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 first sentence is front-loaded but becomes an unwieldy enumeration of categories that largely duplicates the category enum. The second sentence is efficient, but the overall structure is only adequately concise.

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 output schema, annotations, and high schema coverage, the description provides enough domain context to call the tool correctly. It could be stronger by explicitly routing detail-seeking users to get_product or category browsing to list_categories.

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 high at 83%, so the schema carries most parameter semantics. The description mentions product categories but adds no meaning beyond the category enum or other parameter documentation already present in the schema.

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 (Search) and resource (Maison Éclaire's catalogue), and lists the product domains covered. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as get_product or list_categories.

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 an explicit use condition: when the user is looking for candles, a candle gift, or candle-making supplies in Morocco. It does not name when not to use it or point to sibling alternatives, so it stops short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.