Facet UCP Shopping

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

Since no annotations are provided, the description carries the full burden. It discloses important behavioral traits: idempotency, owner-scoping, no money movement, and strict requirements for identity and terminal. This goes beyond the basic action and provides meaningful context for an AI 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 two concise sentences, front-loaded with the primary action. It packs significant behavioral information without redundancy, wasting no words.

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

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

For a simple single-parameter cancel operation, the description covers the action, key consequences (idempotent, no money), and prerequisites. It lacks details on return values or error handling, but given the simplicity and no output schema, it is reasonably 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?

The input schema already provides full coverage of the single 'id' parameter with 'The cart id.' The description adds no additional detail about the parameter itself, so it neither enhances nor conflicts with the schema. Baseline 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 action 'Cancel a cart' with a specific resource, distinguishing it from sibling tools like cancel_checkout. It also adds scope qualifiers (owner-scoped, no money moved) that clarify its purpose.

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 cart cancellation but does not explicitly differentiate from alternatives like cancel_checkout or state when not to use it. It provides context about requirements (identity, Idempotency-Key, signature-required Terminal) which helps an agent determine feasibility.

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 fully bears the transparency burden. It discloses idempotency, owner scoping, that no money moves, and the requirement for identity, Idempotency-Key, and a signature-required terminal. It also explains the inventory release effect.

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 exceptionally concise, with three sentences each serving a distinct purpose: action/effect, behavioral traits, and prerequisites. There is no redundancy or filler, and the most important 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?

For a tool with only one parameter and no output schema, the description is remarkably complete. It covers the purpose, effects, constraints, and prerequisites, enabling an agent to invoke it correctly without ambiguity.

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 'id' is fully described in the schema as 'The checkout session id.' The description does not add any parameter-specific semantics, so it meets the baseline for high schema coverage without needing further elaboration.

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 ('Cancel a checkout session'), its temporal scope ('before completion'), and the specific effect ('releasing its inventory hold'). This distinguishes it from sibling tools like cancel_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?

The description specifies when to use the tool ('before completion'), scopes it to the owner, and explicitly distinguishes it from an escrow refund. However, it does not name alternative tools for related actions (e.g., cancel_cart), so it stops short of fully explicit 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?

With no annotations provided, the description fully discloses the high-stakes behaviors: funds capture on-chain or into escrow, server-side amount re-derivation, signature verification, specific error mappings (per-buyer refusal vs. real 401), and required identity/signature conditions. This is exemplary transparency for a money-moving operation.

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 dense but every sentence delivers critical information: purpose, money-moving nature, verification, error semantics, and prerequisites. It is front-loaded with the core action. Slightly long, but for a high-risk irreversible operation, the length is justified.

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?

This tool is complex (money movement, identity, signatures, two payment paths) with no output schema and no annotations. The description covers behavioral outcomes, error cases, and prerequisites thoroughly. It provides enough context for an agent to invoke it correctly and anticipate failure modes.

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 both parameters, so the baseline is 3. The description adds meaningful nuance, especially for the payment parameter: it explains that the credential must be signed locally and that Facet never holds the key, which is critical security context beyond the schema's type definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: completing a checkout and placing an order. It explicitly identifies this as the 'MONEY-MOVING leg' and contrasts with sibling tools like cancel_checkout and update_checkout, making its unique role unambiguous.

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

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

The description gives strong contextual cues: it is used on a checkout you created, after obtaining a buyer-signed payment credential, and requires identity and a signed Idempotency-Key. It does not explicitly name alternative tools or say 'use this instead of X', but the prerequisites and the money-moving emphasis implicitly distinguish it from related checkout operations.

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 responsibility. It discloses key behavioral details: the cart 'moves no money', 'holds no inventory', has 'estimated (server-derived) totals', and 'NO payment_handlers'. It also states the authentication requirement: 'REQUIRES IDENTITY on a signature-required Terminal.' This is 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?

