Shop GENOSYS Korean skincare in the UAE from chat: find products, AED prices, order and pay.
Scored across 11 tools
search and search_products both search the catalog with near-identical names, and an agent could easily pick the wrong one despite the 'returns ids vs rich details' distinction. The purchase flow is split three ways (create_bag_link, open_checkout, place_order), which are overlapping paths to the same goal and easy to misselect, and fetch overlaps with get_product for product content.
Most tools follow a verb_noun pattern (create_bag_link, get_product, list_categories, open_checkout, place_order, recommend_routine, search_products), with only a few noun-phrase info tools (order_status, store_info) and bare verbs (fetch, search). The convention is largely predictable with minor deviations.
11 tools is well-scoped for a full shopping assistant covering discovery, detail, recommendation, cart, checkout, orders, and store info. Each tool earns its place without redundancy in count.
The surface covers the full lifecycle: orient (list_categories), search, product detail, recommend, cart link, checkout, order placement, order status, and store policies. Minor gaps like order history, cancellation, or returns initiation exist but core workflows are covered.
Build one link that opens genosys.ae with these items already in the shopper's bag, ready to check out. Use when the shopper decides to buy. Products with sizes or shades (see get_product options) need one picked: pass size, or color as its label or value (e.g. "#01 Bright").
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive, closed-world, so the safety profile is covered. The description adds genuine context beyond that: the conditional requirement that sized/shaded products need a size or color picked, and the '#01 Bright'-style label/value format.
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, front-loaded with the outcome, then the usage trigger, then the parameter caveat. No filler and every sentence carries 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?
No output schema exists, and the description conveys what the artifact is (a link that opens the site with items pre-loaded). The cross-reference to get_product options is helpful. It stops short of stating the exact return shape and how the link relates to open_checkout, which would fully close the loop.
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?
With 0% schema description coverage the description carries the full burden, and it explains the non-obvious conditional requirement (size or color for sized/shaded products) that JSON schema cannot express. It omits quantity semantics and the 20-item cap, which are discoverable from the schema constraints themselves.
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?
Specific verb+resource: builds a pre-filled genosys.ae bag link. It clearly distinguishes itself from checkout-mutating siblings (open_checkout, place_order) by describing the output as a link rather than a transaction.
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 when the shopper decides to buy" gives a clear trigger condition. It does not explicitly name alternatives such as open_checkout or place_order, so the agent must infer the boundary between building a link and completing a purchase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full text of a result from search, by id ("product:18" or "blog:").
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the id format but nothing about lookup failure behavior or output shape; with annotations carrying the burden, a 3 is appropriate.
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 compact sentence that front-loads the resource and includes the id examples inline. No wasted words, though the examples could be slightly clearer about the prefix scheme.
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-only fetch with no output schema, the description supplies the essential id format. It does not describe not-found behavior, but annotations cover safety and no return-value detail is strictly required.
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 0% and the schema only says 'string', so the description must compensate. It does so by giving two concrete id formats ('product:18', 'blog:<slug>'), which is the key missing information, though it may not enumerate every valid prefix.
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 ('Full text of a result') and the resource ('from search, by id'), and gives concrete id forms. It implies differentiation from siblings like get_product and search, but does not explicitly state what makes it distinct from get_product, which also returns product content.
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 phrase 'from search' implies this is used after a search call, which is a reasonable hint, but there is no explicit when-to-use/when-not statement, no mention of alternatives like get_product, and no guidance on when an id is unavailable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full details for one product: description, key features, benefits, key ingredients and actives, step-by-step how to use, sizes or shades with prices, and an add-to-bag link. Use the id from search_products (e.g. "18" or "68").
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Language of descriptions and links: en (default), ru or ar. Product names stay in English. | |
| product_id | Yes | Product id from search_products, e.g. "18". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the return contents of a single-product fetch, which matters because there is no output 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?
Two sentences, front-loaded with the core purpose; the second only carries the id prerequisite. The field enumeration is dense but each clause maps to information the agent actually needs, so nothing is wasted.
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 two-parameter read tool with full schema coverage and annotations, the description covers purpose, input provenance and return contents. It omits only edge behavior such as what happens for an unknown product id or how locale affects links, which are minor gaps.
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 both parameters are already documented and the enum for locale is defined there. The description reinforces the product_id provenance and format, but adds no new syntax or constraints, so the 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?
States a specific verb and resource ('Full details for one product') and enumerates exactly which fields come back (description, features, benefits, ingredients, usage steps, sizes/prices, add-to-bag link). This distinguishes it cleanly from the sibling search_products, which only locates 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?
Explicitly tells the agent to use the id obtained from search_products and gives concrete id examples ("18" or "68"), which is the key prerequisite. It does not state when not to call it (e.g. batching many ids), so it stops short of a full when/when-not rubric.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All product categories and skin concerns in the live catalog, with product counts. Use to orient before searching.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 that this reflects the 'live catalog' (freshness) and includes product counts, which is genuinely useful context, but it says nothing about result size, ordering or shape. With annotations carrying the safety profile, a 3 fits.
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?
One sentence, front-loaded with what is returned and ending with the usage cue. No filler or redundant restatement of the name.
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-argument, read-only listing tool with full annotation coverage and no output schema, the description supplies enough to decide and invoke it. It could go slightly further by hinting at the scale or structure of the returned category list.
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 takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify beyond the schema's empty object.
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?
Names a specific verb and resource ('All product categories and skin concerns... with product counts') and distinguishes itself from the search tools by framing itself as orientation data. It is clear what it returns, though it never names a sibling tool to contrast against.
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 to orient before searching' gives an explicit when-to-use context and implies the workflow ordering (call this, then search). It stops short of naming which sibling to follow up with or stating when not to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the shopper a checkout form for these items: shade picker where needed, quantities, delivery details (name, email, phone, emirate, address), live total and a button that creates the order and opens secure Stripe payment. Use when the shopper wants to buy. Pass any details the shopper already gave as prefill.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| locale | No | Language of descriptions and links: en (default), ru or ar. Product names stay in English. | |
| prefill | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotent/non-destructive, so the safety profile is covered; the description adds useful context beyond that — the form's fields, that payment is handed off to hosted Stripe, and that this renders a UI rather than mutating state itself. It is consistent with readOnlyHint because order creation is attributed to the on-page button, not the tool call.
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?
Front-loaded with the core action, then the form's content, then the trigger and prefill hint — no filler sentences. The middle sentence is list-heavy but each item earns its place by describing what the shopper will see.
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 3-param UI-opening tool with no output schema and annotations covering the safety profile, the description supplies trigger, form contents, and prefill handling. It never says what the call itself returns or acknowledges limits like max 20 items, which is the remaining 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?
At 33% schema coverage the description has to compensate, and it does for two of three params: it explains that items drive quantities and a shade picker (implying color/size), and it lists the prefill fields (name, email, phone, emirate, address). locale is left to the schema's own description, so it is not fully covered, but the semantic load-bearing params are.
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?
Specific verb and resource: 'Show the shopper a checkout form for these items', with the form's contents enumerated (shade picker, quantities, delivery details, live total, Stripe button). The distinction from the sibling place_order is only implied by the fact that order creation happens via an on-page button, not stated by name, so it stops short of 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?
'Use when the shopper wants to buy' gives a clear trigger, and 'Pass any details the shopper already gave as prefill' is actionable pre-call guidance. It does not name or exclude the alternative siblings (place_order, create_bag_link), which is the main gap for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Status and payment of a GENOSYS order. Needs the order number and the email used for the order.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| order_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the safety profile is covered. The description adds one genuinely non-obvious behavior: the lookup is gated on supplying the email used at order time, which is an authorization/lookup constraint not visible in the annotations. It says nothing about error behavior when the email does not match, or about pagination/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 compact sentences with no filler, and the purpose (status and payment) is front-loaded ahead of the prerequisite. Nothing in the text is redundant.
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 two-parameter read with no output schema and no nested objects, the description covers what the tool returns and what it requires. It could be marginally stronger by saying whether shipping/delivery details are included and what a failed lookup looks like, but nothing an agent needs to call it 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 description coverage is 0%, so the description must carry the load, and it does supply meaning for both parameters: the order number and the requirement that the email be the one used for the order. That constraint is valuable, but there is no detail on accepted order-number formats, case sensitivity, or how mismatches are surfaced.
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 (a GENOSYS order) and states exactly what it returns: status and payment. That is enough for an agent to distinguish it from place_order or open_checkout, though it never explicitly names a sibling it is not, so it stops short of 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?
There is no when-to-use framing and no mention of alternatives among ten siblings, several of which (place_order, open_checkout, fetch) sit in the same order lifecycle. The only guidance is the implied prerequisite that the caller must already hold an order number and the ordering email.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a GENOSYS UAE order from this chat and get a secure Stripe payment link (card, Apple Pay, Google Pay). Call only after the shopper has confirmed the items, the total and their delivery details. The order is confirmed by email once paid; unpaid orders are not shipped. Delivery is UAE only. Prices are retail AED including VAT.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| notes | No | Delivery notes, e.g. preferred time. | |
| locale | No | Language of descriptions and links: en (default), ru or ar. Product names stay in English. | |
| customer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the basic profile (not read-only, not destructive, non-idempotent, open-world), and the description adds real context: payment is via a Stripe link, order is confirmed by email only once paid, unpaid orders are not shipped, delivery is UAE-only, and prices are retail AED including VAT. It omits the risk implied by idempotentHint=false (calling twice may create duplicate orders/charges), which would be valuable for an agent deciding whether to retry.
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?
Four dense sentences, front-loaded with the action and payment-link outcome, then preconditions, then post-purchase and delivery semantics. No padding or repetition.
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 nested, non-idempotent mutation with no output schema, the description covers what happens after the call (payment link, email confirmation, shipping) and the delivery/pricing constraints. Remaining gaps are failure/retry behavior and whether the payment link expires — minor but noticeable for a checkout 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 description coverage is 50% and the description adds little parameter-level meaning — it does not explain how to build the items array or customer object beyond noting retail AED pricing. The schema itself documents product_id, email matching, phone, address and locale well, so a 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?
States a specific verb and resource ("Create a GENOSYS UAE order") and adds the distinctive outcome (a secure Stripe payment link), which separates it from siblings like create_bag_link, open_checkout and order_status. An agent can identify the tool's job without opening 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?
Gives an explicit precondition: "Call only after the shopper has confirmed the items, the total and their delivery details," plus a hard scope limit (UAE delivery only). It does not name which sibling to use when the precondition is unmet (e.g. create_bag_link before confirmation), 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.
Ranked product picks for a shopper's skin type and concerns, the same scoring as the skin quiz on genosys.ae. Use when someone describes their skin and asks what to use.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 6. | |
| locale | No | Language of descriptions and links: en (default), ru or ar. Product names stay in English. | |
| concerns | No | e.g. ["hydration","anti-aging"]. Tags: hydration, anti-aging, sensitivity, pore-care, brightening, acne-blemishes, eye-care, hair, hair-loss. | |
| age_group | No | ||
| skin_type | No | ||
| at_home_only | No | True (default) leaves out professional clinic-only products. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context that scoring matches the official skin quiz on genosys.ae, but says nothing about required inputs, data freshness, or output structure beyond 'ranked product picks'.
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 filler: the first states the output and its basis, the second states the trigger. Front-loaded and appropriately sized for the tool's complexity.
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 read-only recommendation tool with rich annotations and no output schema, the description covers what is produced and when to use it. It leaves minor gaps around default behavior when called with few or no arguments and exactly how many results are returned, but nothing critical to correct invocation 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 description coverage is 67%, so the description should carry more of the burden. It clarifies that 'concerns' relate to skin concerns, but adds no meaning for limit or locale beyond what the schema already states, and does not explain how a described skin condition maps to the concerns array.
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 output ('Ranked product picks') and its basis ('shopper's skin type and concerns'), which tells the agent exactly what it gets. It doesn't differentiate from sibling tools like search_products or get_product, but the recommendation purpose is distinct enough to distinguish at a glance.
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 a clear trigger: 'Use when someone describes their skin and asks what to use.' This is strong when-to-use guidance. It lacks when-not conditions and never names sibling alternatives such as search_products, so it falls 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 GENOSYS products and skincare articles. Returns ids to pass to fetch. ("product:" for products, "blog:" for articles.)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds valuable context the annotations don't: the return shape of prefixed ids ('product:<id>', 'blog:<slug>') that downstream tools consume. It stops short of noting rate limits or pagination.
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 tight sentences, front-loaded with the purpose and followed by the return-value convention. No filler; both sentences earn their 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?
With no output schema, the mention of return ids is a helpful partial substitute. But the query semantics go unexplained and the overlap with 'search_products' is unresolved, so the definition is only minimally sufficient for correct invocation.
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 0% for the single 'query' parameter, so the description must compensate and does not. It never explains whether the query is natural-language, keyword-based, or how it interacts with the product/article scope, leaving the required parameter's semantics undocumented.
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') and resource ('GENOSYS products and skincare articles'), making the scope clear. However, it never distinguishes itself from the close sibling 'search_products', leaving the agent to guess which search to pick.
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 implied workflow ('Returns ids to pass to fetch'), which is genuine usage context. But it offers no when-not guidance and never names or contrasts with 'search_products', so the alternative-selection decision is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the live GENOSYS UAE catalog (Korean professional skincare, haircare, devices, beauty boxes). Use for any "what do you have for..." question. Accepts plain language in English, Russian or Arabic, plus optional filters. Returns name, price in AED (VAT included), size, stock, concerns and the product link.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Default 8. | |
| query | No | What the shopper wants, e.g. "serum for dry skin", "SPF cushion", "hair loss shampoo". | |
| locale | No | Language of descriptions and links: en (default), ru or ar. Product names stay in English. | |
| concern | No | Skin concern, e.g. hydration, anti-aging, sensitivity, pore-care, brightening, acne-blemishes, eye-care, hair-loss, sun-protection. | |
| category | No | Category filter, e.g. Serum, Cream, Mask, Cleanser, Toner/Mist, Sun, Cushion BB, Eye care, Scalp/Hair, Beauty Boxes, Device, Microneedling, PRO Solution. Call list_categories for the full list. | |
| skin_type | No | ||
| in_stock_only | No | ||
| max_price_aed | No | Only products at or below this price (AED, VAT included). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavior: it queries a LIVE catalog, accepts free-form input in three languages, and enumerates the returned fields (name, price in AED with VAT, size, stock, concerns, link) — which matters since there is no output schema. It does not disclose result-count limits or empty-result behavior, and `limit` is only explained in 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?
Three tight sentences with the scope front-loaded, followed by the usage trigger and the return contract. No filler, no repetition, and the most decision-relevant information (what catalog, when to use) comes first.
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 an eight-parameter, zero-required search tool with no output schema, the description covers what an agent needs: the domain, the natural-language entry point, the supported languages, and the shape of the response. The remaining gaps (pagination semantics, filter combination logic) are secondary and largely inferable from 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 75%, so the schema already carries most parameter meaning, and the description's contribution is largely restatement: 'plain language in English, Russian or Arabic' mirrors the `locale` enum, and 'price in AED (VAT included)' mirrors `max_price_aed`. It adds only the vague phrase 'plus optional filters' without clarifying how `concern`, `category`, and `skin_type` combine (AND vs OR) or that `skin_type` and `in_stock_only` exist at all. 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?
States a specific verb and resource (search the live GENOSYS UAE catalog) and scopes the catalog contents with concrete examples (Korean professional skincare, haircare, devices, beauty boxes). The scope is unambiguous, though the description never distinguishes this tool from the sibling `search` or `list_categories`, so the agent must infer the boundary.
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 a clear triggering condition: use for any "what do you have for..." question, and notes that filters are optional. It stops short of naming alternatives (get_product for a known SKU, list_categories for browsing taxonomy) or stating when NOT to use it, so the routing decision against siblings is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delivery areas, times and fees, payment methods, returns, contact (WhatsApp, email), apps and policies for GENOSYS UAE.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Language of descriptions and links: en (default), ru or ar. Product names stay in English. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds scope context (UAE-specific store policies and support channels) but says nothing about return format, freshness, or whether the info is locale-dependent beyond what the schema already states.
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 that front-loads the resource and packs the content domains into a compact list with no filler. The list is slightly run-on, but every item is informative and nothing is wasted.
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-required-parameter, read-only info lookup with a fully documented enum and no output schema, the description is sufficient — an agent knows what topics this returns and that it is safe and idempotent. It would be stronger with a brief note on when to prefer this over the transactional siblings.
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 sole `locale` parameter is already fully documented in the schema, including the enum values and the note that product names stay in English. The description never mentions locale, so it adds no meaning beyond the schema; 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 names a concrete resource (store information for GENOSYS UAE) and enumerates the specific content domains it returns — delivery, payment, returns, contact, apps, policies. It is easily separable from the sibling tools (search, get_product, order_status, place_order), which all deal with products or transactions rather than static store metadata. It lacks an explicit verb like 'retrieve', but the intent is 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?
Usage is only implied by the topic list: an agent can infer it should call this for shipping/returns/payment questions, but there is no explicit 'use this when…' statement, no mention of when NOT to use it, and no reference to alternatives. For a tool whose siblings overlap in the shopping domain, an explicit routing cue would help.
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.
create_bag_linkfetchget_productlist_categoriesopen_checkoutorder_statusplace_orderrecommend_routinesearchsearch_productsstore_infoSearch Singapore skincare and beauty, build guest carts, and prepare buyer checkout links.
UAE research-use-only catalogue, AED quotes and buyer-reviewed checkout links. No order submission.
Wholesale Korean skincare for US and Canadian resellers: case prices, margins, checkout links.
Birinchi Shop is an online store in Uzbekistan. Your AI assistant can search products, show the price with the 30,000 UZS delivery fee, and place a cash-on-delivery order for you — only after you confirm. A call-center operator phones to confirm every order; delivery takes 1–3 days to all regions. No API key or sign-up needed.
Add one secure layer between your agents and this server.
