Custom Blinds Shop

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

No annotations exist, and the description only says 'Discard a cart.' It does not disclose whether the operation is destructive, reversible, or requires authorization, leaving significant behavioral ambiguity.

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 brief but includes an irrelevant first sentence ('UCP 2026-04-08 spec method') that adds no value. It is not concise; it is under-specified.

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 lack of output schema, annotations, and parameter descriptions, the description fails to provide essential context like effect on cart state, idempotency, or relation to checkout lifecycle.

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 'cart_id' parameter is not described in the description. With 0% schema coverage, the description adds no meaning beyond the parameter name itself.

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 'Discard a cart' clearly states the action ('discard') and resource ('cart'), distinguishing it from siblings like 'cancel_checkout' or 'update_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?

No guidance is provided on when to use this tool versus alternatives like 'cancel_checkout' or 'update_cart'. The description lacks context for 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 must fully disclose behavior. It only states the cancellation action without describing side effects, auth requirements, idempotency, or state changes. This is insufficient 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 very short but includes the unnecessary phrase 'UCP 2026-04-08 spec method,' which adds no value. It could be more concise without the meta-commentary.

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 tool with one parameter, the description provides the basic purpose but lacks behavioral details, parameter semantics, and output information. It is not fully complete for reliable agent 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 0% with no parameter descriptions. The description does not explain the checkout_id parameter's format, source, or constraints, failing to compensate for the schema's lack of information.

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 cancels a checkout that hasn't been paid. It identifies the resource (checkout) and action (cancel), distinguishing it from siblings like cancel_cart. However, it lacks explicit differentiation from similar tools like 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?

The phrase 'not yet been paid' provides a condition for use, but there is no explicit when-not-to-use or alternative recommendations. The usage context is implied rather than stated.

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 behavior: real-time query, returns boolean, restock date, and alternatives. However, it omits details like error handling, idempotency, or side effects. A score of 3 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?

The description is a single, well-structured sentence that conveys all essential information without unnecessary words. Every part is informative.

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 partially compensates by listing return fields (in_stock, restock date, alternatives). However, it lacks details on field types, error responses, and what happens for invalid inputs. This is adequate but not thorough.

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%, and the tool description adds no meaning to the two parameters (product_id, colour_name). It does not explain their format or expected values, leaving the agent to guess.

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 'real-time per-colour stock check' with a specific verb and resource. It distinguishes itself from sibling tools like get_product by focusing on colour-specific stock status and returning 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?

No guidance on when to use this tool versus alternatives (e.g., get_product or get_price). The description does not mention context, preconditions, or when not to use it.

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 the full burden of behavioral disclosure. It mentions that the tool returns a payment_url and that a webhook flips the order to 'paid', providing some insight into async behavior. However, it omits critical details like idempotency, error handling, and side effects on the checkout object.

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 at three sentences, but the first sentence ('UCP 2026-04-08 spec method') is cryptic and adds little value. The remaining sentences are clear and directly convey the action and result. Overall, it is efficient with minimal waste.

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 lack of output schema, the description should explain the complete response. It only mentions 'payment_url', leaving out other possible fields or error states. There are 24 sibling tools, but no guidance on how this tool integrates into the checkout flow. The description is insufficient for an agent to fully understand prerequisites and outcomes.

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%; the description adds context for payment_method by explaining the enum values ('yoco card or ozow EFT') and noting it overrides previous values. However, checkout_id is left unexplained, and the description does not fully compensate for the missing 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's action: mint a payment link using a chosen payment method. It specifies the verb ('mint') and resource ('payment link via checkout'), and distinguishes from siblings like create_checkout or cancel_checkout by focusing on payment completion.

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 does not explicitly state when to use this tool versus alternatives such as create_checkout or cancel_checkout. It lacks guidance on prerequisites, when not to use, or workflow context, leaving the agent to infer the tool's role.

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, and the description does not disclose whether the tool has side effects (e.g., creating a draft) or is read-only. It lacks details on auth requirements, rate limits, or other behavioral traits beyond the obvious return of a summary.

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 only two sentences, both front-loaded with the main action and output. Every word contributes value, with no extraneous 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?