The description is concise and well-structured. It leads with the main action, then adds necessary behavioral and workflow context in a few sentences without redundancy or unnecessary detail.

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 purpose, workflow, behavioral traits, and prerequisites. The only minor gap is that it does not explicitly state the return value (e.g., a cart object with an ID), though it implies via 'create_checkout(cart_id)' that a cart_id is returned.

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 line_items, including the format and the note that prices are catalog-derived. The tool description does not add extra parameter-level semantics beyond what the schema already provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb and resource: 'Create a pre-checkout cart from catalog line items.' It also distinguishes itself from siblings like create_checkout by emphasizing the cart is a temporary scratchpad, not a final 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 provides explicit workflow guidance: 'Assemble it, then create_checkout(cart_id) to convert.' This tells the agent when to use this tool and how it fits with the checkout flow. It does not explicitly describe when not to use it, 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, the description carries the full burden. It discloses critical behaviors: server-resolved payment_handlers, merchant-sealed price/pay_to, FULFILLMENT_REQUIRED for physical goods, and identity/auth requirements. This goes far beyond basic 'create' wording.

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 dense sentences, each delivering unique information. Front-loaded with the core action, followed by high-value behavioral details. 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?

Given no annotations and no output schema, the description covers the essential selection and invocation context: what it creates, key return value (payment_handlers), constraints, and auth. Complexity is moderate, and the description addresses it well.

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. The description adds meaning by explaining cart_id promotion semantics, line_items structure, and the requirement for fulfillment on physical goods, enhancing what the schema already 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 states a specific action ('Open a checkout session') on a specific resource, and distinguishes it from related tools like create_cart ('or promote a cart with cart_id') and get_checkout. The verb+resource combination is clear and unambiguous.

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

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

It explains when to use this tool versus alternatives (line items vs cart promotion) and provides context for physical goods requiring fulfillment. It doesn't explicitly name sibling tools or exclude scenarios, but the usage context is clearly implied.

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. Clearly discloses authentication requirement (KYA token) and return structure (featured and results). Does not mention rate limits or pagination, but is transparent about critical behavioral trait (auth).

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 plus a detailed auth paragraph. Front-loaded with main purpose. Some minor verbosity in auth section but overall concise and 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 no output schema and 4 parameters, the description explains return values and auth. However, lacks guidance on using 'featured' field in subsequent calls. Mostly complete but could be slightly more actionable.

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

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

Schema description coverage is 100%, so the schema already documents each parameter. The description does not add significant new meaning beyond what is in the schema. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb 'Find businesses' and specific resource 'in the Facet Universal Business Index that an agent can transact with'. Distinguishes between 'featured' and 'results', giving precise scope. Differentiates from sibling tools like get_order 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?

Explicitly tells when to use ('Use this first when you do not already know which merchant to talk to'). Provides pre-requisite: requires a Facet KYA token. Does not explicitly state when not to use, 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 carries the full burden. It discloses the identity requirement (KYA token), the 401 failure mode, the cross-merchant opt-in scope, and the terminal_url return behavior. This is substantial, though it does not mention pagination, sorting, or empty-result behavior.

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

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

The description is front-loaded with the core purpose, then parameter semantics, then usage context, then auth details. Every sentence earns its place, and the structure uses clear signposting (e.g., 'REQUIRES IDENTITY:') without 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?

For a moderately complex search tool with no output schema and no annotations, the description covers what it returns (matches with terminal_url), how to filter properly, when to use it, and the authentication prerequisite. It even advises on next steps (point catalog/checkout calls at terminal_url). This is sufficient for an agent to use the tool correctly.

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

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

The schema already covers all parameters at 100% coverage, so the baseline is 3. The description adds meaningful constraint information: 'at least one filter is required' and clarifies the relationship between filters ('and/or', 'all must be present'). This goes beyond the schema without fully duplicating 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 opens with a specific verb+resource+scope: 'Search products ACROSS every merchant in the Facet network that has opted into cross-merchant discovery.' This clearly distinguishes it from sibling tools like discover_businesses (businesses vs products) and search_catalog/lookup_catalog (likely merchant-scoped).

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

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

It provides an explicit usage condition: 'Use this when you know WHAT you want but not WHICH merchant sells it.' This gives clear context. However, it does not name specific alternatives or explicitly state when not to use it, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden. It discloses owner-scoping, not_found behavior for foreign ids, and the identity requirement, which are key behavioral traits. It does not cover all edge cases (e.g., missing identity) but is transparent for a simple read operation.

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, with the core purpose front-loaded. No redundant phrasing; every clause adds value (scope, return contents, error behavior, prerequisite).

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 one parameter and no output schema, the description covers the input semantics, output contents (line items and estimated totals), error case (not_found), and required identity context. This is sufficient for an agent to correctly invoke 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?

