Forage Shopping

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

With no annotations provided, the description carries full burden. It explains the workflow context (polling after browser payment escalation) but omits safety traits (read-only vs. mutation), error behaviors, or rate limits. The word 'Check' implies read-only but this is not explicitly stated.

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 tightly structured sentences with zero waste. Front-loaded with the core function ('Check the status'), followed immediately by specific usage context. 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?

Given the simple single-parameter structure and existence of an output schema, the description adequately covers the workflow context (escalation step handling). Sufficient for this complexity level, though could optionally mention error cases or prerequisite steps.

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%, establishing baseline 3. The description adds value by clarifying the checkout_id can represent either a 'checkout session' or an 'order', expanding scope beyond what the schema title 'Checkout Id' suggests.

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 the specific action ('Check the status') and resource ('checkout session or order'), clearly distinguishing this from siblings like start_checkout or complete_purchase by focusing on status retrieval rather than initiation or finalization.

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 temporal guidance ('Use this after the user has completed an escalation step') and use cases ('to see if the checkout can now proceed' or 'check on a completed order'). Lacks explicit named alternatives, though the 'after' clause implicitly distinguishes it from start_checkout.

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?

No annotations are provided, so the description must carry full behavioral disclosure. While it mentions showing 'price differences', it fails to disclose critical traits like data freshness (real-time vs cached), shipping inclusion, merchant coverage scope, or that it is read-only (unlike its purchase-related siblings).

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 brief with two short sentences, but exhibits slight redundancy as both sentences communicate the same core concept (comparing prices across merchants) using synonymous phrasing ('multiple merchants' vs 'different retailers').

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 presence of an output schema (handling return documentation) and simple 2-parameter input, the description is minimally sufficient. However, given the tool sits among purchase-mutation siblings, clarifying it is a pre-purchase research step would improve completeness.

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 100% schema description coverage, the schema fully documents both parameters (product_name with example, session_id with linking purpose). The description mentions 'specific product' which aligns with the required parameter but adds no semantic guidance beyond the schema, warranting the baseline score.

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 compares prices for a specific product across merchants/retailers using specific verbs. However, it lacks explicit differentiation from the sibling tool 'find_deals', which could cause confusion about which price-related tool to use.

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 explains what the tool does but provides no guidance on when to use it versus alternatives like 'find_deals' or 'search_products', nor does it mention prerequisites such as whether to use this before or after finding a product.

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 no annotations provided, the description carries full burden and effectively discloses side effects: it records telemetry conversions, ends the attribution session, and returns confirmation details. Could be improved by noting irreversibility or idempotency concerns for a purchase completion 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?

Four well-structured sentences: purpose, usage constraint, behavioral side effects, and return value. Every sentence earns its place with no redundancy or 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?

Given that an output schema exists (per context signals), the description adequately covers invocation prerequisites and side effects. It appropriately summarizes the return value without duplicating schema 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 fully documents both parameters (checkout_id and session_id). The description mentions 'checkout status' and 'attribution session' which loosely map to parameters, but does not add syntax guidance or format details beyond what the schema provides.

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 with specific verbs ('Complete a checkout and place the order'), identifies the resource (checkout/order), and distinguishes from siblings like start_checkout or update_checkout_info by emphasizing the finalization action.

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 precondition 'Only call this when the checkout status is 'ready_for_complete'', which tells the agent exactly when to invoke it. However, it does not explicitly name alternative tools (e.g., update_checkout_info) to use when the status is not ready.

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?

No annotations provided, so description carries full burden. Provides some behavioral context ('current' implies temporal relevance; 'discounted/best-value' implies filtering logic), but lacks details on ranking algorithm, result limits, geographic scope, or failure modes when no deals exist.

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 primary action. No redundancy or tautology. Line break between sentences doesn't impede readability.

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 100% schema coverage and existence of output schema (mentioned in context signals), description adequately covers core functionality. However, lacks behavioral depth expected for a deal-finding tool with no annotations (e.g., how 'best' is calculated).

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%, establishing baseline 3. Description mentions 'product category' reinforcing the required parameter, but adds no syntax guidance (e.g., currency formats for 'budget') or semantic explanation of 'session_id' beyond what schema already documents.

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?

Clear verb ('Find') and resource ('deals in a product category'), with helpful scoping ('discounted, on-sale, or best-value'). Distinguishes from general 'search_products' sibling by emphasizing deal-specific filtering, though differentiation from 'compare_prices' could be sharper.

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?

