Shop SIIL clothing: discover products and sizes, then open a secure SIIL checkout link.
Scored across 10 tools
The set is split cleanly into a com (WooCommerce) family and an org (Medusa) family, with get_product/search_products versus get_org_product/search_org_products clearly labelled by store and by language. The only soft overlaps are get_categories vs. category-based browsing in search_products, and get_checkout_link vs. the product tools that also return a pay-on-site URL, but the descriptions spell out the read-only vs. detail distinction well enough to avoid misselection.
Every tool follows a strict verb_noun pattern using only two verbs (get_ and search_), with predictable pairings: search_products/get_product, search_org_products/get_org_product, search_blog/get_blog_post. The _org_ infix is applied consistently across the second storefront, so the store qualifier is easy to pattern-match.
Ten tools sits in the well-scoped range, and each maps to a real shopper need (discover, inspect, checkout, shipping, policies, blog). The only slight bloat is the duplicated product surface for two storefronts, especially since get_checkout_link already unifies both stores behind a single `store` parameter, suggesting products could have been consolidated the same way.
The discovery-to-purchase path is fully covered: category browse, keyword search, product detail with variations, checkout link, shipping zones, and store policies/contact. Gaps are post-purchase — no order status/tracking or returns/exchange operation — and get_categories appears to describe only the com catalogue with no equivalent listing for the org store.
Get the full content of a SIIL clothing-brand blog article.
Returns the complete article text for a specific blog post.
Use search_blog first to find relevant articles, then use this
tool to read the full content.
Args:
post_id: Blog post ID (from search_blog results)
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it returns complete article text and that post_id originates from search_blog, but says nothing about error behavior for an invalid/missing ID or how large articles are returned. With annotations doing the heavy lifting, this is adequate rather than rich.
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 verb and resource, then workflow guidance, then Args. The middle sentence 'Returns the complete article text for a specific blog post' partly restates the opening line, a small redundancy, but nothing else 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?
A single-parameter read tool with an output schema, so return-value documentation isn't required. The description covers purpose, prerequisite workflow, and parameter provenance; only failure modes for a bad post_id are absent, which is 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 0%, so the description carries the burden for the single parameter. The Args block gives provenance ('from search_blog results'), which is genuinely useful routing information the schema lacks, though the integer type and ID format are left to 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+resource ('Get the full content of a ... blog article') and explicitly scopes it to full-text retrieval versus the search sibling. An agent can distinguish it from search_blog without opening any 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?
Names the prerequisite alternative directly: 'Use search_blog first to find relevant articles, then use this tool to read the full content.' The condition that selects this tool over search_blog is spelled out, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all SIIL Ostomy product categories with product counts.
Returns categories like Belts, Swimwear, Panties, Wraps, Lingerie, Accessories/Protectors, and Kids.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare that this is a read-only, idempotent, non-destructive operation. The description adds useful return context by saying categories include product counts and by giving examples, but it does not add behavioral details such as ordering, pagination, or auth requirements.
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, front-loaded with the core purpose, and contains no filler. The examples add useful context without making it verbose.
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 zero-parameter read-only tool with annotations and an output schema, the description is complete enough. It states what is listed, mentions product counts, and gives representative examples.
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 semantics are not a meaningful gap. The description appropriately does not invent parameters or add unnecessary invocation instructions.
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: listing all SIIL Ostomy product categories with product counts. It is clear what the tool does and gives examples, though it does not explicitly differentiate itself from product-searching siblings.
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 no explicit guidance about when to use this tool versus alternatives such as search_products or get_product. Usage is only implied by the phrase 'List all' and the category examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a SIIL checkout link for one shopper-selected product and size/colour.
Read-only: returns a URL, creates no order/cart and takes no payment. The shopper
opens the link and reviews current availability, total, delivery and pays on SIIL.
Opening it starts a new cart and can replace an existing cart. Ask for size/colour
before selecting a variant. Never request personal, address or card data in chat.
Args:
store: com (WooCommerce) or org (Medusa).
product_id: Product ID from get_product or get_org_product, not a variant ID.
variant_id: Exact variation ID from that product; required for all size choices.
quantity: Integer 1-10.
lang: com: en, en-gb, es, fr, de. org: it, pl, cs, sk, sv, da, nb, fi, nl, el, hu, ro, pt, ja.
handle: org product slug from get_org_product, in the same language.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | en | |
| store | No | com | |
| handle | No | ||
| quantity | No | ||
| product_id | No | ||
| variant_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/destructive annotations: it explains that the call returns only a URL, creates no order or cart, takes no payment, and — critically — that 'Opening it starts a new cart and can replace an existing cart', a side effect the annotations cannot express. The PII warning adds further operational context an agent needs.
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-loads purpose, then behavior, then args in a scannable block — good ordering. Slightly redundant in places (the size/colour instruction appears both in prose and in the variant_id arg line), but with 0% schema coverage the Args block is necessary rather than padding.
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 six-parameter, no-output-schema tool it covers the return value (a URL), the side-effect profile, language constraints, and input prerequisites. It leaves minor gaps: link expiry, and error behavior when a variant_id does not match the product.
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 carries the full burden and does: store values (com=WooCommerce, org=Medusa), product_id vs variant_id distinction, quantity bound 1-10, per-store language lists, and handle defined as an org slug in the same language. This is meaning no agent could recover from the bare 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 — 'Get a SIIL checkout link for one shopper-selected product and size/colour' — and scopes it to a single product/variant, which clearly separates it from the sibling search_products/get_product tools that supply IDs. An agent can tell what it produces (a URL) 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 concrete workflow preconditions: 'Ask for size/colour before selecting a variant', product_id must come from get_product or get_org_product, and 'Never request personal, address or card data in chat'. It routes to the sibling tools for input sourcing, though it never states a case where this tool is the wrong choice outright.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One siilostomy.org product: photos, sizes, EUR amount, and the page to pay on.
Args:
handle: Slug from search_org_products for that same language.
lang: it, pl, cs, sk, sv, da, nb, fi, nl, el, hu, ro, pt, ja.
product_id: Numeric id, if the handle is unknown.
The person pays on the returned url. This tool does not create an order.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | it | |
| handle | No | ||
| product_id | No |
| Name | Required | Description |
|---|---|---|
| result | 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 earns credit by adding that no order is created and that the actual payment happens on the returned URL, which is real behavioral context an agent needs before deciding to call it.
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 is front-loaded in one sentence, then args, then the payment caveat. Every line carries information; the only softness is the somewhat repetitive two-sentence payment note, which could be one sentence.
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 explain return values, and it correctly focuses on parameters and the no-order behavior. It is nearly complete; missing only explicit handle-vs-product_id precedence and any hint about failure when a product is not found in the given language.
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 largely does: handle is defined via its source (search_org_products, same language), lang is given the full list of accepted codes absent from the schema, and product_id is framed as the fallback when handle is unknown. Only the precedence/interaction between handle and product_id is left implicit.
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?
First sentence names the specific resource (a single siilostomy.org product) and enumerates the returned content: photos, sizes, EUR amount, and the payment URL. This clearly separates it from search_org_products, but it never distinguishes itself from the sibling get_product, so the agent cannot tell which single-product tool applies.
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 one strong usage signal – the handle comes from search_org_products in the same language – and an exclusion ('does not create an order', payment happens on the returned url). However, there is no guidance on when to prefer this over the sibling get_product or what to do when neither handle nor product_id is known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for a specific SIIL Ostomy product.
Provide either product_id or sku. Returns complete product information
including description, images, attributes, variations, and pricing.
Args:
product_id: WooCommerce product ID (e.g. 15570)
sku: Product SKU (e.g. "MB01720")
| Name | Required | Description | Default |
|---|---|---|---|
| sku | No | ||
| product_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive behavior, so the bar is lower; the description still adds value by enumerating returned content (description, images, attributes, variations, pricing) and the either-or identifier rule. It omits error behavior (e.g., unknown SKU) and whether the lookup is exact-match only.
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 capability, followed by a tight usage sentence and a short Args block where each line earns its place. Slightly redundant to restate return fields when an output schema exists, but the text stays compact.
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 two-parameter read tool with an output schema, the essentials are covered: what it fetches, how to identify the product, and roughly what comes back. The only missing piece an agent might need is dispute resolution between the two identifiers, which is 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 description coverage is 0%, so the description carries the burden, and it does so well: it names the identifier style (WooCommerce product ID) and gives concrete examples for both parameters, plus the mutual-exclusivity hint. Minor gap: it does not specify precedence when both are passed or the failure mode when neither is.
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 ('Get full details for a specific SIIL Ostomy product') and scopes it to a single-product fetch, which contrasts implicitly with the sibling search_products/get_org_product. It stops short of naming an alternative, so it is clear but not fully sibling-differentiated.
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?
'Provide either product_id or sku' gives a concrete usage rule for lookups, which is real guidance beyond the schema. However, it never says when to use this tool versus search_products or get_org_product, nor what happens if both or neither identifier is supplied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get shipping information for SIIL Ostomy orders.
Returns shipping zones, delivery times, and carriers.
SIIL ships from Spain (EU) and USA warehouses.
Args:
country_code: ISO 2-letter country code (e.g. "US", "DE", "JP").
If provided, returns the specific zone for that country.
| Name | Required | Description | Default |
|---|---|---|---|
| country_code | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, open-world, and non-destructive behavior. The description adds useful context beyond that: the data categories returned and the fact that shipping depends on EU and USA warehouse origins. It does not disclose rate limits or whether the open-world lookup is live, 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 description is short, front-loaded with the core purpose, and organized into a concise summary plus an Args section. Every sentence contributes either scope, return content, or parameter meaning.
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, single-parameter lookup with an output schema, the description is complete enough. It states the scope, return categories, warehouse context, and optional parameter behavior, so an agent can call it correctly without needing more.
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 parameter semantics. It does so well: country_code is documented as an ISO 2-letter code with examples ("US", "DE", "JP") and an explicit conditional behavior when provided versus omitted.
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 uses a specific verb and resource (get shipping information) scoped to SIIL Ostomy orders, and enumerates what is returned: shipping zones, delivery times, carriers, and warehouse origins. This clearly distinguishes it from the product, blog, category, and store-info sibling tools.
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 the context: SIIL Ostomy orders, with warehouses in Spain and the USA. It also explains that supplying a country code narrows the result to that country's zone. It does not explicitly state when not to use it, but there are no obvious sibling alternatives for shipping information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get SIIL store information, policies, and contact details.
Returns store description, return policy, payment methods, shipping overview, and contact information.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, so safety is covered. The description adds the scope of returned content but nothing about freshness, caching, or whether info is static vs live — an openWorldHint tool would benefit from that.
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 short sentences, front-loaded with the purpose. The second sentence restates 'contact details' as 'contact information' and lightly re-treads the first, which is mild waste but not harmful.
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?
A parameterless, read-only lookup with an output schema and full annotations needs little more than a scope statement, and this provides it. Only the tie-break against get_shipping_info 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?
Zero parameters, so the baseline applies; the description correctly implies no input is needed and doesn't invent any.
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 ('Get SIIL store information') and enumerates the content areas covered, so it is clearly distinct from product/blog/search siblings. Minor overlap with get_shipping_info via 'shipping overview' 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?
Usage is implied: fetch store-level metadata. No explicit when-to-use framing and no mention of the closest alternative (get_shipping_info) or any precondition, leaving the agent to infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the SIIL clothing-brand blog for apparel and lifestyle articles.
Args:
query: Search keywords. Examples: "swimwear", "belt", "underwear",
"travel outfit", "fit"
limit: Number of results (max 20, default 10)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds the result-count cap (max 20) as a useful practical constraint but says nothing about result ordering, pagination, or what an empty result means.
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 one-sentence purpose followed by a compact Args block; no wasted prose. The example keywords are mildly verbose but demonstrate intent usefully.
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?
Output schema exists, so return-value explanation is unnecessary, and a 2-param read-only search tool needs little else. The only real gap is the semantics of an empty query string, which matters because the parameter is optional with a default.
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 must carry the parameters, and it does add key facts: query is keywords, and limit has a max of 20 and default of 10. However, it never explains that query defaults to an empty string (does an empty query return everything or nothing?), leaving the most consequential ambiguity unresolved.
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 SIIL clothing-brand blog') and scopes the content to 'apparel and lifestyle articles', which implicitly separates it from product-search siblings like search_products. It never names get_blog_post as the contrasting retrieval-by-id tool, so differentiation remains implicit rather than stated.
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 word 'Search' implies keyword-based discovery versus the sibling get_blog_post (fetch one post by id), but the description never says when to use this over that sibling or over get_categories. Usage must be inferred from the verb alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search siilostomy.org in the shopper's language.
Use this for Italy, Poland, Czechia, Slovakia, Sweden, Denmark, Norway,
Finland, the Netherlands, Greece, Hungary, Romania, Portugal and Japan.
English, Spanish, French and German are search_products on siilostomy.com.
Args:
query: Words in that language, or a product family (belt, panties).
lang: it, pl, cs, sk, sv, da, nb, fi, nl, el, hu, ro, pt, ja.
Country names work too (poland, japan, czech).
limit: How many products to return. Max 12.
Returns the title, the photo, the EUR catalog amount, and the product
page. The page shows the local currency. The person pays on that page.
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | it | |
| limit | No | ||
| query | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuinely new operational facts: a hard cap of 12 results, that amounts are shown in EUR catalog terms while the product page shows local currency, and that payment happens on the page rather than in this tool. It doesn't mention auth needs or pagination/failure behavior, which keeps it short of 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?
Routing information is front-loaded, then args, then returns – a sensible ordering with no filler. The returns paragraph partially restates what the output schema already carries, which is a small redundancy rather than a flaw.
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 search tool with an output schema, everything an agent needs to call it correctly is present: routing, language codes, result cap, and a note on currency/checkout semantics. The structural richness (output schema) covers the return payload, and the description fills the remaining 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 coverage is 0%, so the description must carry all parameter meaning, and it does: query is defined as words in the target language or a product family (belt, panties), lang lists all 12 codes plus the fact that country names also work, and limit is bounded at max 12. Only minor gap is that defaults (it, 8, empty query) are left to 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?
Opens with a specific verb+resource and domain: 'Search siilostomy.org in the shopper's language.' This immediately separates it from the sibling search_products, which is scoped to siilostomy.com, and the description states that split explicitly later.
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?
Enumerates exactly which countries/languages this tool covers and names the alternative ('English, Spanish, French and German are search_products on siilostomy.com'), giving an unambiguous routing rule with both when-to-use and when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search SIIL clothing by keyword, category, or price range.
Args:
query: Search keywords (matches product name, SKU, description).
A lone category word (swimwear, belts, underwear) browses that
live slug instead of full-text. Examples: "swimwear", "belt black", "MB01720"
category: Filter by English name or live Woo slug.
Aliases: swimwear=banoen, belts=cinturon-siil-en,
underwear=intimo-en, panties=panties, wraps=bandas-en,
lingerie=bodies-en, protector=siil-protector-en, accessories
min_price: Minimum price in EUR (e.g. 30.0)
max_price: Maximum price in EUR (e.g. 100.0)
limit: Number of results (max 50, default 20)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| category | No | ||
| max_price | No | ||
| min_price | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, so the safety bar is low; the description adds real behavioral detail beyond them — the 50-result cap (default 20 is in the schema, the cap is not), the lone-category-word slug-browsing quirk, and the alias resolution table.
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 one-line purpose followed by a compact Args block; every line carries information. The alias list is long but each entry maps a real user term to a required slug, so it earns its space.
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?
A 5-parameter search tool with no annotations gaps and an output schema, and the description covers all parameters plus result capping. Minor gaps remain: no statement of default behavior with an empty query, result ordering, or pagination beyond the limit.
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% — parameters carry only titles and defaults — so the description carries the full burden and does it well: query matching fields and examples, category aliases mapped to live slugs, min/max price currency, and the max-50 limit that is absent from 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 (search) and resource (SIIL clothing) plus the three axes of search: keyword, category, price range. That distinguishes it from get_product (single item), but it never explicitly distinguishes itself from the sibling search_org_products, leaving the agent to infer the difference.
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 explains how to search (lone category words browse a slug rather than full-text) but gives no guidance on when to choose this tool over get_product or search_org_products, nor what happens with an empty query. Usage is implied rather than directed.
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_blog_postget_categoriesget_checkout_linkget_org_productget_productget_shipping_infoget_store_infosearch_blogsearch_org_productssearch_productsMerch for AI builders. Search 8 products (tees, hoodies and a sticker sheet), read sizes, colors and prices, get US shipping quotes, and create a checkout link a person pays on Stripe. No auth required.
Shop the Is Agentic store with read-only catalog discovery, gift recommendations and cart links.
AI shopping gateway for product search, inventory, carts, and merchant-hosted checkout.
AI fashion design — product photos, videos, tech packs, colorways & fabric sims.
Add one secure layer between your agents and this server.