The schema only says 'The cart id', but the description adds that it must be YOUR cart id and that using another agent's id yields not_found. This significantly enriches the parameter's meaning, so it goes beyond the schema baseline.

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 'Read back one of YOUR carts by id' with a specific verb and resource, and mentions the return content (line items and estimated totals). It distinguishes from siblings by noting owner-scoping and not_found behavior.

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 clear context: it's for reading your own cart, and explicitly warns that another agent's id returns not_found, which effectively excludes that use case. It also states the identity requirement on a signature-required Terminal, giving a prerequisite. No explicit alternative tool is named, but the guidance 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 provided, so the description carries the full burden. It thoroughly discloses the return fields, owner-scoping with not_found behavior for foreign IDs, and the identity prerequisite. This is substantial transparency beyond basic read semantics.

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 dense sentences with no redundancy. Each sentence contributes critical information (function, return fields, scope, auth requirement), making it highly efficient and 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?

For a single-parameter read tool with no output schema, the description covers the return content, error behavior, and a prerequisite (identity). This gives an agent everything needed to invoke it correctly and anticipate results.

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 already covers the id parameter with 100% description coverage. The description enriches it by explaining owner-scoping and the not_found result for another agent's ID, which is meaningful context not present in 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 explicitly states the tool reads back a checkout session by ID and lists the returned fields (status, totals, line items, payment_handlers). This clearly distinguishes it from sibling getters like get_cart or 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?

