Read-only catalogue, gift ideas and delivery terms of a handmade candle shop in Morocco.
Scored across 5 tools
Each tool targets a distinct resource or intent: catalogue search, single-product lookup by slug, category browsing, curated gift recommendations by budget/occasion, and shop policy info. The only near-overlap (get_gift_ideas vs search_products) is sharply separated by budget/occasion curating versus keyword search, and descriptions explicitly say when to use each.
All names are snake_case verb_noun (get_gift_ideas, get_product, get_shop_info, list_categories, search_products) with verbs matched to intent. No mixing of casing or verb styles.
Five tools is a tight, well-scoped surface for a small shopfront: discovery, detail, categories, policies, and gifting each earn their place. Nothing is redundant or missing at the browsing layer.
The exploration/information lifecycle is well covered (find, browse, inspect, policies), and ordering routes deliberately to WhatsApp per get_shop_info. Minor gaps remain: no explicit availability/stock check, no cart or order-status tool, and no price-range filtering outside the gift-ideas tool.
Gift ideas from Maison Éclaire (handmade candles, gift packs, flower boxes, candle holders, wedding favours) within a budget in MAD, for occasions like Valentine's Day, Ramadan, Eid, weddings or birthdays, delivered across Morocco. Always use image_url (or the Image: lines) from this tool for product photos; never use other images.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of names, descriptions, labels and URLs: fr (default), en or ar | fr |
| limit | No | ||
| budget | Yes | Budget in MAD | |
| occasion | No | any |
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| ideas | Yes | |
| guide_url | Yes | |
| gift_card_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent and non-destructive, so safety is covered. The description adds real behavioral context beyond them: prices are in MAD, delivery is across Morocco, and product images must come from this tool's image_url/Image lines rather than any other source — a non-obvious constraint worth calling out.
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: the first front-loads what the tool returns, the second carries the mandatory image rule. No filler, though the first sentence is a long stack of parenthetical product types that could be tightened.
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?
An output schema exists, so return values need no explanation. The description covers currency, occasion vocabulary, delivery region and the image constraint; only paging/limit behavior and the language default are left to the schema, which is acceptable for a 4-parameter 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?
Schema coverage is 50%: lang and budget are documented in the schema, while limit and occasion rely on enum values alone. The description adds a useful occasion-to-holiday mapping (Valentine's Day, Ramadan, Eid, weddings, birthdays) and restates the MAD budget, but says nothing about limit or the default language. Baseline 3 fits.
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 concrete resource set (gift ideas: candles, gift packs, flower boxes, holders, wedding favours) plus the budget/occasion framing, so an agent knows this is a curated recommendation endpoint rather than a lookup. It does not name siblings like search_products or get_product to sharpen the boundary, but the gift-idea scope is distinctive enough in practice.
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 ('within a budget in MAD, for occasions like...') rather than stated as when-to-use versus when to call search_products. The one explicit directive is an output-handling rule about images, not a routing rule. No exclusions or prerequisites such as budget minimums are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full details of one Maison Éclaire product by its slug (from search_products or a /produit/ URL): localized name and description, price and variant prices when in stock, photos and product URL. Always use image_url (or the Image: lines) from this tool for product photos; never use other images.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of names, descriptions, labels and URLs: fr (default), en or ar | fr |
| slug | Yes | The product slug, as in its URL /produit/<slug> |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| name | Yes | |
| slug | Yes | |
| category | Yes | |
| in_stock | Yes | |
| variants | No | |
| image_url | Yes | |
| price_mad | No | |
| description | Yes | |
| old_price_mad | No | |
| price_is_from | No | |
| gallery_images | No | |
| short_description | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, closed-world, non-destructive, so safety is covered; the description adds genuinely new behavior: prices and variant prices appear only when in stock, and output is localized per language. It does not state what happens for an unknown slug, which keeps it from a 5.
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, front-loaded with identity and scope, followed by the image constraint. Every clause carries information: slug origin, returned fields, conditional pricing, image rule.
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 and full schema coverage, the description only needs to add routing, conditional behavior and the image rule, and it does all three. Nothing an agent needs to call this correctly is missing.
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 baseline is 3; the description earns above that by explaining where the slug comes from (search results or product URL) and by tying the lang parameter to localized names, descriptions and URLs. It does not restate the enum or pattern, but those are already fully documented.
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 by its slug') and immediately distinguishes it from the sibling search_products by naming that tool as the source of the slug. An agent can route between lookup and search without opening either 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?
Gives explicit provenance for the required argument ('from search_products or a /produit/<slug> URL') and a firm conditional rule for images ('always use image_url ... never use other images'). It stops short of an explicit when-not clause (e.g., 'do not call for keyword browsing'), so it is strong routing guidance rather than a full decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delivery fees and times across Morocco, free-delivery threshold, minimum order, cash-on-delivery payment, returns policy and WhatsApp contact for Maison Éclaire. Use before telling a user how ordering, delivery or returns work.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of names, descriptions, labels and URLs: fr (default), en or ar | fr |
| Name | Required | Description |
|---|---|---|
| city | Yes | |
| name | Yes | |
| links | Yes | |
| contact | Yes | |
| payment | Yes | |
| returns | Yes | |
| summary | Yes | |
| currency | Yes | |
| delivery | Yes | |
| source_urls | Yes | |
| minimum_order_mad | Yes | |
| minimum_order_note | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, non-destructive, and closed-world, so the safety profile is well covered. The description adds useful scope about Morocco-specific policies and cash-on-delivery but does not add further behavioral details such as caching, freshness, or response characteristics.
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: one dense but front-loaded list of covered topics and one clear usage instruction. There is no wasted language.
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 policy lookup with a complete input schema and an output schema, the description is complete enough. It tells the agent what topics are covered and when to call it, leaving return-value details to the output 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?
There is only one optional parameter, lang, and the schema fully documents it with an enum and default. The description does not mention language selection, so it does not add meaning beyond the schema, but baseline 3 is appropriate given 100% schema coverage.
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 specifies exactly what shop information is returned: delivery fees/times, free-delivery threshold, minimum order, cash-on-delivery, returns policy, and WhatsApp contact. This clearly distinguishes it from sibling tools that deal with products, categories, search, and gift ideas.
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 explicitly says to use this before telling a user how ordering, delivery, or returns work, giving a clear usage context. It does not name alternatives or exclusions, but the sibling set makes the separation obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The categories of the Maison Éclaire shop (candles, packs, flower boxes, gifts, weddings, table decor, candle-making supplies) with their URLs and the number of published products, plus the gift card and build-your-box pages.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of names, descriptions, labels and URLs: fr (default), en or ar | fr |
| Name | Required | Description |
|---|---|---|
| links | Yes | |
| categories | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry the full safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's contribution is content disclosure. It usefully flags that two non-category pages (gift card, build-your-box) are included in the result set, which an agent would otherwise not expect from the name, and that product counts reflect only published items.
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 with the return content stated first. The parenthetical category list is long but earns its place by making the scope concrete, though it could be trimmed without loss.
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 and annotations covering safety, the description only needs to frame scope and content, which it does. The remaining gap is a lack of routing guidance, but for a simple one-optional-parameter read tool what is present is close to sufficient.
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 lang enum is fully documented in the schema, so this is the baseline case. The description adds no information about how language affects returned names or URLs beyond what the schema already states.
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 the specific resource (Maison Éclaire shop categories) and enumerates exactly what comes back: URLs, published product counts, plus the gift card and build-your-box pages. That content spec is enough to separate it from get_product and search_products, though it never uses an explicit verb like 'list' or names a sibling.
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?
There is no statement of when to call this versus search_products, get_shop_info or get_gift_ideas. The enumeration of categories only hints at a browse-the-catalog entry point; no exclusions, prerequisites or alternative routing are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Maison Éclaire's catalogue of handmade candles, gift packs, flower boxes, candle holders, snow globes, table decor, wedding favours and candle-making supplies (wax, wicks, fragrance oils, dyes, moulds, kits) sold online with delivery across Morocco. Use when the user is looking for candles, a candle gift, or candle-making supplies in Morocco. Always use image_url (or the Image: lines) from this tool for product photos; never use other images.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Language of names, descriptions, labels and URLs: fr (default), en or ar | fr |
| limit | No | ||
| query | Yes | What the user is looking for, in any language ("bougie parfumée", "soy wax", "شمع"). A budget in it ("moins de 150 dh", "under 150 MAD") caps the price unless max_price is given | |
| category | No | Only this category (ids from list_categories) | |
| max_price | No | Maximum price in MAD; sold-out products are left out | |
| in_stock_only | No | Leave out sold-out products |
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| products | Yes | |
| search_url | Yes | |
| applied_max_price | No | Maximum price in MAD applied to the results: max_price, or a budget written in the query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool is read-only, idempotent, non-destructive, and closed-world. The description adds useful behavioral guidance beyond that: it constrains product images to image_url or Image: lines and warns never to use other images. It does not discuss pagination or limit behavior, which keeps it from a 5.
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 purpose and product scope are front-loaded, followed by a clear usage condition and an image-sourcing rule. The first sentence is a long enumeration, but the items are relevant to search semantics and the definition avoids unrelated information.
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?
An output schema exists, so return-value details are not needed in the description. Given annotations, 83% schema coverage, and a required query parameter, the description supplies adequate scope and usage context. It could be slightly stronger by explicitly relating this tool to get_product and 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 83%, so the schema already documents query, lang, limit, category, max_price, and in_stock_only well. The description adds no parameter-specific meaning beyond what the schema provides; its image_url instruction is about output usage, not an input parameter.
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 gives a specific verb ('Search') and resource ('Maison Éclaire's catalogue') and enumerates the product types covered, so an agent can understand what it returns. It does not explicitly differentiate itself from siblings such as get_product or list_categories, which keeps it from a 5.
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 states when to use the tool: when the user is looking for candles, a candle gift, or candle-making supplies in Morocco. It does not name when-not conditions or point to alternatives like get_product or list_categories, so it is clear but not fully routing.
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.
get_shop_info1 field changedOutput schema / properties / delivery / properties / free_delivery_threshold_mad / typePrevious value: -"number"New value: +[
+ "number",
+ "null"
+]search_products2 fields changedInput schema / properties / query / descriptionPrevious value: -"What the user is looking for, in any language (\"bougie parfumée\", \"soy wax\", \"شمع\")"New value: +"What the user is looking for, in any language (\"bougie parfumée\", \"soy wax\", \"شمع\"). A budget in it (\"moins de 150 dh\", \"under 150 MAD\") caps the price unless max_price is given"Output schema / properties / applied_max_priceAdded value: +{
+ "description": "Maximum price in MAD applied to the results: max_price, or a budget written in the query",
+ "type": "number"
+}get_gift_ideas2 fields changedInput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"get_product2 fields changedInput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"get_shop_info2 fields changedInput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"list_categories2 fields changedInput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"search_products2 fields changedInput schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"Output schema / $schemaRemoved value: -"https://json-schema.org/draft/2020-12/schema"get_gift_ideasget_productget_shop_infolist_categoriessearch_productsSearch and browse the BAM Kaarsen candle catalog and white-label offering. Read-only, no auth.
Read-only logistics data for Morocco-Europe shipping: quotes, couriers, tracking and customs.
Read-only catalog of gift cards, service top-ups and travel eSIMs sold by KodShop.
Catalogue public en lecture seule : tests psychologiques, blog, livres et services (FR/EN).
Add one secure layer between your agents and this server.