Despite 8 parameters, no output schema, and no annotations, the description is too brief. It omits important context such as how price is calculated, the prerequisite for product_id (from search_products), and the province parameter's special behaviour (mentioned only in schema). The tool is moderately complex but the description does not cover it adequately.

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% coverage with descriptions for all 8 parameters. The description adds no extra meaning to individual parameters beyond noting that price is calculated (an output). Baseline 3 is appropriate since the schema already handles parameter 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 it builds a complete blind configuration with specific components (product details, colour, dimensions, mount type, calculated price) and returns a summary. It uses a specific verb and resource, distinguishing it from siblings like get_price or search_products by its composite nature, though it doesn't explicitly reference alternatives.

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

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

The description implies usage context (final step before ordering) but provides no explicit guidance on when to use this tool versus alternatives like get_price or search_products. There are no exclusions 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?

Discloses creation behavior, return value (cart_id), and 24-hour TTL. No annotations provided, so description carries full burden; adequately covers key behavioral aspects but could mention if existing cart is replaced.

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

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

Two sentences, no wasted words. First sentence states spec and core purpose, second provides key features and return value. Well-structured and 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?

Covers purpose, optional parameters, return value, and TTL. Missing details like what happens if no items supplied, but for a simple creation tool with no output schema, it is fairly 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%, and description adds minimal value beyond schema descriptions. Mentions 'seed with items and customer details' which aligns with schema, but no additional semantic detail.

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 verb 'create' and resource 'cart', with context of being for the agent and optional seeding. Differentiates from sibling tools like get_cart (read), update_cart (modify), cancel_cart (delete).

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?

Implies usage as initial step for cart operations, mentions optional seeding. Lacks explicit exclusion or alternative comparisons, but context implies when to use.

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 discloses key behavioral traits: returns checkout_id, does not mint payment link. However, it does not mention side effects (e.g., whether the cart is modified), permissions, or error conditions. Still, the core behavioral insight is valuable.

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 with no wasted words. Four short sentences that front-load the purpose and then provide essential behavioral context. 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 limited parameter descriptions, the tool definition adequately covers what the tool does, its inputs, and the absence of payment link creation. Could mention more about the customer object's required fields, but overall complete enough.

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 description adds meaning beyond the schema by clarifying the relationship between cart_id and items ('from a cart_id or inline items + customer'). It also mentions that customer is required even though schema marks it as optional. Schema coverage is 50%, but the description compensates by summarizing usage.

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 action (Create a checkout), the resource (checkout), and the inputs (cart_id or inline items + customer). It returns checkout_id and distinguishes from sibling tools like 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 ('Create a checkout') and when not to use it ('Does NOT mint payment link yet — call complete_checkout for that'). Provides clear context for the next step.

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 fully disclose behavior. It states the tool creates a draft order and returns a payment link, and requires authentication, but omits details on side effects, stock checks, or what happens on payment failure. This is insufficient 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 three short sentences, each providing essential information: action, return value, and authentication. No redundant or extraneous text.

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 high schema coverage, the description lacks details about the return value format (e.g., structure of the payment link response) and error handling. Given no output schema, this creates a gap for the 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?

All parameters have descriptions in the schema (100% coverage), so the description adds no new parameter information. 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 the tool creates a draft order and returns a Yoco payment link. It differentiates from siblings like create_cart or create_checkout by specifying the output is a payment link, but doesn't explicitly contrast with similar order-creation 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?

The description only mentions that API key authentication is required, but does not provide guidance on when to use this tool versus alternatives like create_checkout, nor any prerequisites or exclusions.

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 what the tools do (AR uses phone camera and A4 page) and implies read-only behavior by returning a URL. However, it does not explicitly state side effects, auth needs, or rate limits. Adequate but not comprehensive.

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 plus a usage sentence, all front-loaded. No redundant information. 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?

Missing output schema. Description only says it returns 'the URL' but does not specify response format (e.g., single string, JSON object) or error handling. For a simple tool, this is a notable 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%. Description adds context about the tools' purposes but does not significantly enhance parameter meaning beyond the schema, which already describes mode and product_id with defaults and examples. 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 returns URLs for two specific tools (AR measurement and product visualizer) and explains what each does. It distinguishes itself from sibling tools like configure_product or get_product by focusing on visualization and measurement.

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: 'when a customer wants to measure, visualize, or see how it looks before ordering.' Does not explicitly exclude alternatives, but context makes it 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?

