SI Stores

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real context the annotations don't: it returns 3-6 curated picks with a one-line reason and links to live searches across named external stores, prices are estimates, and transactions complete off-tool. That is meaningful disclosure for an open-world read tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences: capability first, then return shape, then the price/checkout caveat. Nothing is redundant or padded.

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 description carries the return-value burden and does it well (count, one-line rationale, store links). It falls short only on the undocumented input parameters and on not differentiating from sibling search tools.

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 only 43%, and the description recapitulates the length enum plus occasion, size and budget without adding format or syntax beyond the schema. It leaves avoid, color and count unexplained in both places, so it does not compensate for the coverage 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 with scope modifiers: 'Find mini, midi or maxi dresses for an occasion, size and budget.' The length-and-style specificity separates it from the generic shop_search sibling, though no sibling is named explicitly.

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?

Implied usage is clear (dress shopping filtered by length/occasion/budget), and it hints at the boundary of the flow by noting checkout happens on the store's site. However it never says when to pick this over shop_search or size_guide, so the agent must infer the routing.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds real value by disclosing the return shape (ranked styles, a reason each) and that fulfillment happens via partner retailer links rather than in-tool checkout. It doesn't mention limits on result count or any failure modes.

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, input contract first then return contract, with no filler. The parenthetical efficiently enumerates the content the query should contain, and every clause contributes 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?

With no output schema, the description usefully summarizes what comes back. However, it omits any guidance on count (default 3, max 6) or the avoid filter, both of which an agent needs to invoke the tool accurately, leaving meaningful gaps for a 4-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning, and it only partially does. It explains the query string well (who/occasion/interests/diet/budget in one sentence) and gestures at budget, but it never mentions the avoid or count parameters, and folding 'budget' into the query text while a separate budget parameter exists is potentially confusing.

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 action (match a described recipient to gift basket styles) and a concrete output (styles with a reason each plus buy links), so the resource is unambiguous. It doesn't explicitly distinguish itself from the similarly-named scarf_concierge sibling, but gift baskets vs. clothing accessories is clear from the text.

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 how to formulate the invocation: one sentence covering who, occasion, loves, dietary needs, and budget. There are no explicit exclusions or named alternatives (e.g., shop_search or scarf_concierge), 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.

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

Adds substantial context beyond the readOnlyHint=false / openWorldHint=true annotations: the labeled output ('AI preview, not a real photo, not exact fit'), the consent requirement, reuse of photo_tryon's content policy and rate limits, unsupported categories, and the no-storage guarantee. These are the operational details an agent needs before invoking a generative tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action, then chains the return format, consent requirement, policy pointer, and exclusions in compact clauses. Dense but every sentence carries a distinct operational fact; nothing is redundant with the title or schema.

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-image generative tool with no output schema, the description covers the essential ground: what is produced (labeled AI preview), the consent gate, content restrictions, and data handling. An agent has everything it needs to invoke it correctly.

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 67%, and the description compensates usefully by disambiguating the two inputs — the outfit comes from the second photo and the person from the first — which maps directly onto the outfit_* vs person_* parameter pairs. It also explains the consent flag's meaning, though it says nothing about the category enum or the URL-vs-base64 alternatives.

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 — placing an outfit from a second photo onto the person in the first photo — with clarifying examples of acceptable outfit sources (product shot, flat lay, worn). This clearly separates it from the single-photo sibling photo_tryon, so an agent can distinguish the two without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives explicit preconditions (consent=true for photo 1, adult consent), points to the shared content policy and daily limits of photo_tryon, and lists exclusions (lingerie, swimwear, see-through). It never states positively when to prefer this over photo_tryon, but the two-photo framing makes the selection condition reasonably clear.

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

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

