SearchShop AI

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds valuable behavioral details by stating it returns 'structured comparison with shared attributes, differences, tradeoffs, and a decision hint', which goes beyond the schema and 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?

Three tightly written sentences: purpose, usage guidance, and output summary. Every sentence adds value with no filler or redundancy.

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 simple input (one array parameter), strong annotations, and absence of an output schema, the description adequately covers what the tool does, when to use it, what it returns, and how it differs from siblings. No meaningful gaps.

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

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

Schema description coverage is 100% — the 'products' parameter includes a clear description with format and example. The tool description doesn't add extra parameter-level semantics beyond what's in the schema, 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 clearly states the tool's function with a specific verb ('Compare') and resource ('two or more products side by side'). It also distinguishes from sibling tools by explicitly contrasting with get_product for single lookups, making its purpose 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?

Provides explicit usage conditions ('when the user asks to compare, says 'X vs Y', or wants to decide between options') and a clear exclusion with an alternative ('Do not use for single product lookup — use get_product instead'). This is textbook 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?

Annotations already signal readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds useful behavioral context: it resolves product URLs automatically without catalog import, supports discount codes/cart notes/selling plans, and returns a clickable Shopify checkout link. This goes beyond the annotation flags and clarifies the tool's side effects.

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 well-structured and front-loaded with the primary purpose. Each sentence adds value—usage guidance, URL resolution behavior, feature list, and return value—without redundancy. It is appropriately sized for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 5 optional parameters and no output schema, the description is complete. It covers what the tool does, how inputs are provided, when to use it, and what the user receives. Edge cases like max quantities are handled by the schema. No missing critical information for selection or invocation.

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

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

Schema covers 100% of parameter descriptions, so baseline is 3. The description adds semantics by grouping items and product_urls, explaining that URLs are auto-resolved, and highlighting the supported features (discount codes, cart notes, selling plans). This clarifies how to use the parameters beyond the schema alone.

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 opens with a specific verb and resource: 'Create a checkout URL for one or more products.' It clearly distinguishes this tool from siblings by referencing the checkout flow and pointing to search_products/skincare_recommend as preliminary steps. The example URL adds concrete clarity.

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?

Explicit guidance is provided: 'Do not use unless the user wants to buy — use search_products or skincare_recommend first.' This tells the agent when to use and when not to use, and names the alternative tools. It also explains the automatic URL-to-variant resolution, which informs correct usage.

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 destructiveHint=false, so the safety profile is covered. The description adds that the tool 'Returns a widget card with the product details, image, price, and checkout button,' which informs the agent of the output structure beyond the annotations. No additional side-effect warnings are needed for a read-only lookup.

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 three sentences, each with a distinct purpose: primary action, usage context, and exclusion/return. It is concise without redundancy and front-loads the most critical 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?

For a simple read-only product lookup with two parameters, the description covers purpose, usage boundaries, and return format. No output schema is needed for a widget card, and the tool's behavior is fully described with the context and exclusions.

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%, with descriptions for both sku and title, including an example SKU and fuzzy-match note. The description's mention of 'by SKU or title' adds no new information beyond the schema, so a 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?

The description opens with 'Get full details for a specific product by SKU or title,' providing a clear verb, resource, and lookup method. It explicitly differentiates from browsing/recommendation tools by directing to search_products or skincare_recommend, removing ambiguity among 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?

It states 'Use when the user asks about a specific product by name (e.g. ...)' and provides explicit exclusions: 'Do not use for browsing or recommendations — use search_products or skincare_recommend.' This gives the agent clear decision criteria.

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 destructiveHint=false. The description adds that it returns the summary and URL, which is useful behavioral context. It does not contradict the annotations and provides some extra value beyond the structured data.

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, focused sentence that front-loads the action and resource. Every word earns its place; no redundant filler.

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 one-parameter, read-only tool with no output schema, the description covers the essential info: what the tool does, what it returns, and where the parameter comes from. It is 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 100% for the single parameter 'slug', so the baseline is 3. The description adds provenance by noting the slug comes from search_research_notes, which goes beyond the schema's example and clarifies the parameter's source.

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 action ('Get'), the resource ('Research Note'), and the specific output ('summary and URL'). It distinguishes itself from sibling tools like search_research_notes by focusing on a single note identified by slug, which is precise and 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?

It provides clear contextual guidance by noting the slug is 'returned by search_research_notes', implying a two-step workflow: search first, then retrieve details. This indicates when to use this tool relative to its sibling. It lacks explicit exclusions, but the workflow hint is valuable.

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?