No annotations provided, so description bears full burden. It merely states 'Return', implying a read operation, but lacks details on side effects, authentication, error behavior, or what happens if cart_id is invalid.

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?

Only two sentences, but the first is boilerplate ('UCP 2026-04-08 spec method') that adds no value. The second is clear but not particularly structured. Could be slightly more informative 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 1 required parameter, no output schema, and no nested objects, the description is minimal but covers the basic function. It lacks details on error handling or cart state, but is adequate for a simple retrieval tool.

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

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

Schema description coverage is 0%, and the description adds no meaning beyond the parameter name 'cart_id'. It does not explain the format, scope, or usage of the parameter.

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 'Return the current cart contents, total, and customer details,' with a specific verb and resource. It distinguishes from sibling tools like get_checkout or get_order, though it doesn't explicitly contrast them.

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

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

No guidance on when to use vs alternatives. The first sentence 'UCP 2026-04-08 spec method' is not usage advice, and there is no mention of preconditions or 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?

No annotations are present, so the description must disclose behavioral traits. It only states what information is returned but does not mention side effects (destructive or not), authentication needs, rate limits, or error behavior. For a read operation, it should at least imply non-destructiveness. The lack of such details creates uncertainty for the agent.

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 but includes the extraneous phrase 'UCP 2026-04-08 spec method,' which does not aid an AI agent and may cause confusion. The rest is a single sentence that efficiently states the return content, but the wasteful filler reduces effectiveness.

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 an output schema, annotations, and the presence of many sibling tools, the description is incomplete. It does not cover return structure, error scenarios, or prerequisite steps (e.g., checkout must exist). An agent lacks sufficient information to correctly invoke or interpret results from this 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 has one required parameter, checkout_id, with no description. The tool description does not explain what checkout_id refers to or any constraints on its format. With schema description coverage at 0%, the description should compensate but fails to add meaningful guidance on parameter usage or expected values.

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 that the tool returns checkout state, items, customer, and payment status. It uses a specific verb 'Return' and identifies the resource (checkout). This distinguishes it from sibling tools like cancel_checkout or complete_checkout that modify the checkout. However, the phrase 'UCP 2026-04-08 spec method' is unnecessary jargon.

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 guidance is provided on when to use this tool versus alternatives like get_cart or get_order. An AI agent given multiple sibling tools would benefit from context such as 'Use after creating a checkout to verify its initial state' or 'Use to check payment status before completing checkout.' Without such cues, the agent must infer based on the name alone.

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 discloses key behaviors: production takes 5 working days (Mon–Fri, excluding SA public holidays), returns dispatch date, production days, and a customer-safe summary. It does not mention idempotency, rate limits, or side effects, but covers the essential operational details beyond the schema.

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-loading the purpose in the first sentence. Every sentence serves a distinct purpose: stating what the tool does, then providing essential behavioral constraints and return structure. No redundant or missing information.

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

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

Given low complexity (one param, no output schema), the description covers the core functionality, return fields, and key business rules. It could mention authentication assumptions or prerequisites (e.g., an existing order context), but overall it is sufficient for an agent to determine if and how to use the tool.

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

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

Schema coverage is 100% for the single optional parameter order_date. The description reinforces its optionality, default behavior (today), and includes an example format (ISO date). This adds practical context beyond the schema description, earning above-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 calculates estimated dispatch date for orders, specifying verb (calculate), resource (dispatch date), and context (for orders placed today or a specified date). It differentiates from sibling tools focused on order management, catalog lookup, or checkout processes.

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 advises against quoting a specific delivery ETA because delivery time varies by location, providing explicit usage restriction. It also indicates the output includes a plain-language summary safe for customer sharing, implying appropriate use cases. However, it does not explicitly compare to alternatives or specify when not to use.

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 the soft-auth behavior, which is beyond the input schema. No annotations are provided, so the description carries the burden; it adequately conveys the lookup action and authorization check.

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

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

Two sentences, no redundancy, front-loaded with purpose. 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?

Lacks output description and error conditions (e.g., order not found, auth failure). However, for a simple lookup tool, key behaviors are covered. Sibling differentiation is implicit but not exhaustive.

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 coverage, the description adds full meaning: order_id is the lookup key, customer_email serves as soft-auth and must match. This is essential guidance the schema does not 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?