Adds substantial information beyond the minimal annotations (readOnlyHint=false, openWorldHint=true): rate limits (3 per IP per day plus a site-wide budget), retention ('photos are not stored'), the AI-generated output labeling, and content-policy restrictions with a link. This is exactly the behavioral context an agent needs before invoking a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose, then layers requirements and limits in a compact paragraph with no filler sentences. It is dense but each clause (consent, policies, limits, retention) earns its 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 7-parameter tool with no output schema, the description covers return values (labeled preview image plus shop-similar link), consent, and operational limits. The remaining gap is the unexplained who/mode/site enums, which the schema also leaves bare.

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 only 57%, and the description does little to compensate. The 'edit vs generate' phrasing loosely implies mode=edit, but the opaque enums who (one/left/middle/right/all), mode (auto/edit/generate), and site (shopfashion/scarves) are never explained, leaving nearly half the parameters ambiguous.

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 ('Preview a described clothing or accessory style on a photo'), and clarifies it can also edit an existing garment, which distinguishes it from a pure generation tool. It does not explicitly differentiate itself from the sibling outfit_tryon, which an agent would need to reason about.

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 usage context with concrete examples ('make the skirt mini', 'navy instead of red') and states the consent precondition. It does not name the sibling outfit_tryon or explain when to prefer this tool over it, so routing still requires inference.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and the fact that it reaches outside the local catalog are covered. The description adds that results include a reason per idea and links to live searches, which is mild added context but mostly restates the openWorld behavior an agent already knows from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, with the required input format front-loaded before the return description. Every clause 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?

There is no output schema, and the second sentence does describe what comes back (style ideas, one reason each, links to live searches), which is the main gap-closer. The remaining shortfall is the undocumented 'avoid' and 'count' parameters, which an agent must infer from the schema names alone.

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 parameter meaning; it partially does by enumerating the aspects to capture (who, colors, fabric, climate, budget, monogram) and mapping budget to the budget field. It leaves 'avoid' and 'count' entirely unexplained and gives no hint about the 300-character query limit.

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 action (describe the recipient) and a specific output (scarf style ideas with reasons and live scarf search links), so an agent knows this is a scarf-specific idea generator rather than a search or try-on tool. It is distinguishable from siblings like shop_search or gift_basket_concierge, though it never explicitly names or contrasts them.

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 implies usage by prescribing the input form ('Describe the recipient in one sentence'), which signals a gift/recipient-recommendation scenario. However, it gives no explicit when-to-use versus alternatives (e.g., gift_basket_concierge, shop_search) and no exclusions or prerequisites.

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

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

With readOnlyHint and openWorldHint already covering the safety and world-scope profile, the description adds real value: the return cardinality (3-6 picks), the content of each pick (a reason plus links to live searches at multiple stores), and the non-purchasing nature of the call. It omits any rate-limit, latency, or link-freshness caveats, keeping 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?

Three sentences with the actionable instruction front-loaded, then output shape, then the safety clarification. The parenthetical packs five concepts into one clause, which is dense but still readable; nothing is padded.

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?

There is no output schema, so the description correctly compensates by describing the return shape and cardinality, and annotations cover the read-only/open-world profile. Combined with adequate parameter mapping, an agent has what it needs to invoke this correctly; only format specifics for budget/avoid are 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% across five parameters, so the description must carry the semantic load — and it largely does, mapping query to 'who, occasion', plus size, budget and 'things to avoid' (avoid). The count parameter is only hinted at via 'Returns 3-6 fashion picks', and no formats (currency for budget, list semantics for avoid) are given.

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 concrete verb+resource: it takes a one-sentence shopper description and returns 3-6 fashion picks with reasons and multi-store live-search links. This is a specific, distinctive action that separates it from narrow siblings like find_dress_by_length or scarf_concierge. It stops short of naming those siblings or explicitly contrasting itself with them.

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 how to phrase input ('Describe who you're shopping for in one sentence') and confirms the operation is non-transactional ('Nothing is bought here'), which gives implied usage context. However, it never states when to choose this over gift_basket_concierge, outfit_tryon, size_guide or the other concierge siblings, so routing remains inferential.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds real value beyond them: 'Computed server-side, nothing stored' discloses the privacy/no-persistence behavior when no data is retained. It stops short of describing pagination or error behavior, but for a stateless estimator this is solid context.

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 tight sentences with no filler; the core function is front-loaded and the estimate caveat follows immediately. Every sentence earns its 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 description helpfully explains the return values (US/UK/EU dress sizes and letter sizes) and the store-chart link. However, for an 11-parameter tool it leaves the measurement and gender parameters unexplained, so it is only partially complete for the tool's complexity.

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 the parameter burden. It names only height, weight, and body_type out of 11 params, omitting required 'gender' and the units/waist/bust/hip/chest/measurement-unit fields entirely, leaving most inputs 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 (Estimate) and resource (clothing sizes) and names the core inputs. It is clearly distinguishable from siblings like outfit_tryon, photo_tryon, and shop_search, none of which estimate sizes.

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 sets expectation with 'An estimate only; always check the store's own chart,' which implies this is a preliminary lookup, but it never states when to choose it over photo_tryon or any sibling. Usage is implied rather than explicit.

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