No explicit guidance on when to use this tool versus siblings like 'search_products' (general catalog) or 'compare_prices' (price comparison). No mention of prerequisites or exclusion 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?

With no annotations provided, the description carries the full burden. It successfully discloses the external data sources (Shopify's global catalogue and Channel3's affiliate network) and return format (structured listings with prices/merchants/checkout links). However, it omits operational details like rate limits, session persistence behavior, or error conditions that would help an agent understand the tool's constraints.

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 appropriately structured with the core purpose front-loaded in the first sentence. Subsequent sentences add specific value about data sources and return structure. There is minor redundancy mentioning 'checkout links' twice, but overall it is tight and information-dense without being 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?

Given the presence of an output schema (which alleviates the need to describe return values in detail) and full schema coverage, the description provides adequate context by specifying the search scope (50M+ products) and result composition. It could improve by mentioning pagination behavior or empty result handling.

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 has 100% description coverage, establishing a baseline of 3. The description adds no parameter-specific details beyond what the schema already provides (e.g., it doesn't elaborate on the session_id linking behavior or query syntax), but this is acceptable given the comprehensive schema documentation.

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 core action (search for products), scope (across merchants), and output type (comparison results). It effectively distinguishes from single-merchant searches by mentioning 'across merchants' and hints at comparison functionality, though it doesn't explicitly differentiate from siblings like 'find_deals' or 'compare_prices'.

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 no guidance on when to use this tool versus alternatives like 'find_deals' (which suggests discount-specific searching) or 'compare_prices' (which may require specific product identifiers). There are no 'when-not-to-use' warnings or prerequisites mentioned.

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?

No annotations provided, so description carries full disclosure burden. Effectively explains multi-step behavior: merchant capability discovery, session creation, content attribution attachment, and return of status/missing fields. Could clarify if session creation is idempotent or expiration behavior.

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 well-structured sentences with zero waste: sentence 1 defines action, sentence 2 explains mechanism/attribution, sentence 3 specifies return values. Front-loaded with core purpose. No redundancy with schema or title.

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?

Appropriately complete given 100% schema coverage and presence of output schema (justifying brief return value summary). Covers UCP discovery behavior and attribution logic. Missing explicit workflow sequence with named siblings (complete_purchase, update_checkout_info) that would make it fully complete.

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%, establishing baseline 3. Description reinforces schema concepts (e.g., 'content attribution data' aligns with session_id's 'link checkout with earlier search telemetry'), but does not add significant semantic meaning beyond what schema property descriptions already provide.

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?

Specific verb ('Start') + specific resource ('UCP checkout session') clearly stated. Description distinguishes from siblings like 'complete_purchase' and 'update_checkout_info' by emphasizing session creation and returning 'information the merchant still needs', implicitly positioning this as the workflow entry point.

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 clear contextual signals: mentions 'current session's search and comparison activity' implying use after search/comparison tools, and 'information the merchant still needs' implies subsequent steps required. However, does not explicitly name sibling alternatives (e.g., 'use complete_purchase to finalize').

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?

Since annotations are absent, description carries full burden. It adds valuable behavioral context about response handling ('requires_escalation' status and continue_url sharing) that isn't in the schema. However, it lacks disclosure about mutation safety, reversibility, or side effects of updating checkout 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?

Three well-structured sentences: purpose statement first, workflow guidance second, and response handling third. Every sentence earns its place with zero verbosity or redundancy. Information is appropriately front-loaded.

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 has an output schema (not shown but indicated), the description appropriately focuses on workflow integration and special response handling ('requires_escalation'). It adequately covers the 5-parameter checkout update scenario, though could benefit from mentioning transaction safety given the mutation nature.

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 baseline score is 3. Description mentions the field groupings (email, name, shipping address, discount codes) and adds mild semantic context by noting these are 'information the merchant requested', but does not elaborate beyond what the schema already documents.

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 uses specific verb 'Update' with resource 'checkout session' and scope 'buyer information'. It clearly distinguishes from sibling 'start_checkout' (initiation) and 'complete_purchase' (finalization) by positioning this as the middle step for providing missing buyer details.

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 sequencing 'Call this after start_checkout' and trigger condition 'when the merchant indicates what information is still needed'. This clearly establishes when to use the tool in the workflow, though it lacks explicit 'when not to use' guidance or alternative tool recommendations.

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