Fulfiller — print catalogue & quotes

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

Annotations only declare it is a non-read, non-destructive, closed-world write. The description adds substantial behavior the annotations cannot convey: prices are frozen at add time, promotions already deducted, totals are HT excluding VAT and shipping, and nothing is committed. The return-shape note ('renvoie le panier complet') closes the loop.

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?

Front-loaded with the action, then the critical caveats (not an order, HT pricing, frozen price), then a routing instruction. Dense but nearly every clause carries needed information; only the pricing-field mention slights toward restating output fields.

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

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

No output schema, and the description compensates by stating that the complete cart is returned so no follow-up get_cart is needed. Idempotent retry behavior is covered by the schema's idempotencyKey description. Adequate for a mutation tool with optional parameters.

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

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

Schema description coverage is 100% and the nested properties are already documented in rich detail (sku optionality, PRODUCT_AMBIGUOUS, quantity semantics, selection shape). The description mostly restates provenance (productId from search_products, sku facultatif) rather than adding new semantics, so the 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?

States a specific verb and resource ('Crée un panier anonyme') plus optional initial lines, and immediately disambiguates the concept from an order ('Un panier n'est PAS une commande'). An agent can distinguish this from get_cart/update_cart/delete_cart without opening a schema.

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?

Gives a concrete when-not ('n'appelez pas get_cart juste après'), points to the sibling that supplies productId (search_products), and hints at re-quoting via quote_product when volume changes. It does not explicitly say when to prefer this over update_cart, 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?

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds useful behavioral context beyond that: deletion is permanent, irreversible, and removes all cart lines. It does not cover permissions or error behavior, but the critical destructive scope is made explicit.

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 sentences, front-loaded with the irreversible effect and followed by the alternative. Every sentence earns its place with no redundant 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?

For a destructive one-parameter tool with full schema coverage and annotations covering safety, the description is complete enough. It communicates scope, irreversibility, and the correct alternative tool; no output schema is present, so return values need not be described.

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 cartId parameter is already fully documented, including UUID source and capability warning. The description adds no additional parameter semantics, which is acceptable given the high schema coverage baseline of 3.

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 verb and resource: 'Supprime DÉFINITIVEMENT un panier et toutes ses lignes.' It also distinguishes the tool from its sibling update_cart by naming the single-line alternative. An agent can immediately tell this is full-cart deletion, not line-level editing.

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 explicitly routes the agent to the correct sibling: 'Pour retirer une seule ligne, utilisez update_cart avec `remove`.' This gives a clear condition for using delete_cart (whole cart) versus update_cart (single line). No ambiguity remains.

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

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

Annotations already declare readOnlyHint/destructiveHint=false, but the description adds non-obvious behavior: the cart is frozen at add time with no re-quotation, and pricedAt/expiresAt signal price age. It does not cover failure modes (invalid cartId, hard-expired cart), so it is strong 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?

Dense but front-loaded: behavior (frozen prices) first, then routing guidance. Every clause carries information, though the second sentence packs several distinct ideas together, which costs a little readability.

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

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

With no output schema, the description usefully characterizes the return content (per-line pricedAt, expiresAt) and the read semantics. It omits error/edge behavior for invalid or fully expired carts, so it is near-complete rather than complete.

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

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

Schema description coverage is 100%, so cartId (capability/UUID) and display (UI card toggle) are already fully documented in the schema. The description adds no further parameter-level meaning, matching the baseline for full schema 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?

Starts with a specific verb+resource ('Renvoie le panier') and immediately scopes it as a read of a previously frozen cart. It explicitly distinguishes itself from create_cart and update_cart, so the agent can separate it from siblings without opening schemas.

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?

Gives explicit when-to-use ('plus tard dans la conversation, ou quand l’utilisateur demande à le revoir'), explicit when-not ('inutile juste après create_cart ou update_cart'), and names the alternative for stale prices ('re-cotez avec quote_product'). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safe-read profile is covered. The description adds genuine behavioral context beyond that: it discloses that option dependencies are NOT included and that `presets` are quotable as-is via `selection.preset`. Minor gap: no pagination/size hints, but for a single-product read that is not material.

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?

Front-loaded with the return content, then the when-to-call guidance, then the caveat about dependencies. Every sentence carries value, though the preset/dependency details make it denser than strictly minimal.

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?

There is no output schema, so the description must describe returns, which it does thoroughly (options, available values, presets). It also clarifies the relationship to validate_selection and quote_product, leaving nothing an agent needs to call this correctly.

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

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

Schema coverage is 100% and the single parameter's provenance (productId from search_products) is documented in the schema itself. The description adds no additional meaning to productId. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb (renvoie) and resource (options configurables d'un produit) with the concrete content returned (quantités, délais, valeurs, tailles) and their available values. It also distinguishes the tool from siblings by framing the product as a configuration space rather than a fixed SKU.

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

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

Explicitly says to call it BEFORE validate_selection or quote_product, naming both alternatives and the ordering condition. It even explains that validate_selection is the tool that reveals option dependencies, giving a clear handoff.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds genuine behavioral context: no pricing, stale embedded prices, videos live in `videos` not `images`, missing fields mean unset in the PIM, FAQ is rare, and exactly one argument must be supplied.

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?

Dense and front-loaded: the resource and payload lead, then usage, then pricing caveat, then the argument rule. Slightly long, but nearly every clause carries distinct, actionable information rather than filler.

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

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

There is no output schema, so the description must describe the return shape, and it does by enumerating the sheet sections and the field-absence semantics. An agent has everything needed to call it and interpret the result.

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 real value beyond the schema by stating the exclusivity rule ('Fournissez exactement un argument') that the schema itself does not express — all three params are optional with no oneOf constraint.

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?

States a specific verb+resource and enumerates the exact payload (PIM sheet: descriptions, key points, FAQ, file constraints, resources). It also explicitly distinguishes itself from quote_product and corrects a common confusion (prices appear in text but are stale).

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?

Gives explicit when-to-use ('pour DÉCRIRE un produit ou aider à préparer un fichier') and when-not ('Ne renvoie aucun prix — pour coter, passez par quote_product'), naming the alternative and the condition that selects it. Also routes category-page lookups to 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?

Annotations already declare readOnly/destructive/openWorld, so safety is covered; the description goes further by naming the returned price field (devis.finalPriceHt, discount included), the per-tier error isolation (out-of-range tier errors locally without invalidating others), and the rounding rule where an out-of-step tier is quoted at the nearest orderable tier with quotedQuantity indicating the actual quantity. This is substantive behavioral detail beyond annotations, though it doesn't cover rate limits or pagination.

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?

Dense but front-loaded: the core capability and the answering use case come first, then the return field, then the error/rounding semantics. Every sentence carries information, though the density makes it less scannable.

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

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

With no output schema, the description usefully names the price path (devis.finalPriceHt) and explains quotedQuantity, covering the essentials of what comes back. The main uncovered area is the shape of the localized error response, but overall it is sufficient for correct invocation.

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

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

Schema description coverage is 100%, so productId, selection and quantities are already documented in the schema, with selection explicitly cross-referencing quote_product's selection form. The description adds no syntax or format detail beyond that baseline; the quantity-tier semantics it discusses are behavioral rather than parameter-level.

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?

States a specific verb and resource: a quote grid for multiple quantity tiers in a single call, with a concrete example question («combien pour 100, 250, 500 ?»). It references quote_product as sharing the same rule, which implies the distinction (single quote vs multi-tier grid) but doesn't state it directly, so differentiation from the sibling is by inference rather than explicit.

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 example question implies the usage context (comparing several quantities at once) and 'Même règle que quote_product' gestures at the sibling, but there is no explicit 'use this instead of quote_product when…' or when-not guidance. Usage is implied, not prescribed.

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?

Goes well beyond the readOnly/non-destructive annotations: it explains the price is computed live rather than table-looked-up, identifies the firm price field vs the catalogue price, explains promo strikethrough semantics, and describes the requiresReview branch where the quote applies to the resolved summary rather than the request. This is exactly the extra context annotations cannot carry.

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?

Front-loaded with the core claim (real firm price for a selection) and then focused on output-field interpretation. Dense but every sentence serves a purpose; no output schema exists, so the return-value guidance earns its space.

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

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

With no output schema, the description usefully documents the return surface (finalPriceHt, priceHt, promo, summary, requiresReview, status). For a nested, two-parameter quoting tool it is close to complete, though it omits error/alert handling detail (only alerts are mentioned).

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% and the schema itself is extremely detailed, so the baseline is 3. The description adds no parameter-level syntax or format guidance of its own, leaving the heavy lifting entirely to 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?

States a specific verb+resource (quote a selection) and specifies the price is a real, firm price computed by the pricing engine, never read from a SKU table. This implicitly separates it from softer-price siblings, but it never names quote_by_quantity or validate_selection, so sibling differentiation is left to inference.

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?

Usage is implied ('c'est le seul prix ferme', announce devis.finalPriceHt) rather than stated as when-to-use vs when-not. No explicit routing to quote_by_quantity or validate_selection, so the agent must infer which quoting path applies.

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

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context on top: the exact-vs-approximate resolution semantic, the single-argument constraint, and the shape of the result (productId, sku, nom, url). It does not cover failure modes (e.g. unknown SKU), which keeps it from a 5.

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 dense sentences, front-loaded with the transformation and result shape, followed by the routing rule and the invocation constraint. Every clause carries information; no filler.

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

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

A read-only resolver with no output schema; the description compensates by naming the returned fields, and annotations cover safety while the schema fully documents parameters. Nothing an agent needs to select or invoke it correctly 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?

With 100% schema coverage the baseline is 3, and each parameter is already documented in the schema. The description adds meaning beyond it by stating mutual exclusivity ('exactly one argument') and the provenance of each identifier (sku from-LD, url of the page, productId from search_products), which the schema does not express.

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?

States a specific verb and resource ('Convertit une identité EXACTE en identité complète') and enumerates both the accepted inputs (sku, url, productId) and the returned fields. It explicitly names and contrasts with the sibling search_products, so an agent can distinguish the two without opening either schema.

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?

Gives an explicit preference rule: 'À PRÉFÉRER à search_products dès que vous tenez l'un des trois', plus the reason (recherche approximative vs. exacte). It also states the invocation constraint ('Fournissez exactement un argument'), leaving nothing to inference.

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?

Far exceeds the annotations (which only cover the safe-read profile): it discloses the single automatic query relaxation and the relaxedQuery signal, the non-authoritative nature of startingPrice, the per-product basis variance (TOTAL/UNIT/PER_SQUARE_METER) with a rule against cross-basis comparison, and duplicate listings via alsoListedAs. These are response-shape behaviours not documented anywhere else, since there is no output 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?

Purpose and required entry-point status are front-loaded in the first two sentences; every subsequent clause targets a distinct pitfall (price semantics, basis mixing, duplicates). It is dense and reads as a wall of caveats, but nothing is redundant.

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

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

With no output schema, the description still covers the returned fields, their trust level, the basis-incomparability rule, the relaxation behaviour and duplicate handling — everything an agent needs to call it and interpret results correctly.

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

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

Schema description coverage is 100% and the q description already documents word-matching, ignored dimensions/quantities, the 3-letter rule and relaxation, so the description adds little parameter-level detail. It contributes only indirect guidance (use `startingPrice.displayLabel` when citing), so the baseline 3 for schema-carried parameters 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?

States a specific verb and resource (full-text search of the Fulfiller catalogue) plus what it returns (currently quotable products with productId, sku, url, startingPrice). It also positions itself against siblings by declaring itself the mandatory entry point for the productId-consuming tools and by contrasting its indicative startingPrice with quote_product's firm price.

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

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

Explicit routing: 'Point d’entrée obligatoire' tells the agent this must run first, and 'seul quote_product' directs firm pricing to the sibling. It also gives an exclusion-type instruction — do not present alsoListedAs entries as distinct products — and explains when the query gets relaxed.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is known; the description adds real behavioral value on top: deterministic sequencing of remove/update/add, that quantity updates do NOT re-quote (unit price frozen), that added lines ARE quoted at insertion, and that the response is the complete cart. It does not discuss failure/partial-application behavior or irreversibility beyond what the destructiveHint already implies.

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 tight sentences with no filler; the operational ordering constraint is front-loaded and the return-value/anti-get_cart note closes it. Every clause earns its place.

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

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

For a destructive multi-operation mutation with no output schema, the description supplies the essentials an agent needs: ordering, quoting semantics, and the fact that the full cart is returned. It stops short of describing error/partial-failure handling or concurrency, but given the fully documented schema and clear annotations the definition is functionally complete.

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

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

Schema description coverage is 100%, so the baseline is 3; the description goes further by attaching pricing semantics to the operations (updates reuse the frozen unit price, adds are quoted, and changing volume requires a re-quote then line replacement). That meaning is not derivable from the schema alone, though it does not cover lineId/limits specifics.

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 precise mutation (apply to cart) and enumerates the three sub-operations it performs in a fixed order (remove, update, add), each mapped to its actual parameter. It also distinguishes itself from the sibling get_cart by telling the agent the call already returns the full cart, so the agent can tell it apart from the other cart tools without opening a schema.

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

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

It gives explicit operational guidance: the order in which operations are applied and the instruction not to call get_cart immediately afterwards because the updated cart is returned. It does not, however, say when to prefer this tool over quote_product/quote_by_quantity for pricing a change, nor any prerequisite about the cart needing to exist, so a small gap remains.

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

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

Annotations only cover the safety profile (readOnly, non-destructive, closed-world); the description adds substantial non-obvious behavior: it does not return prices, and it explains the meaning of requiresReview=true, alerts, status per option, and enabledOptions as the place where cross-option dependencies are read. With no output schema, this disclosure is exactly what the agent needs.

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?

Dense but front-loaded: the purpose and the price exclusion come first, then the return-field semantics. Every sentence carries information, though the back half is somewhat packed with field names in a single breath.

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 nested-input tool with no output schema, the description explains the key return fields (summary, status, requiresReview, alerts, enabledOptions) and the cross-option dependency concept, which is strong. It does not fully enumerate the response shape, so not quite complete, but 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 coverage is 100%, including a description tying `selection` to quote_product's shape, so the schema already carries the parameter burden. The description adds conceptual framing (a tolerant selection to be corrected) but no syntax or format detail beyond the schema, matching the baseline 3.

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?

States a specific compound action (resolve a tolerant selection into canonical codes and verify its orderability) and explicitly scopes it against the sibling quote_product by stating it returns no price and is meant to precede quoting. An agent can distinguish this validation step from quoting without opening any schema.

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?

Names the context of use clearly ('to correct a selection before quoting it'), which implicitly routes the agent to run this before quote_product. There is no explicit when-not-to-use or named exclusion, so it stops short of a full 5.

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