Description clearly states 'Look up a placed order by order_id', specifying verb (look up), resource (placed order), and key identifier. Distinguishes from siblings like get_cart or create_order by focusing on placed orders.

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 notes that customer_email is required for soft-auth and must match the order record, guiding correct invocation. Does not explicitly exclude other contexts, but the purpose 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?

No annotations are present, so the description must carry full behavioral burden. It states the tool returns handlers and capabilities, which implies a read operation, but does not explicitly confirm no side effects, authorization requirements, or rate limits. This is adequate but minimal for a simple listing 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 with essential information front-loaded. No wasted words; every sentence serves a purpose.

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 (0 required params, no output schema), the description is fairly complete. It specifies the return type and usage context. Could mention that it is a safe, idempotent operation, but overall adequate.

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 is 3. The description does not add any extra information about the parameter beyond what is in the schema; it merely restates the schema's description. No 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 specifies a specific verb ('Return'), resource ('available payment handlers'), and explicitly names examples ('Yoco card, Ozow instant EFT'). It also indicates the context of use ('before complete_checkout'), differentiating it from sibling tools like complete_checkout and get_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 clearly states when to use the tool ('to inform the customer of options before complete_checkout'), providing usage context. However, it does not explicitly state when not to use it or list alternative tools, so a slight deduction.

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. The description discloses that prices include VAT and the return format, but does not mention if it's read-only, any prerequisites, or side effects. It is adequate but not detailed.

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: first describes the action, second describes the output. No redundant information. Very 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?

Given 6 parameters (all described in schema) and no output schema, the description explains the return values. It does not mention edge cases or additional constraints, but is complete enough for a pricing tool.

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

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

Schema coverage is 100%, so parameters are well-documented. The description adds context that the tool returns prices in ZAR including VAT, but does not add extra meaning to parameters 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?

The description clearly states it calculates an instant price quote for a specific blind product given width and height in millimetres, and specifies the output (unit price and total in ZAR). It distinguishes from siblings like search_products 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?

The description implies when to use (to get a price for a product before ordering), but does not explicitly mention when not to use or alternative tools. Context is clear among siblings.

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 states that the tool returns details but does not explicitly confirm it is a read-only, non-destructive operation. The name 'get' implies safety, but explicit disclosure would improve 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 a single sentence divided into two parts, making it concise and front-loaded. The spec reference 'UCP 2026-04-08 spec method' adds minor overhead but does not significantly detract from clarity for an agent familiar with the spec.

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

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

Given the low complexity (1 parameter, no output schema, no annotations), the description provides sufficient context for the tool's core purpose and return values. However, it lacks details about error handling or validation, which would be beneficial for a complete understanding.

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 0% description coverage for the single parameter 'product_id'. The description does not elaborate on the parameter beyond implying it identifies a product (via 'Returns full details for a single product'). No format, constraints, or examples are provided, failing to compensate for the missing 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 action ('Returns full details') and the resource ('single product'), listing specific details included (colours, materials, features, pricing notes, schema URL). This distinguishes it from sibling tools like search_products which return multiple results.

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

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

The description implies usage for retrieving a single product by ID but lacks explicit guidance on when to use this tool versus alternatives like search_products or get_product_recommendation. No exclusions or prerequisites are 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?

With no annotations, the description carries the full burden. It discloses deterministic behavior and a handoff for security concern, which is helpful. However, it does not mention any destructive actions, rate limits, or other behavioral nuances.

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, front-loaded sentences with no filler. 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 5 parameters, no output schema, and no annotations, the description covers the main purpose and a special case but leaves location and aesthetic unexplained. Lacks output format info, making it adequate but not 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 coverage is 0%, so description must compensate. It explains primary_concern, room, and max_budget_zar, but omits location and aesthetic. Adds some meaning but not complete parameter coverage.

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 recommends Custom Blinds products based on primary concern, room, and budget, with a specific note about deterministic mapping and a special case for security. It distinguishes from sibling tools that are transactional in nature.

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

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

The description implies usage for product recommendations, contrasting with sibling tools for cart, checkout, and orders. It provides a specific condition for security concern, but lacks explicit 'when to use' or 'alternatives' 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 provided, so description must cover behavioral traits. It discloses routing logic and that the link is 'pre-filled', but does not describe the return value (e.g., a URL string) or whether it is a read-only operation. Some behavioral transparency is missing.

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

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

