Custom Blinds Shop

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

With no annotations provided, the description carries full burden. It discloses permanent deletion, no effect on existing checkout/order, and irreversibility. Lacks details on authorization or data cleanup, but sufficiently covers key behavioral traits.

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, front-loaded with the purpose, no superfluous words. Each sentence adds value: action, usage context, behavioral notes.

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 delete tool with one parameter and no output schema, the description covers purpose, usage context, and key behaviors. Missing details on return value or error handling, but still adequate given the tool's simplicity.

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 description must compensate. It mentions 'by cart_id' but provides no additional meaning about the parameter format, constraints, or examples beyond the schema's type 'string.' Minimal added value.

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 'Permanently delete a cart by cart_id,' which is a specific verb and resource. It distinguishes from sibling tools like cancel_checkout (different resource) and update_cart (different 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?

Explicitly states when to use: 'when the customer abandons the session or wants to start over.' Also clarifies what it does NOT affect (checkout or paid order) and notes irreversibility with suggestion to create a new cart.

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?

Despite no annotations, the description fully discloses behavior: it aborts unpaid checkout, releases checkout_id, has no effect on confirmed orders, and suggests restart process. Comprehensive for a cancellation 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 sentences: first states action, second gives usage context, third provides limitation and restart guidance. Front-loaded and efficient with no superfluous 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?

Given the tool's simplicity (1 parameter, no output schema, no nested objects) and zero annotations, the description covers all necessary aspects: purpose, when to use, limitations, and next steps. Complete for a cancellation 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 only parameter checkout_id is not described in schema (0% coverage), but description implies it's the ID from create_checkout and that using it will 'release' it. This adds meaningful context beyond the type string.

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 clear verb 'Abort' and specific resource 'unpaid checkout'. It also distinguishes from sibling tools like 'cancel_cart' and 'complete_checkout' by focusing on checkouts before payment.

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 (customer changes mind after create_checkout but before payment) and when not to use (no effect on confirmed orders). Provides clear alternative: create new cart and checkout from scratch.

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?

Describes return values (in_stock, restock date, alternatives) and implies read-only operation. However, does not explicitly state lack of side effects or authentication requirements. With no annotations, some burden remains.

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, front-loaded with purpose, then return details, then usage guidance. No redundant words, efficiently conveys 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?

With no output schema, description adequately explains return values. Covers main behavioral aspects for a low-complexity tool. Could mention error conditions or authentication, but overall sufficient.

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 description must compensate. The description refers to 'product_id' and 'colour_name' implicitly but does not explain formats, constraints, or relation. Minimal added semantic value beyond parameter 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?

Clearly states the verb 'verify', resource 'colour availability', and the context 'before configure_product'. Distinct from siblings by emphasizing its role in preventing configure_product failures. Returns specific information including in_stock boolean, restock date, and alternative colours.

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: 'when a customer requests a named colour' or 'when you want to prevent a configure_product failure'. Also implies not to call for other purposes and names the related sibling tool configure_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?

Discloses checkout locking after call, asynchronous payment confirmation via webhook, and ability to abort with cancel_checkout. Without annotations, description carries full burden; it covers key behavioral traits well.

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 concise sentences, front-loaded with 'Phase 2 of 2'. No redundancy or 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?

Covers full workflow context: two-phase process, locking, async payment, alternative tool. No output schema, but description specifies return value. Complete for this complexity level.

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?

Description explains that payment_method overrides prior values and lists enum options. With 50% schema coverage, description adds meaning beyond schema, though both parameter descriptions could be enhanced.

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?

Clearly states it is phase 2 of 2 checkout finalization, mints payment links for Yoco/Ozow, returns payment_url. Distinguishes from siblings like create_checkout, cancel_checkout, and get_order.

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 describes when to use (after create_checkout), what it returns, and provides guidance to poll get_order for payment status and use cancel_checkout to abort. Names alternative for changing mind.

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, the description fully covers the behavioral traits: validation of colour existence and stock, pricing, and returning a configuration summary. It also advises a prerequisite step. However, it does not disclose error behavior or side effects like inventory locking, which is a minor gap.

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 concise sentences, each adding critical information: what the tool does, its validation and pricing, and how to use the output. No redundant or off-topic content.

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 absence of output schema, the description adequately covers return value (configuration summary for create_cart). It also references the prerequisite check_colour_stock. For a tool with 8 parameters, the main required ones are highlighted, and the workflow is clear.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the purpose of key parameters (e.g., mount type description matching enums), and provides workflow context (output used in create_cart). It does not describe optional parameters, but schema already does.

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 specifies that the tool locks in a full blind specification including product, dimensions, colour, and mount type, validates colour existence and stock, and prices the blind. It distinguishes itself from siblings like check_colour_stock and get_price by stating it returns a configuration summary for create_cart.

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 the tool (after having full specs) and suggests calling check_colour_stock first if uncertain about availability. While it doesn't explicitly list when not to use, the context of siblings and the explicit alternate tool guidance is strong.

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, the description must convey behavior. It discloses that the tool requires no auth, returns a cart_id with a 24-hour TTL, and optionally accepts initial items and customer details. It does not mention side effects, rate limits, or error scenarios, but covers core behavioral traits adequately.

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, front-loading the essential purpose and including only relevant details. It is structured as a single paragraph with clear progression, no redundancy, and every sentence contributes to understanding.

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 simplicity (2 optional parameters, no required fields, no output schema), the description covers the key aspects: purpose, output (cart_id), TTL, seeding options, and next steps. It lacks error handling details but is sufficient for a straightforward creation 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 input schema already has descriptions for both parameters (items and customer), and the description largely echoes that information. It adds 'pre-configured blind items' context and 'customer details', but provides minimal extra value beyond the schema, resulting in a 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's purpose: starting the open UCP purchase flow by creating a cart session and returning a cart_id. It specifies a 24-hour TTL, distinguishes from sibling tools like update_cart and cancel_cart, and provides next steps in the workflow.

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 that no authentication is needed and outlines the subsequent steps (update_cart, create_checkout, complete_checkout). It implies when to use this tool (first step in the flow) but does not explicitly state when not to use it or mention alternatives beyond the sequential workflow.

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. It discloses that no payment link is minted yet, implying non-destructive. However, it does not mention side effects on the cart (e.g., whether it is consumed or left intact), nor error conditions or idempotency.

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?

Description is concise with 4 sentences, front-loaded with core purpose, then explains phase context and alternatives. No unnecessary words, well-structured.

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 complexity (4 params, nested object, no output schema, no annotations), description covers the flow, prerequisites, and next steps. It lacks error handling details but is sufficient for typical usage.

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 50% but description adds value: clarifies that customer fields name, email, phone are required (reiterating schema), explains mutual exclusivity of items and cart_id, and notes default for payment_method. This goes beyond the 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?

Description clearly states the tool as Phase 1 of 2 in purchase flow, converting a cart or inline items plus customer into a checkout. It distinguishes from sibling tools like complete_checkout and update_checkout by specifying the role and next steps.

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 explains when to use this tool (first phase), what to do next (complete_checkout for payment link), and how to correct details before finalizing (update_checkout). Also mentions required customer fields.

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?

Despite no annotations, the description reveals key behaviors: authentication requirement, server-side price re-verification ignoring agent-supplied prices, and return of a payment_url (Yoco or Ozow). This adds value beyond the input schema, though it could mention side effects like stock reservation.

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 long, each serving a distinct purpose: purpose and alternative, usage condition, server-side behavior, return value. No superfluous words; it is front-loaded with 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?

The description covers authentication, pricing behavior, return type, and alternative flows. However, it lacks explicit details about the return value structure (e.g., whether payment_url is a string or object) and potential side effects, which would be valuable given 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 coverage is 100% with descriptions for all 6 parameters. The description does not add additional semantic context beyond what the schema provides, 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 clearly states it is a legacy auth-required tool for creating an order via a single-call path to a payment link, distinguishing it from the preferred multi-step UCP flow. It identifies the resource (order) and the specific verb (create), making the 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?

Explicitly advises against use unless the agent holds a Bearer token and prefers a single-call path, and recommends the alternative open UCP flow (create_cart → create_checkout → complete_checkout). This provides clear when-to-use and when-not-to-use 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?

Describes how AR tool works (camera, A4 reference) and modes, but does not disclose what the output is (URL) or any side effects. Without annotations, more behavioral clarity would help.

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?

Description is three sentences, front-loaded with purpose, each sentence adds unique value. 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?

Tool lacks output schema and description does not clarify what 'surfaces' means (returns a URL? launches UI?). Given simplicity, this is a noticeable gap.

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, but description adds context for mode meanings (measure uses camera, visualize uses uploaded photo) and product_id purpose, going beyond 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?

Clearly states the tool surfaces an AR measurement tool or product visualizer for window measurement or blind preview. Distinct from siblings which are shopping/cart/order tools.

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 when to use: when a customer wants to measure window or preview blind. No exclusions or alternatives provided, but context is clear and sufficient.

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. It clearly indicates a read operation ('Retrieve') and reveals return content and expiration behavior. However, it does not explicitly state idempotency or that no side effects occur, though this is implied by 'Retrieve'.

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, front-loaded with purpose and output, followed by usage guidance and a constraint. Every sentence adds value, and there is no redundant or filler content.

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 simplicity (one required parameter, no output schema), the description covers: what the tool returns, when to use it in the workflow (after update_cart, before create_checkout), and a key behavioral trait (expiration). This is sufficient for correct 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?

The only parameter, cart_id, is mentioned in the description ('by cart_id') and its purpose is clear (identifies the cart). However, no additional details like format or constraints are provided. With 0% schema coverage, the description adds basic context but lacks depth.

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 ('Retrieve') and resource ('live cart state') and explicitly lists what is returned (full item list, calculated totals, customer details). It distinguishes itself from siblings like update_cart and create_checkout by stating the workflow context.

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: 'Call after update_cart to confirm changes are correct before proceeding to create_checkout.' It also includes a temporal constraint (cart expires after 24 hours of inactivity), guiding agents on when not to rely on stale data.

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 the description carries the burden. It discloses return fields (status, item list, customer details, payment_url) and implies read-only behavior via 'poll'. A more explicit note on idempotency would raise the score, but current description is already informative.

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, no wasted words. Front-loaded with action and return values, followed by usage guidance. Highly efficient.

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 lookup tool with one parameter and no output schema, the description covers purpose, return fields, and use cases. It could mention error scenarios or expected response format, but it's reasonably complete for effective usage.

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 single parameter 'checkout_id' is mentioned in context, but the description does not add details beyond its type (string) or expected format. With 0% schema coverage, the description could compensate more, but the parameter's purpose is clear from the tool name.

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 ('Poll a checkout by checkout_id') and the resource, and distinguishes it from siblings by specifying return fields and use cases relative to complete_checkout.

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 provides two concrete use cases: verifying customer details before calling complete_checkout, and retrieving payment_url after complete_checkout. This guides the agent on when to use this tool.

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, but the description fully discloses behavior: production takes 5 working days excluding holidays, returns specific fields, and cautions against promising final delivery. It accurately sets expectations without contradiction.

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?

Extremely concise: two sentences plus a clear usage tip. Front-loaded with main purpose, no wasted 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?

Given the simple parameter, no output schema, and no annotations, the description is remarkably complete. It explains the logic, output fields, and limitations, covering what an agent needs to know.

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

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

Schema has 1 parameter with 100% coverage, so baseline is 3. The description does not add significant meaning beyond what the schema provides; it mentions the output but not how the parameter affects it.

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 estimates dispatch time for a new order, with specific verb 'Estimate' and resource 'dispatch'. It distinguishes itself from siblings like get_order and create_order by focusing on delivery estimation.

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 when-to-use context: 'Call this when a customer asks when will it arrive?' and warns against quoting final delivery dates due to variable transit times. This gives clear guidance on appropriate 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?

No annotations are provided, so the description bears full responsibility. It discloses the authentication mechanism and the types of data returned (payment status, production status, dispatch date), giving full 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?

The description is two sentences, front-loaded with action and resource, every sentence adds value 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?

Despite no output schema, the description enumerates the return fields (payment status, production status, dispatch date) and covers all key aspects for a retrieval tool. It is complete and informative.

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 0% schema description coverage, the description adds essential meaning: it explains that customer_email serves as soft-auth and must match, and that it retrieves specific order details. This compensates fully for the lack of schema descriptions.

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 retrieves a confirmed order's status, items, and payment details by order_id. It uses a specific verb (retrieve) and resource (order details), distinguishing it from sibling tools like cancel_cart, create_order, etc.

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 mentions that customer_email is required as soft-auth and must exactly match the order record, preventing arbitrary lookups. This provides clear when-to-use and implicit when-not-to-use 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?

No annotations are provided, so the description bears full burden. It discloses that the tool returns a list of processors with capabilities, and indicates it's a read operation by stating 'List available...' without mention of side effects. While it doesn't detail caching or rate limits, the behavioral disclosure is adequate.

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 convey all necessary information with no redundancy. Front-loaded with the primary action and resource.

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?

The description includes what is returned (processors and capabilities), references sibling tools for next steps, and provides usage context. Without an output schema, it offers sufficient completeness for a listing tool, though it could mention if the list is exhaustive or dynamic.

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 has 100% description coverage for the single optional parameter, already explaining it's for future filtering. The description adds no additional meaning about the parameter, 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 it lists available payment processors and their capabilities, specifically naming Yoco and Ozow. It distinguishes the tool by indicating it informs the payment_method field in create_checkout and complete_checkout, setting it apart from sibling tools.

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: 'when the customer asks how can I pay?' or before presenting options. Also explains how the result feeds into other tools, providing clear context.

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 indicates the tool returns unit and total prices with VAT included. However, with no annotations provided, it does not explicitly state that it is read-only or non-destructive, leaving some behavioral transparency gaps.

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 with two front-loaded sentences that efficiently convey the tool's purpose, required context, and next steps without unnecessary 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?

Given no output schema, the description mentions the return values (unit_price_zar and total_price_zar) and provides a clear workflow. It covers essential context for correct invocation, though it could hint at default behaviors for optional parameters.

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 provides 100% coverage with descriptions for all parameters. The description adds value by explaining that product_id is sourced from other tools and that width_mm and height_mm are required, though it does not elaborate on the optional parameters beyond schema details.

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 gets an exact ZAR price for a product at specific dimensions, distinguishing it from sibling tools like search_products or configure_product by specifying its function and output.

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 instructs that product_id should come from search_products or lookup_catalog and that configure_product should be called next. It lists required parameters but does not explicitly state when not to use the tool or mention 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?

No annotations provided, so description carries full burden. It lists what is returned but does not disclose error behavior, authentication needs, or side effects. Acceptable for a read-only fetch tool, but could be more 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?

Two concise sentences, front-loaded with action and context. No wasted words; every part provides 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 single-parameter fetch tool with no output schema, the description fully covers purpose, inputs, and return content. No obvious 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 has no parameter descriptions (0% coverage), but the description adds meaning by naming the parameter with examples (e.g., 'roller-blockout') and explaining its role. This adds value beyond the 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?

Clearly states it fetches complete product details by ID with examples of product IDs and lists return fields (colours, stock, materials, etc.). However, it doesn't explicitly differentiate from siblings like get_price or search_products, though the scope is implied.

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 guidance: 'Use before configure_product to confirm a colour exists and is in stock before committing.' This gives clear context and a use case, but does not mention when not to use it or 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?

No annotations are provided, so the description carries the full burden. It discloses the required parameter, optional filters, and a special routing case. However, it does not explicitly state whether the operation is read-only or has side effects, nor does it mention any auth or rate limits. Given no annotations, the transparency is adequate but not thorough.

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 very concise, using two sentences (effectively three clauses) to convey all necessary information. It front-loads the core purpose and then adds details. Every sentence adds value without 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 tool has 5 parameters (1 required) and no output schema, the description provides a fairly complete picture: input constraints, optional filters, output summary, and next steps. The only minor gap is not detailing the exact output format or confirming it is a read-only operation, but overall it is well-rounded.

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 compensate. It lists the required primary_concern with its valid values, and mentions optional narrowing by room, location, budget, and aesthetic. However, 'budget' is used instead of the schema's 'max_budget_zar', which could cause confusion. No format details are given for location or aesthetic.

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 translates a customer's primary concern into a product recommendation. It specifies the exact enumerated values for primary_concern and lists optional filters. The output (product_id with rationale) and next steps are also mentioned, distinguishing it from sibling tools like get_price and configure_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?

Provides explicit guidance on when to use (given a customer's primary concern) and what to do next (pass result to get_price or configure_product). Also notes a special routing for security concerns. However, it does not explicitly state when not to use the tool or compare with alternatives like search_products.

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 carries the full burden. It discloses the routing logic and phone numbers but does not clarify that the tool only generates a link and does not send a WhatsApp message. This omission could lead to incorrect assumptions about 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 remarkably concise: two sentences that efficiently convey purpose, routing rules, and usage guidance. 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 the tool has 4 parameters and no output schema, the description adequately covers purpose and routing but fails to describe the output format (e.g., a URL string) and does not mention the customer_name parameter's role. The absence of behavioral annotations heightens the need for completeness, but some gaps remain.

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 75% (3/4 parameters described), and the description adds value by explaining how location drives routing and providing an example for product_context. However, the customer_name parameter lacks a description in both schema and tool description, leaving its purpose unexplained.

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 generates a pre-filled WhatsApp deep link for customer handoff, with specific verb 'Generate' and resource 'pre-filled WhatsApp deep link'. It distinguishes itself from sibling tools by focusing on human assistance handoff, whereas siblings deal with cart/checkout operations.

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: 'when the customer prefers human assistance or when self-serve checkout isn't appropriate', providing clear guidance. However, it does not explicitly state when not to use it or contrast with alternatives, leaving some room for ambiguity.

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, but description discloses it returns matching products with id and url. It is a read-only lookup, but could explicitly state non-destructive nature. 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?

Three sentences, front-loaded with purpose, no redundant information. Efficiently conveys 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?

Return fields are specified, and usage context is clear. No mention of pagination or limits, but for a simple filter tool it is largely complete given the 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 description coverage is low (25%), but description enumerates parameters and provides category options. However, it lacks format for colour and units for dimensions, leaving some ambiguity.

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 it is a structured catalogue filter and lists specific filter criteria (category, colour, dimensions). It distinguishes itself from search_catalog for open-ended queries.

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 says 'Ideal when the customer has stated a blind type' and instructs to use search_catalog for natural language queries, providing clear guidance on when to use this tool.

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?

Discloses that the tool returns a pre-filled WhatsApp link, implying a handoff rather than automatic processing. No annotations exist, so description carries full burden; it is transparent but could explicitly state if verification occurs.

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: first states purpose, second gives conditions and output, third lists exceptions and requirements. Every sentence adds value, no 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?

For a tool with no output schema, the description explains the output (WhatsApp link), covers when to use, exceptions, and required parameters. It is sufficiently complete for the agent to understand the tool's role and behavior.

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 parameters are well-documented. Description adds business context (dimensions must match, product_id and competitor_price_zar are required, etc.), enhancing understanding beyond the 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?

Clearly states the tool submits a price match claim when a customer finds a cheaper identical blind elsewhere. It specifies the action, resource, and distinguishes from siblings by its unique function.

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 (customer found cheaper elsewhere), lists exclusions (Blinds Direct, clearance, out-of-stock), and mentions minimum required parameters. Provides clear context for 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?

With no annotations, the description carries full burden. It discloses that swatches ship only at order placement, caps at 5 codes, and implies this is for orders. However, it does not clarify whether an order must already exist or if this is part of order creation, leaving a minor gap.

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 clearly front-load the main action and then provide essential behavioral constraints. No wasted 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?

No output schema, so return behavior is unclear. The description does not mention prerequisites (e.g., need an existing order/cart) or what the tool returns. While it provides good usage context, it leaves operational gaps for an AI agent.

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 67%; undocumented parameters (customer_name, customer_email) lack explanation in description. The description reinforces swatch_codes max 5 but adds no new info beyond schema. Baseline 3 due to coverage <80%, and description does not compensate for missing descriptions.

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 'Register' and the resource 'colour swatches', specifying they are dispatched with the customer's order, up to 5. This is distinct from sibling tools like check_colour_stock (stock check) and others.

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 (register swatches for order), when not to (swatches ship only with order, not standalone), and provides customer guidance for the alternative scenario. No sibling tool overlaps with this functionality.

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 the description carries the burden. It discloses that it is a read operation, returning specific fields (id, name, category, description, product_url). However, it does not explicitly state that it is read-only or mention any auth requirements, but the search nature implies safety.

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 that efficiently convey purpose, usage, and output. No wasted words; front-loaded with action 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?

Given the tool's simplicity (one parameter, no output schema), the description covers the core functionality. It does not mention pagination or result limits, but for a search tool with clear return fields, it is largely 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 coverage is 100% with a single parameter 'query' that already has a description. The description adds example queries but does not provide additional semantic value beyond what the schema already conveys.

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: 'Free-text search across the full catalogue' with examples like 'blockout for bedroom' or 'wood venetian'. It distinguishes from sibling tools like lookup_catalog by specifying that this tool is for open queries, not filtered 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?

Provides clear usage context: use for open free-text queries, and for filtering by category/colour/dimensions, use lookup_catalog instead. Also advises to pass the returned id to get_product or get_price, giving a clear workflow.

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. It describes a read-only search operation with no side effects, though it does not explicitly state 'read-only'. Nonetheless, the action is clearly non-destructive and transparent about outputs.

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 crisp sentences front-load the purpose and usage, then detail outputs and next steps. 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?

Five optional parameters are covered, output fields listed, and province behavior explained. However, it does not describe how filters combine (e.g., AND between type and colour) or specify that province is optional, which could be ambiguous.

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 baseline 3. The description summarizes parameters (type, colour, dimensions) but does not add new semantic detail beyond the schema. The province parameter's conditional behavior is mentioned, adding marginal value.

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 searches for products when no product ID is known, filters by blind type, colour, dimensions, and returns specific fields. Distinguishes from siblings like get_product or get_price by specifying prerequisite workflow.

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 advises when to use (customer hasn't specified a product ID) and provides next-step instruction to pass product_id to get_price or configure_product, guiding the agent's workflow.

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. It discloses the auth requirement, the input dependency on configure_product, and the manual response nature. However, it does not mention side effects (e.g., record creation), idempotency, or error handling, which would be helpful for a submission 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?

Two sentences cover all essential information: legacy status, alternative flow, use case, prerequisites, and response time. No redundant phrases; every clause contributes meaningfully.

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 complexity (5 parameters, nested object, no output schema), the description provides sufficient context for an agent to decide to use it and how to invoke it. It lacks only explicit return value info, but the implied response (team follows up) partially covers that. Overall well-rounded for its purpose.

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 baseline 3. The description adds value by explaining that product_config comes from 'configure_product output' and enumerates the required contact fields (name, email, phone). This clarifies the source and purpose beyond the schema's brief descriptions.

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 identifies the tool as a legacy auth-required tool for sales follow-up via email, distinguishing it from the open UCP flow. It specifies the verb ('submit_enquiry') and the resource (enquiry for sales team), and contrasts with sibling tools like create_cart and complete_checkout.

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 this tool ('when the customer wants a sales team follow-up by email rather than paying online') and when to prefer alternatives ('prefer the open UCP flow'). Also lists required prerequisites (Bearer token, configure_product output) and the expected response timeline (24 hours).

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 the description fully bears the burden. It describes the effect of each op, customer merge, and the checkout constraint. It does not disclose potential errors or side effects, but the operations are straightforward.

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 concise paragraph with no filler. It front-loads the purpose and quickly enumerates operations and constraints. 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?

Given no output schema and 5 parameters with nested objects, the description covers the main operations and constraints. It could detail the structure of items and customer more, but it is sufficient for basic usage.

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 only 20% (only indices has a description). The description adds meaning for op values, customer field (merging details), and items implicitly. However, it does not detail the format of items or customer object, leaving some ambiguity.

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 modifies an open cart before checkout and explains the four operations (add, remove, set, clear). It distinguishes from sibling tools like create_cart, get_cart, cancel_cart, etc., by specifying the context of an open cart pre-checkout.

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 says to use before checkout and that it cannot modify a cart with a checkout in progress. It also recommends calling get_cart to confirm. However, it does not explicitly compare to sibling tools for when to use alternatives, but the context is 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?

With no annotations provided, the description takes full responsibility. It discloses that the tool modifies an unpaid checkout, returns the updated state, and raises errors for paid/cancelled checkouts. It lacks details on side effects (e.g., logging) or authorization requirements, but is sufficiently transparent for 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?

The description is extremely concise: two sentences covering purpose, usage context, parameters, return value, and error condition. No unnecessary words, and key information is 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 3 parameters, no annotations, and no output schema, the description adequately covers what it does, parameters, return, and error. It could be more complete by mentioning that only provided fields are updated (partial update) or providing validation hints, but it is largely sufficient.

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?

Despite 0% schema description coverage, the description adds significant meaning: it explains that 'customer' contains name, email, phone, and address, and that 'payment_method' is an enum of yoco or ozow. This compensates fully for the lack of schema descriptions.

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 updates customer details or switches payment method on an unpaid checkout. It distinguishes from siblings like create_checkout (create), complete_checkout (finalize), and cancel_checkout (cancel) by specifying the precondition and its role in the checkout flow.

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 context by stating it should be used before complete_checkout and on an unpaid checkout. It also notes that it raises an error if paid or cancelled, implying when not to use it. However, it does not explicitly mention alternatives or when to choose this over other update tools.

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