market

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

Annotations include readOnlyHint=true and openWorldHint=false, indicating behavior. Description adds that country/shipping signals are best-effort and separate from product availability, which is valuable context for result interpretation. No contradictions.

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 concise sentences that front-load purpose and provide actionable examples. Every sentence adds value without repetition or fluff.

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?

Description adequately covers purpose, usage, and behavioral caveats. Given schema covers parameters fully and no output schema exists, description could optionally elaborate on return structure, but current level is sufficient for competent use.

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

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

Schema coverage is 100% and descriptions in schema are detailed. Description does not add additional parameter details beyond the schema, but examples provided in description align with parameters. Baseline score of 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?

Description clearly states the tool finds fashion brands using natural language, with specific examples that distinguish it from sibling tools like discover_products (which likely finds products, not brands). It specifies the input type (natural language queries) and typical use cases.

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?

Description explicitly provides context for when to use (natural language queries for categories/style/country) and gives example queries that work well. It also warns that brand country/shipping signals are best-effort and separate from product availability, helping set expectations.

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 declare readOnlyHint=true and openWorldHint=false, indicating a safe read operation with limited scope. The description adds valuable context: it explains the AI-powered semantic search mechanism, multi-currency handling with automatic conversion to USD, and that results show original store currency. This goes beyond annotations, though it doesn't detail rate limits or auth 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?

The description is front-loaded with the core purpose, followed by key features and examples. Every sentence adds value: it explains the search method, provides usage examples, lists supported filters, and details currency handling. No wasted words, and it's structured for quick comprehension.

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?

Given the tool's complexity (20 parameters, no output schema), the description does well by covering the AI search approach, multi-currency logic, and result formatting. It compensates for the lack of output schema by stating results show original store currency. However, it could mention pagination or result limits more explicitly, though the schema covers limit parameter.

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 schema fully documents all 20 parameters. The description adds some context by mentioning fashion-specific filters and multi-currency support, which aligns with parameters like colors, materials, and currency. However, it doesn't provide significant additional semantics beyond what the schema already specifies.

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 states the tool's purpose: 'Find fashion products using natural language' with AI-powered semantic search. It specifies the resource (fashion products) and verb (find), and distinguishes from siblings by emphasizing natural language queries versus more structured alternatives like find_similar or get_product.

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 provides explicit guidance: 'Best for descriptive queries' with examples, and mentions fashion-specific filters. It implicitly contrasts with siblings by highlighting natural language search, suggesting when to use this tool over more structured or specific sibling tools like get_filters or list_stores.

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 provide readOnlyHint: true and openWorldHint: false, indicating safe read-only, deterministic results. The description adds value by explaining the underlying mechanism (brand-profile vectors from product indexing) and the fixed return limit of 10, which is not in 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 concise sentences, front-loaded with the core purpose, no wasted words. Every sentence adds essential 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?

Given the low complexity (2 parameters, no output schema, simple return constraint), the description covers the key aspects: input type, similarity method, and result count. No additional return value explanation needed since there is no output schema.

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

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

Schema description coverage is 50%, with the 'brand' parameter described well ('Brand name or brandKey, e.g. "Rick Owens" or "rick owens".') and 'limit' having clear range via schema. The description reinforces that the tool returns up to 10 brands, aligning with the limit default and max. However, the description does not explain the limit parameter's role.

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 states 'find similar brands' using 'brand-profile vectors', specifying the input (brand name or brandKey) and a concrete output (up to 10 brands). It distinguishes from siblings like 'find_similar' and 'discover_brands' by mentioning the specific vector-based similarity mechanism.

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 for finding similar brands given a brand reference, but does not explicitly state when to use this tool versus alternatives like 'find_similar' or 'discover_brands'. No when-not-to-use or exclusion criteria are provided.

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 indicate readOnlyHint=true, confirming non-destructive read. The description adds behavioral details: returns compact product cards, includes page/hasNextPage, limited to 10 results per page (max 3 pages), and explains currency fallback logic. No contradiction with 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?

The description is concise (3 sentences) and front-loads the purpose. However, it packs multiple pieces of information into a single paragraph without clear separation. It is still efficient and readable.

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 tool with 4 parameters, no output schema, but clear annotations, the description provides sufficient context: return format (compact cards), pagination details (page/hasNextPage, max 3 pages, up to 10 per page), and a pointer to get_product for full details. It covers all essential behavioral aspects.

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 covers 100% of parameters, so baseline is 3. The description adds value by explaining the currency parameter's behavior (ISO code, default USD, fallback to FX conversion), which goes beyond the schema description. Other parameters are adequately described in 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?

The description clearly states the tool's action: 'Given a product ID, find similar products across the entire catalog.' It specifies the verb 'find' and the resource 'similar products', and distinguishes from sibling tool 'get_product' by noting it returns compact cards versus full variant detail.

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 explicitly states when to use this tool ('for 'more like this' recommendations or finding alternatives') and when not to ('call get_product for SKU-level variants...'), providing clear guidance on alternatives.

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 indicate readOnlyHint=true and openWorldHint=false, which the description doesn't contradict. The description adds valuable behavioral context beyond annotations: it explains performance implications ('faster and less data'), scoping behavior for 'category' and 'brand_search', and clarifies that 'brand_search' uses prefix matching. However, it doesn't mention pagination details for 'brand_page' or potential rate limits.

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 efficiently structured: the first sentence states the core purpose, followed by three concise sentences explaining key parameter usage. Each sentence adds clear value without redundancy, and the information is front-loaded with the most important details 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?

Given the tool's moderate complexity (4 parameters, no output schema), the description is mostly complete. It covers the tool's purpose, key usage scenarios, and behavioral nuances. However, it doesn't describe the return format or structure of filter values, which would be helpful since there's no output schema. The annotations provide safety information but not output details.

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 schema already documents all parameters thoroughly. The description adds some semantic context: it explains that 'fields' reduces data volume, 'category' scopes subcategories, and 'brand_search' uses prefix matching. This provides marginal value beyond the schema but doesn't significantly enhance parameter understanding.

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 states the tool's purpose with a specific verb ('Returns') and resource ('available filter values in the catalog'), and distinguishes it from siblings by focusing on filter metadata rather than product data or store information. It explicitly lists the dimensions returned, making the scope 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?

The description provides explicit guidance on when to use the tool: 'By default returns all dimensions' and 'Use "fields" to request only specific dimensions — faster and less data.' It also explains when to use specific parameters like 'category' and 'brand_search' for scoping or searching, offering clear alternatives within the tool itself.

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 indicate read-only and closed-world behavior. The description adds value by specifying what details are included (variants, images, AI classification, purchase link), but does not disclose additional traits like rate limits, authentication needs, or error handling.

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 a single, efficient sentence that front-loads the core purpose and lists included details without unnecessary words, making it easy to parse.

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 tool with one well-documented parameter and no output schema, the description is mostly complete. It could improve by clarifying the return format or error cases, but it adequately covers the tool's purpose and scope given the annotations.

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 parameter 'product_id' is fully documented in the schema. The description adds no additional parameter details beyond implying it comes from a previous search, which aligns with the schema's description.

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 states the verb ('Get') and resource ('full details of a specific product by ID'), and distinguishes from siblings by specifying it retrieves detailed information for a single product rather than searching or listing (e.g., 'discover_products' for broader searches).

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 when detailed information on a specific product is needed, and the parameter description suggests it follows a search result. However, it does not explicitly state when NOT to use it or name alternatives like 'discover_products' for initial searches.

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