Single sentence that front-loads the action and key routing rule. No unnecessary words. Efficient and clear.

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 purpose, routing, and parameter hints. Missing return value description and explanation of 'customer_name' parameter. Among 25 sibling tools, this is the only WhatsApp handoff tool, so context is fairly complete for a simple link generator.

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%, and description adds useful context: message is optional, location drives routing, product_context example. However, 'customer_name' lacks both schema description and description text, leaving a gap. Overall adds significant value 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 it generates a pre-filled WhatsApp link routed to specific contacts. Differentiates from siblings which are cart, checkout, order, or catalog tools. The verb 'generate' and resource 'WhatsApp link' are specific.

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 specifies routing based on location: Garden Route goes to Duncan Kane, others to shop line. Implies when to use (handoff to WhatsApp). Does not explicitly state when not to use, but context is clear given sibling tools.

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

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

No annotations provided, so description must disclose behavior. It only mentions 'UCP 2026-04-08 spec method' (unclear) and filtering, but does not state side effects, auth needs, rate limits, or return format.

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 spec reference, and no wasted words. Efficiently communicates purpose and alternative.

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?

Complete enough for a filter tool with no output schema, though it could clarify that results are a list of matching products. Sibling tools provide context.

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 adds context that parameters are for structured criteria and dimensions. With only 25% schema coverage, it compensates by listing category, colour, and dimensions, though doesn't define each parameter's values or constraints.

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 filters the catalogue by structured criteria (category, colour, dimensions), and explicitly distinguishes it from search_catalog for free text.

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

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

Provides explicit guidance to use search_catalog for free text, implying this tool is for structured queries, which helps the agent select the right 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?

Describes return value (pre-filled WhatsApp link and confirmation message) and constraints (exclusions). Does not clarify whether the claim is actually submitted or just prepared, but overall transparent given no annotations.

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

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

Three sentences, no fluff, front-loaded with purpose. 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?

Covers purpose, usage, exclusions, and return. Ambiguity remains on whether the tool actually submits the claim or just generates a link, and the dimension parameters are implied as required but not marked as such in 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%, so baseline is 3. Description provides overall context but no additional parameter-level details 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?

The description clearly states the tool submits a price match claim, specifies the matching criteria (same product, dimensions, specs from authorized SA retailer), and lists exclusions, distinguishing it 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?

Provides clear context for when to use (price matching scenario) and explicit exclusions (Blinds Direct, clearance, flash sales, out-of-stock). No alternative tools are mentioned, but the purpose is well-defined.

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 responsibility. It discloses key behaviors: swatches are tied to order placement, capped at 5 samples, and the tool registers the request against an order. While it doesn't mention permissions or side effects, it provides sufficient transparency for typical use.

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-loading the core action and constraints. Every sentence is meaningful, with no redundant or extraneous text.

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 mentions 'against an order' but the input schema does not include an order identifier. This is a significant gap in completeness, as the user cannot specify which order the swatch request is for. Otherwise, the description covers core behavior and constraints, but this missing detail reduces effectiveness.

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%. The description adds value by explaining that swatch_codes is optional and max 5, customer_phone used as WhatsApp number, and product_interest examples. It also contextualizes the parameters within the overall function.

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: registering a swatch request against an order. It specifies that swatches are dispatched with order placement, not standalone, and caps samples at 5. This distinguishes it from siblings like create_order or get_product.

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

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

The description provides explicit usage guidance: use when a customer wants swatches, but do not promise standalone delivery; guide the customer to place an order first. These instructions clearly indicate when and when not to use the 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?

With no annotations, the description carries full burden. It describes the operation as a search and mentions return fields, but does not explicitly state it is read-only or non-destructive. Provides basic transparency but not thorough behavioral context.

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

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

Two sentences, each earning its place: first identifies spec, second describes core functionality and output. Could be slightly expanded for sibling differentiation, but no fluff.

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

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

Returns fields are listed, but no mention of pagination, sorting, or limits. Lacks comparison to sibling tools like search_products. Adequate for a simple search but missing context that would help an 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 coverage is 100%, so the schema already explains the 'query' parameter. The description adds example values but does not add significant new meaning 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 tool does a free-text search of the Custom Blinds catalogue and lists return fields. However, it does not differentiate from sibling tools like lookup_catalog or search_products, which may have overlapping functionality.

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 guidance is provided on when to use this tool vs alternatives. The description implies general search use but does not specify when to prefer it over lookup_catalog (perhaps exact lookup) or 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 provided, so the description carries full burden. It describes a read-only search operation with no side effects, but lacks details on pagination, rate limits, or ordering behavior. Adequate but not exhaustive.

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 the action ('Search the Custom Blinds product catalogue'), and no redundant 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?

