Knitwear and layers: search the catalogue, sizes and size charts, delivery, policies, order status.
Scored across 4 tools
Each tool targets a clearly different need: single-product detail, catalog search, static policy text, and order lookup by reference. The boundaries between search_products (browse/discover) and get_product (deep detail on one item) are explicitly stated, so an agent can pick correctly.
All names use snake_case with a verb_noun shape (get_product, search_products, track_order), which is easy to scan. The one minor deviation is store_policies, which reads as a noun phrase rather than an action verb.
Four tools is lean but each covers a distinct job in a storefront assistant, with no filler. It sits slightly on the thin side since there is no cart or category-browsing tool, but nothing is redundant.
Discovery, detail, policy and post-purchase tracking are all covered, and get_product explicitly returns the buy page so purchase is handled outside the server. The notable gap is the lack of any cart/checkout or department-listing operation, though an empty search partially substitutes for browsing.
Everything the product page says about one piece: price, sizes, colour, story and details, the supplier's size chart (garment measurements), delivery estimate, returns, customer reviews and the page to buy it on.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The piece's slug, from search_products (e.g. the-otter-sweater) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds value by disclosing the breadth of returned data (size chart, delivery estimate, reviews, buy link), but says nothing about failure behavior for an unknown slug or whether any fields can be absent.
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 no filler. The inventory list of returned sections is long but each item earns its place by telling the agent what data is available. Slightly dense as one breathless clause rather than a clean structure.
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 enumeration of returned sections is exactly the right compensating detail and makes the tool's payload predictable. Only gap is the absence of any error or empty-result behavior for an invalid slug.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the slug parameter and its provenance from search_products are already documented in the schema. The description does not mention the parameter at all, so no meaning is added beyond the structured field. 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 clearly scopes the tool to a single product ('one piece') and enumerates what is returned, which distinguishes it from search_products by cardinality even without naming the sibling. The verb 'get' is only implied via the title, so it is clear but not maximally explicit.
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 rather than stated: an agent must infer that this is the follow-up call after search_products yields a slug. The only routing cue lives in the schema's parameter description, not the tool description, and no conditions or exclusions for store_policies or track_order are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find pieces in this store by words (e.g. 'wool sweater', 'cardigan', 'rust'), optionally filtered by department, size and maximum price. Empty query lists every piece.
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | e.g. M or XL | |
| limit | No | ||
| query | No | Words to search for; empty lists every piece | |
| max_price | No | Maximum price in the store's currency (major units) | |
| department | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed-world scope, so the safety profile needs no restating. The description adds one genuine behavioral fact ('empty query lists every piece') but says nothing about result ordering, the effect of the limit cap, or whether results are truncated.
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, front-loaded with the primary action, and no restatement of annotation or schema content. Every clause carries information the agent would otherwise have to infer.
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 all-optional five-parameter search with no output schema, the description is nearly sufficient. The main omission is any hint of the result shape or how the limit interacts with the returned list, but the core selection and filtering behavior is fully covered.
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 60%, and the description compensates meaningfully: the examples 'wool sweater', 'cardigan', 'rust' signal that material and color words match, not just product names, which the schema's generic 'Words to search for' does not convey. The limit parameter is never mentioned in the description, leaving a small gap.
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 ('Find pieces in this store by words') plus the filter axes, and the phrase 'by words' plus 'empty query lists every piece' implicitly separates it from get_product, which fetches a single item by identifier. An agent can route between them 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 clear context for when this tool applies (free-text lookup, optionally narrowed by department/size/price) and explicitly notes the empty-query fallback to listing everything. It does not name alternatives such as get_product for a known item, so there is no exclusion rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shipping, returns, privacy, terms or contact policy, in full, as published.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description's job is to add context. 'In full, as published' does exactly that: it tells the agent the response is the complete, authoritative published text rather than a summary or excerpt, which is information no annotation conveys.
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 eleven-word fragment with no filler, and the substantive qualifier ('in full, as published') is placed where it will be read. It is arguably over-compressed to the point of being a phrase rather than a sentence, but nothing in it 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 one-enum-parameter read tool with rich annotations and no output schema, the description supplies the essentials: which policies exist and that the full published text is returned. The only mild gap is the response shape (plain text versus structured document with sections), which an agent could reasonably want to know.
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%, but the sole parameter is a closed enum whose five values are self-documenting. The description restates those same five values without adding selection guidance (e.g. what to do when a question spans multiple topics, or whether a combined query is possible), so it neither compensates for the coverage gap nor misleads.
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 exact resource (store policy documents) and enumerates the five topics, and combined with the title 'Read the store policies' an agent can immediately tell this retrieves policy text. It is clearly distinct from the siblings get_product, search_products and track_order, though the description itself is a noun fragment that relies on the title for its verb.
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: the topic list suggests calling it when a shopper asks about shipping, returns, privacy, terms or contact. There is no explicit statement of when to prefer it over alternatives or of any preconditions, but for a single-purpose policy reader with no real competitors among the siblings, the implied routing is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The status of one order (preparing, shipped, delivered), its items, delivery estimate and tracking. Needs the 8-character order reference from the confirmation email and the email used at checkout.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The email used at checkout | ||
| reference | Yes | Order reference, 8 characters, e.g. 1A2B3C4D |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already certify readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds value by enumerating the returned data (status, items, estimate, tracking) and the input sourcing, which goes beyond the annotations. It does not describe failure cases (e.g., unknown reference), keeping it below 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 compact sentences with no filler, and the useful output description is front-loaded before the input requirements. 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?
For a simple two-parameter lookup with 100% schema coverage and annotations covering the safety profile, the description is nearly complete: it covers what is returned and how to source inputs. Error handling for invalid references is the only notable omission.
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 both parameters are fully documented in the schema (8-char reference example, email used at checkout). The description largely restates these, adding only the source of the reference ('confirmation email'), so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states clearly what the tool returns for a single order (status states, items, delivery estimate, tracking), which makes its purpose obvious and distinct from siblings like get_product or search_products. It is not phrased as a clean verb+resource and doesn't explicitly name the siblings, keeping it just 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?
It tells the agent exactly what it needs to call the tool and where those inputs come from ('8-character order reference from the confirmation email and the email used at checkout'). This is strong prerequisite context, though there are no explicit when-not or alternative-tool conditions.
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_productsearch_productsstore_policiestrack_orderSearch fashion across 1,000+ retailers; compare prices, sizes and stock by country.
Fashion and gift concierge: size guide, AI try-on previews, dress search, gift baskets, scarves.
UCP agentic-commerce proxy for Estroni: merino & low-tox women's activewear catalogue.
Virtual try-on and on-model AI fashion photography: catalog search, try-on grids, HD delivery.
Add one secure layer between your agents and this server.