The description indicates the tool is owner-scoped ('another agent's id returns not_found') and requires identity on a signature-required Terminal, implying it is for one's own checkout sessions only. It does not explicitly name alternative tools, but the scope and resource make the usage context 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 exist, so description carries full burden. It discloses that the tool is read-only, returns specific fields, enforces agent-level access control (FORBIDDEN for other agents), and requires a specific authentication mechanism (Bearer KYA). All behavioral traits are explicitly stated.

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

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

Three sentences, each serving a distinct purpose: purpose, constraints, authentication. No wasted words; critical 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 no output schema, the description adequately lists return fields (status, amount, settlement state) and mentions error behavior (FORBIDDEN). The single parameter is explained, and authentication requirement is specified. Complete for an agent to correctly invoke 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% (one parameter fully described). The description adds minor context (order_id returned when you paid) but does not significantly add beyond the schema description. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads back one of YOUR orders on this merchant, specifying the returned fields (status, amount, settlement state). It distinguishes from siblings like list_orders by emphasizing that it retrieves a specific order using order_id and only for the agent's own 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?

Provides explicit when-to-use (to read back an order using the order_id from payment), when-not-to-use (another agent's order returns FORBIDDEN), and prerequisites (identity required with Authorization header). No alternative tools mentioned but clearly delineates scope.

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 the tool is for discovery and requires no identity, implying read-only behavior. While it doesn't explicitly state no side effects, the context is sufficient for safe invocation.

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-load the main purpose, followed by usage guidance and a note on requirements. 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 lacking an output schema, the description provides illustrative examples and relational context with a sibling tool, making it sufficiently complete for a zero-parameter discovery 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% (no parameters). The description adds value by explaining the nature of the returned data (settlement rails and examples), which goes beyond the empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: identifying which settlement rails a merchant accepts. It provides specific examples (e.g., coin/boson-escrow) and distinguishes it from the sibling tool get_payment_requirements by indicating this is a prerequisite.

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 instructs to call before get_payment_requirements to obtain a valid rail_id, preventing guesswork. Also notes that no identity is required, providing clear usage 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?

With no annotations, description fully discloses key behaviors: the offer must be signed locally, the amount is fixed to quote token's sealed total, identity requirements, and that Facet cannot sign. It also explains the return format (escrow address, asset, amount, network). 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?

Description is well-structured with front-loaded purpose, but slightly verbose. Each sentence adds necessary context—workflow steps, identity requirements, and parameter constraints. Could potentially be trimmed slightly, but overall 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, 4 required, no output schema, and no annotations, the description is remarkably complete. It covers the overall workflow, all parameter constraints, behavioral nuances (local signing, fixed amount), and even hints at the output format. No significant 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 coverage is 100%, so baseline 3. Description adds value beyond schema by explaining constraints (amount must equal sealed total, product_id must match sealed product, rail_id purpose). It references related tools (get_quote) and clarifies default for qty.

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 starts with a specific verb ('turn') and resource ('quote_token into a seller-signed payment offer'), clearly stating what the tool does. It distinguishes itself from siblings like get_quote, get_order, and get_payment_capabilities by specifying that it transforms a quote token into a payment offer.

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?

Clearly explains when to use (after get_quote, to authorize payment) and prerequisites (same identity and aid as get_quote). It also explains why paying is two steps and notes constraints like 'Facet never holds your key and cannot sign for you.' No explicit mention of when not to use, but 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, the description must convey behavioral traits. It states 'Get full product detail', implying a read-only operation. However, it does not disclose the response structure, potential limits, or whether the 'full detail' includes all fields. It is adequate but lacks depth.

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, a single sentence that front-loads the purpose. It avoids unnecessary words, but at the cost of missing important details. It is not verbose, but the conciseness may hinder completeness.

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 (nested object parameter, no output schema, no annotations), the description is incomplete. It does not explain what 'full product detail' means, how to differentiate product vs variant, or what the response contains. Sibling tools like 'lookup_catalog' are not addressed.

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 add meaning. It says 'by product or variant identifier' but does not explain how the single 'catalog' parameter maps to different identifiers or what 'catalog.id' represents. The description adds minimal value beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get full product detail') and the method ('by product or variant identifier'). It distinguishes from sibling tools like 'search_catalog' which are broader. However, the input schema uses 'catalog.id' which could be ambiguous, but the description compensates by mentioning both product and variant identifiers.

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 'lookup_catalog' or 'search_catalog'. It does not specify prerequisites or scenarios where this tool is appropriate.

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 behavioral aspects: signing a quote_token, error conditions (FULFILLMENT_REQUIRED, UNDELIVERABLE), authentication requirement. With no annotations, the description carries full burden and does well, though it could explicitly state it's a read-only operation.

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 moderately concise, with each sentence providing essential information. It could be slightly tightened, but it effectively communicates key points without 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?

Given the schema covers all parameters and no output schema exists, the description compensates by explaining the quote_token output and error scenarios. It also covers authentication. A complete picture for selecting and using 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?

The schema has 100% coverage, so baseline is 3. The description adds value by explaining that fulfillment is required for physical products and what errors occur without it, 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?

The description clearly states the tool obtains a real landed cost and a signed quote_token for a product to a destination. While it distinguishes itself implicitly from siblings by its unique role, it does not name specific 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?

Explicitly advises calling before paying, and details prerequisites like fulfillment for physical products and identity token. However, it does not explicitly state when not to use it versus siblings like get_product or get_order.

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, description discloses key behavioral traits: scoped to own identity, requires authorization, returns newest first. Lacks details on pagination behavior beyond cursor or error responses, but adds value 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?

Two short sentences, each carrying weight: first states purpose and scope, second notes identity requirement. No wasted words, front-loaded with key information.

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

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

For a simple list tool with 2 parameters and no output schema, the description covers purpose, scoping, ordering, and auth requirement. Could benefit from noting return shape or pagination behavior, but is largely complete given constraints.

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 description does not need to add much. It provides no extra detail on limit or cursor beyond what the schema already contains, so 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 uses specific verb 'List' and resource 'order history', scopes to 'YOUR' and 'on this merchant', and specifies ordering 'newest first'. This clearly distinguishes it from siblings like get_order (single order) or discover_businesses.

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 identity requirement and authorization header, implying when to use (with valid bearer token). Does not provide explicit when-not-to-use or alternatives, but context is 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?

No annotations are provided, so the description must fully convey behavioral traits. It states 'by identifier (batch)' but does not disclose outcomes for missing IDs, rate limits, or that it is a read-only operation. Key behaviors 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?

A single, clear sentence with no unnecessary words. Information is front-loaded and 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 the tool's simplicity (batch lookup by ID), the description covers the core action but lacks details on error handling, return format, and whether the operation is read-only. With no output schema, these gaps reduce completeness.

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

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

Schema description coverage is 0%, so the description must compensate. It adds the context that identifiers are used for batch lookup, but does not elaborate on the format of IDs or the nested structure. Some value added, but insufficient for full clarity.

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 looks up products or variants by identifier in batch, distinguishing it from sibling tools like search_catalog (query-based) and get_product (single item).

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

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

The description implies usage when identifiers are available, but lacks explicit guidance on when to use this tool versus alternatives like search_catalog or get_product. 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?

No annotations are provided, so the description carries the full burden. It explicitly discloses that no money moves on its own, the merchant approves first, the signer is the merchant's own non-custodial wallet, the amount is capped server-side, and the recipient is always the stamped payer. It also explains the receipt behavior and the required KYA identity requirement.

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 dense but every sentence earns its place. It front-loads the primary action and scope, then covers validation, money flow, ownership, and auth requirements without filler. Each clause contributes unique decision-relevant 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 is thorough for this complexity: scopes, side effects, auth, partial/full behavior, and approval flow are all present. It does not explicitly describe the return envelope or what an error looks like, and since no output schema exists, that small gap keeps it from a 5.

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?

Although the schema already covers all parameters, the description adds meaningful semantics beyond it: it explains why amount and recipient are absent, clarifies refund_line_itens for partial vs omit-for-full, and notes that receipt verification never gates the refund. This helps an agent understand the boundaries and intent of each 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?

The description names a specific verb and resource: request a refund or return on a DELIVERED order. It clearly scopes the tool to delivered orders, owner-scoped orders, and full-vs-partial refunds, which distinguishes it from cart and checkout lifecycle siblings.

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

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

The description gives strong selection signals: only delivered orders, only your own orders, partial vs full refund, and it even states what is NOT an input. It does not explicitly route the agent to alternative tools like cancel_cart or cancel_checkout for non-delivered orders, so it stops short of a perfect 5.

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 bear the full burden. It only states it searches, but does not disclose pagination behavior, return format, or any limitations or 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 a single sentence, concise and front-loaded. However, it is too brief for a tool with nested parameters and no output schema, making it less helpful.

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 nested input schema, no output schema, and no annotations, the description is severely incomplete. It omits pagination, sorting, result details, and any usage 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?

Schema description coverage is 0%, yet the description only mentions 'free-text query', partially explaining the query parameter. It does not explain pagination or the nested structure, leaving significant meaning missing.

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 searches the merchant catalog for products using a free-text query. It uses a specific verb and resource. However, it does not differentiate from the sibling 'lookup_catalog', so it loses the top score.

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 like lookup_catalog. No when-not-to-use or context provided.

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

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

With no annotations, the description carries the full behavioral disclosure burden. It effectively communicates that the operation is a full replacement (not append), that prices are recalculated server-side, and that owner identity on a signature-required terminal is mandatory. This goes beyond a basic mutation statement, though it could mention side effects like error conditions.

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, front-loaded sentence that states the action and follows with critical scoping/security caveats. 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?

The description covers the core purpose, replacement behavior, repricing, ownership scope, and authentication requirement. However, the schema allows omitting line_items, and the description does not clarify what happens in that case (e.g., clears the cart vs. no-op), which is a minor gap. No output schema is provided, so absence of return-value details is acceptable.

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

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

Schema description coverage is 100%, with both parameters clearly described. The description does not add parameter-specific meaning beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb and resource: 'Replace a cart's line items (full replacement), re-priced server-side.' It also distinguishes itself from siblings like get_cart or create_cart by emphasizing full replacement and server-side repricing.

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 clear contextual prerequisites: 'Owner-scoped' and 'REQUIRES IDENTITY on a signature-required Terminal.' However, it does not explicitly name alternative tools or when not to use this tool, so it falls short of a 5.

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 discloses that this is a no-op, that the checkout is sealed at create, that it returns the session plus a note, and that it is owner-scoped. This goes beyond a simple 'update' and prevents misuse.

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 succinct sentences: first states the core function, second explains the behavior and alternative. Every word earns its place, with no redundancy or padding.

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 tool with no output schema and no annotations, this description covers the essential aspects: what it does, its no-op nature, the alternative workflow, and ownership scope. Nothing important is missing.

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 already fully describes the only parameter (id) with 100% coverage. The description adds owner-scoped context but does not add additional meaning about the id parameter itself, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Return' and the specific resource 'checkout's CURRENT sealed snapshot', and explicitly differentiates from sibling tools by explaining it's a no-op and directing users to update_cart + create_checkout for changes. Despite the misleading name, the purpose is 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 tells when to use this tool (to get the current sealed snapshot) and when not to (to change line items), naming the alternative workflow: update the cart and start a new checkout with create_checkout(cart_id). This provides clear guidance on alternatives.

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

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

With no annotations, the description fully carries the behavioral disclosure burden. It explicitly explains idempotency ('updates its note and keeps the original save time'), scoping ('Your wishlist', 'your own agent identity'), and authentication requirements ('REQUIRES IDENTITY: Facet KYA as `Authorization: Bearer <kya>`'). This goes well beyond a simple 'saves a product' statement.

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, information-dense sentences. Every sentence provides unique value: what it does, idempotency behavior, and auth requirement. No filler or repetition of schema details.

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 tool is simple, but the description covers all necessary operational context: purpose, side effects (idempotent note update), identity scope, and auth header. It doesn't explain return values, but no output schema exists and the mutation behavior is clear. Sibling tools provide additional context for alternatives.

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 semantic value by explaining idempotent behavior for repeated product_id submissions—specifically that the note updates while save time is preserved. This goes beyond the schema's basic field descriptions and helps the agent understand the net effect of calling the tool.

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+resource: 'Save a product to YOUR wishlist on this merchant for later.' It clearly distinguishes from sibling tools like wishlist_remove and wishlist_list by focusing on the add action with the purpose 'for later.'

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 clear context: it's scoped to the agent's own identity and requires a specific auth token. While it doesn't explicitly say 'use wishlist_remove instead' or list when-not-to-use, the sibling context and 'save for later' make the intended use obvious. No exclusions are given, but the identity requirement is a meaningful usage constraint.

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 the return ordering ('newest first'), isolation ('never see another agent's list'), and an authentication requirement ('REQUIRES IDENTITY: Facet KYA...'). This goes beyond a minimal description, though it omits details like potential errors or defaults.

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 long, with the first sentence efficiently packing verb, resource, scope, and ordering. The second sentence delivers a critical auth requirement without excess. Every word earns its place.

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

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

For a simple list tool with one optional parameter and no output schema, the description provides the essential context: what items are listed, scope, ordering, and authentication. Given the low complexity, this is fully sufficient for an agent to select and invoke the tool correctly.

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

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

The input schema covers 100% of the parameter documentation ('limit' → 'Max items to return'). The tool description adds no additional parameter semantics beyond what the schema already 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 uses a specific verb ('List') and clearly identifies the resource ('YOUR saved items (wishlist) on this merchant') and ordering ('newest first'). It also distinguishes from siblings by emphasizing user/agent scoping, which separates it from other list tools like list_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?

The description clearly states the tool returns the caller's own wishlist items and is scoped to the agent identity, indicating when it should be used. It does not explicitly mention alternatives or exceptions, but the scope is unambiguous enough to guide selection.

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 idempotency, the response behavior for absent items (removed:false), scope to the agent's own wishlist, and a hard requirement for identity via KYA token. Missing explicit statement about permanence of removal, but the verb 'remove' implies it. Good coverage for a simple 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 short, information-dense sentences. Each sentence earns its place: action+scope, idempotency behavior, identity requirement. No fluff or repetition.

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 one-parameter tool with no output schema, the description covers all essential aspects: what it does, scope, special behavior (idempotent, removed:false), and auth requirement. It's complete and self-contained.

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 already describes product_id as 'The product id to remove.' with 100% coverage. The description does not add extra parameter-level meaning beyond restating the purpose. Baseline 3 is appropriate since schema handles it fully.

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: 'Remove a product from YOUR wishlist on this merchant.' It uses a specific verb (remove) and resource (product from wishlist), and distinguishes itself from siblings like wishlist_add and wishlist_list by focusing on removal and scope.

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 noting it's scoped to 'YOUR wishlist' and 'your own agent identity,' which implies it's for removing items the agent added. It doesn't explicitly mention alternatives, but the idempotency note ('removing something not on your list succeeds') clarifies behavior in edge cases. Slight gap: no explicit 'use when...' but the action is unambiguous.

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