The description covers filters, return fields, and overall purpose. However, it lacks details on pagination, sorting, or whether multiple filter values can be combined. For a search tool with no output schema, it is mostly 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%, and parameter descriptions in the schema are already clear. The description adds context by grouping parameters and stating return fields, but doesn't significantly enhance parameter 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?

The description clearly states the tool searches the Custom Blinds product catalogue and lists specific filters (blind type, colour, dimensions) and return fields (product ID, name, category, etc.), distinguishing it from sibling tools like get_product or search_catalog.

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

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

The description implies usage for filtering products but provides no guidance on when to use this tool vs alternatives like search_catalog or lookup_catalog, nor does it state when not to use it.

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 key behaviors: sends email and requires API key authentication. However, no annotations exist, and description omits details like side effects (e.g., whether a record is saved), rate limits, or async nature.

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 with front-loaded purpose. Every sentence is informative: first defines action, second explains mechanism (email) and auth requirement. 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?

Adequate for a simple submission tool, but lacks output schema and description of return value (e.g., confirmation ID). Given 5 parameters and nested object, description could hint at what happens post-submission.

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 is 3. Adds value by explicitly stating that product_config comes from configure_product, providing cross-tool context that helps the agent understand data flow.

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 action (submit) and resource (product enquiry). Differentiates from siblings like create_order or configure_product by specifying that it sends an email to the sales team with product configuration and customer message.

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

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

Implied usage after configuring a product (references product_config from configure_product), but no explicit when-to-use or when-not-to-use guidance. No mention of alternatives among siblings.

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 bears full responsibility for behavioral disclosure. It mentions a spec and basic operations but fails to explain side effects like whether items are replaced or appended, the effect of 'clear', or the implications of merging customer data. Critical behavioral traits are omitted.

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 short with two substantive sentences, but includes a cryptic spec reference ('UCP 2026-04-08 spec method') that adds no value for an AI agent. It could be trimmed without loss of clarity.

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

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

Given the tool's complexity (5 parameters, nested objects, no output schema) and lack of annotations, the description is insufficient. It does not explain return values, error states, or behavioral invariants, leaving the agent without crucial context for reliable 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 schema description). The tool description adds meaning for 'op' (enum values) and hints that 'customer' merges details, but does not describe 'items' or its structure. This partially compensates for low coverage but leaves major gaps.

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 'Modify cart contents' and enumerates the possible operations (add, remove, set, clear), making the tool's purpose unambiguous. It is distinct from sibling tools like 'create_cart' or 'get_cart', though it does not explicitly differentiate itself.

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 'configure_product' or 'update_checkout'. It simply lists operations without context on typical use cases or prerequisites.

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

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

With no annotations provided, the description bears full responsibility for behavioral disclosure. It mentions the update scope and restriction, but fails to specify whether updates are partial or full, what happens to existing fields not specified, what the response looks like, or any side effects. This is insufficient 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?

Two sentences, mostly focused on purpose. The initial 'UCP 2026-04-08 spec method' is meta-information that adds little value for an agent and could be removed. Otherwise, the description is reasonably concise but could be restructured for clarity.

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 moderate complexity (3 parameters, one nested object), no annotations, and no output schema, the description is incomplete. It does not explain return values, error behavior (e.g., attempting to update a paid checkout), or the allowable structure of the customer object. The agent is left with significant unknowns.

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 explains that payment_method can be changed and references 'customer details', but does not describe the structure of the customer object or the meaning of checkout_id. The nested object's fields remain entirely undocumented, leaving the agent with 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?

Clearly states that the tool updates customer details or payment_method of a checkout, with the constraint 'before completion'. This distinguishes it from sibling tools like create_checkout or complete_checkout, though it could be more explicit about when not to use it.

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 'Cannot update a paid checkout', providing a valuable restriction. However, it lacks guidance on when to choose this tool over alternatives like cancel_checkout or complete_checkout, and does not mention prerequisites (e.g., checkout must exist and be active).

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