The description enriches beyond annotations by detailing the return payload: 'scored products with checkout URLs, safety assessment, and authority state (SHOULD/CAN/SHOULDNT/ESCALATE/CANT).' This provides concrete information about the tool's behavior and output, going well beyond the simple readOnlyHint and destructiveHint 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 two sentences that front-load the core purpose and usage, followed by return details. Each sentence adds essential information without fluff or repetition. This is a model of concise, well-structured documentation.

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 compensates by explaining the return values and authority states, which is critical for the agent. It also covers usage guidance. However, it does not disambiguate from the sibling tool skincare_recommend, which could lead to incorrect selection in edge cases.

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% with descriptive parameter definitions. The description does not add much parameter-specific semantics beyond what is already in the schema, such as 'query' being a natural language request. Baseline 3 is appropriate since the schema carries the burden.

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: 'Get a personalized product recommendation with domain-expert scoring, safety notes, and transaction authority.' It specifies the resource and action. While it distinguishes itself from siblings like search_products by focusing on recommendations, it does not explicitly differentiate from the similarly named skincare_recommend, leaving some ambiguity.

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 usage context: 'Use when the user wants advice, has a concern, or asks what to buy.' This gives clear guidance on when to invoke the tool, but it does not mention when not to use it or suggest alternatives among the sibling tools.

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 destructiveHint=false, so safety is covered. The description adds valuable behavioral context: it returns all matching products with prices, images, and checkout, does not score or filter, and shows everything so the user can decide. This goes beyond what annotations alone convey.

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 longer than ideal, but every sentence carries weight. It front-loads the primary purpose, then addresses when-not-to-use, return contents, and key behavioral distinctions. No fluff, but readability could be tightened slightly.

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 4 parameters and no output schema, the description covers return values (prices, images, checkout), comparison to the recommendation sibling, and parameter usage guardrails. It does not mention pagination or sorting, but given max_results is documented, this is sufficient for a search/browse 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 coverage is 100%, so all parameters are documented. The description adds practical nuance: query examples, a strong caveat on the category parameter ('Do not guess categories'), and clear guidance on max_results behavior ('Only set this if the user specifies a count'). This improves usability beyond raw 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 browses and searches the product catalog, with specific usage scenarios ('see what's available, look up specific products, browse by category, compare options'). It explicitly distinguishes itself from skincare_recommend, making the purpose unambiguous and differentiating it from 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 provides explicit when-to-use guidance and an explicit exclusion: 'Do not use when the user needs personalized recommendations based on skin concerns — use skincare_recommend instead.' This leaves no ambiguity about which sibling to invoke.

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 destructiveHint=false, so the safety profile is covered. The description adds behavioral context beyond that by specifying the content scope (data studies, playbooks, field notes on agentic commerce) and the return fields (titles, summaries, URLs). While it doesn't discuss pagination or limits, for a simple read-only search this is reasonably transparent.

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 exactly two sentences and front-loaded with the action ('Search...'). It packs essential information—resource, content type, return values, and usage trigger—without any filler or redundant phrasing. Every clause 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 tool with a single required parameter, read-only annotations, and no output schema, the description is sufficiently complete. It tells the agent what the tool does, what it returns, what kind of topics are covered, and when to use it. The lack of pagination or result-limit details is not a significant gap for a straightforward search 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?

The schema covers the single 'query' parameter with a description and examples, achieving 100% schema coverage. The tool description complements this by enriching the semantic context—e.g., listing specific topics like 'AI attribution', 'MCP', 'AI catalog accuracy', and 'ChatGPT ads'—which helps the agent formulate better queries. This is more than just a repetition of schema field names.

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 opens with a specific verb ('Search') and a clearly identified resource ('SearchShopAI's Research Notes blog'), and further defines scope with content types and example topics. It also states the return payload (titles, summaries, URLs), which gives a concrete sense of what the tool does. This strongly distinguishes it from sibling tools, especially get_research_note, by signaling search over retrieval.

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?

An explicit usage context is provided: 'Use when asked what SearchShopAI has written or published about a topic.' This gives the agent a clear trigger scenario. However, it does not explicitly mention when not to use it or point to an alternative tool (e.g., get_research_note for fetching a specific note), so it stops short of a full exclusion/alternative comparison.

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?

Beyond annotations (readOnlyHint=true, destructiveHint=false), the description explains that the tool interprets the request and routes to appropriate capabilities, which is a meaningful behavioral trait not captured in annotations. It also specifies that it preserves qualifiers like concerns, skin type, and medical context, adding context about how it processes input.

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 'Start here for any shopping request' and uses concise, purposeful sentences. It provides necessary instructions and alternatives without redundancy, earning its length with concrete guidance and examples.

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 complex routing tool with no output schema, the description covers input expectations, routing capabilities, and guidance for follow-ups. It lacks details on return values or edge cases, but these are less critical for an entry-point tool. The overall guidance is sufficient for an agent 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 description coverage is 100%, with each parameter already described as a 'secondary hint only' and the `request` field fully documented. The description reinforces the importance of passing the complete request, but adds no substantial new information beyond what the schema provides. 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 states the tool is an entry point for any shopping request, using a specific verb ('Start here') and explicitly distinguishes from sibling tools by listing the granular tools (search_products, get_product, compare_products, create_checkout) as precise follow-ups. It defines its scope as understanding and routing conversational requests.

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 explicit guidance: 'Prefer this tool whenever the request is conversational or carries any nuance' and states that granular tools remain available as follow-ups. This directly tells the agent when to use this tool versus 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?

The description discloses return behavior ('Returns a widget with the cart items and a working checkout link') and explains the two operational modes. Annotations already cover readOnly=false and destructiveHint=false, so the description adds value by specifying the output and the auto-recommend behavior of query mode. It does not discuss rate limits or side effects, but these are not hinted at by 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 three sentences with clear structure: purpose, mode list, exclusion, and return output. No redundant phrases or filler. It is front-loaded with the primary purpose and efficiently conveys all necessary pointers.

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 3 parameters, no required fields, and no output schema, the description covers the essential context: what it does, when to use, modes, and output. Minor gaps include not specifying behavior when both query and products are provided (though schema handles that) and absence of error-case handling, but these are partially covered by the schema and not critical for selection.

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?

Input schema has 100% parameter coverage, so the baseline is 3. The description adds meaningful context by explaining the conditional relationship: products array is for 'specific product names' while query mode 'auto-recommend[s] and cart[s]', and that query is 'only used if products array is not provided' (though that detail is also in the schema). This helps the agent choose between mutually exclusive parameters.

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 explicitly states the tool's purpose with a specific verb and resource: 'Create a buyable shopping cart with a real checkout URL.' It also distinguishes itself from siblings like search_products and skincare_recommend by clarifying it's for cart creation, not browsing or recommending.

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 when-to-use and when-not-to-use guidance: 'Do not use for browsing or recommendations — use search_products or skincare_recommend first.' It also details two distinct modes ('Pass products array' vs 'Pass query string') and conditions for each, aiding correct invocation.

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 destructiveHint=false, and the description adds behavioral depth: it works identically to 'recommend', includes ingredient-aware scoring, safety notes, routine building, and returns scored products with checkout URLs. The deprecation warning is also valuable context, though further detail on response structure or edge cases is missing.

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 critical deprecation notice, then succinctly covers purpose, usage guidance, and return value. Every sentence contributes to the agent's decision-making, with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only recommendation tool with fully documented parameters and a clear sibling alternative, the description covers purpose, when to use, what to expect, and the deprecation path. No output schema is needed since the return type is summarized. All necessary context for correct invocation is present.

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 input schema provides 100% coverage with detailed descriptions for brand, query, and strategy, so the description adds no additional parameter-level meaning. The mention of 'strategy override' is redundant with the schema. 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 clearly states a specific function: obtaining a personalized skincare recommendation with ingredient-aware scoring, safety notes, and routine building. It explicitly distinguishes from search_products and even names the successor tool 'recommend', ensuring the agent understands the tool's unique role despite its deprecation.

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

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

Explicitly states when to use ('when the user wants advice, has a skin concern, or asks what to buy') and when not to ('Do not use for browsing or listing products — use search_products instead'). It also provides an alternative tool due to deprecation, fully meeting the when/when-not/alternatives criterion.

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 mark the tool as not read-only and not destructive, and the description adds that it helps improve the engine, implying a write/feedback action. However, it does not disclose side effects, such as whether reports are stored or if there are limits, leaving moderate behavioral transparency.

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 that front-load the primary action and then provide usage conditions and rationale. No filler words; every sentence adds value.

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 feedback tool with full schema coverage and clear trigger conditions, the description is sufficient for correct invocation. It lacks an explicit mention of the expected response, but no output schema exists and the function is straightforward, so a small gap remains.

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 all five parameters are documented (tool_name, issue_type, user_query, description, expected_products). The description does not add extra parameter-level detail, but the schema already carries the burden, 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 uses a specific verb ('Report') and clearly identifies the resource (tool result issues), distinguishing it from sibling recommendation/cart tools. It explains the tool's role in flagging unhelpful, incomplete, or wrong results, which is unique among 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?

Explicitly states when to call it ('whenever you override a recommendation, skip a cart result, or notice the engine output doesn't match...') and when not to ('Do not use proactively — only when you observe an actual issue'). This provides clear decision rules without needing separate alternative tools.

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