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

Annotations declare readOnlyHint=false and destructiveHint=false, so safety is covered. The description adds a genuinely useful behavioral fact beyond that: free-text items carry no quantity field, so amounts must be embedded in the text. It does not state auth requirements or reversibility, but for a simple list add that is minor.

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 core action and the sibling distinction, followed by usage examples and one formatting constraint. 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?

For a one-parameter, non-destructive add with no output schema, the description covers what it does, when to use it, and how to format input. It omits only an auth prerequisite (a sibling ah_login exists), which is a small residual gap.

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

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

Schema coverage is 100%, so baseline would be 3, but the description adds real meaning: the single 'name' parameter must absorb quantity information as prose ('2 bossen bloemen'), which the schema does not convey. This materially changes how the agent should format the argument.

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 ('Add a free-text item to the Albert Heijn shopping list') and immediately differentiates itself from the sibling ah_add_to_shopping_list with '(no product ID needed)'. An agent can pick this over the ID-based add 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 concrete when-to-use conditions: reminders, vague intents ('any good wine'), and items not found in search. The implicit alternative is the ID-based sibling, though it is never named explicitly, so routing relies on the reader inferring which tool handles product IDs.

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 declare readOnlyHint=false / destructiveHint=false, so the description carries real weight and delivers: the name-matching rule, the bonus tie-break default, that exactly one unit per product is added, water being silently skipped, dry_run behavior, and the four-way outcome classification (added, skipped, unmatched, search-failed, the last worth retrying). This is unusually rich behavioral disclosure for a mutation tool.

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

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

Five short sentences, each carrying distinct information, with the primary action front-loaded and refinements (skip, dry_run, return shape, link formatting) following in priority order. No filler or restatement of the title.

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

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

Despite a moderate-complexity mutation with five parameters, the description covers matching logic, skip semantics, dry-run preview, and outcome categories, and even flags failed searches as retryable. An output schema exists so return-shape detail is optional, and the description's brief mention of it is a bonus rather than a necessity.

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, but the description goes beyond the schema by explaining the tie-break semantics behind prefer_bonus ('among equally good matches, one on bonus unless prefer_bonus=false'), the intended content of skip, and the purpose of dry_run. It does not touch 'servings' beyond the schema's own cross-reference to ah_get_recipe.

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 ('Put the ingredients of an Allerhande recipe on the shopping list') plus the key scope qualifier 'in one step', which separates it from ah_add_to_shopping_list (single product) and ah_add_free_text_to_shopping_list. An agent can identify the tool's role without opening the 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 clear when-to-use context and explicit exclusions: water is always skipped, and the user should pass 'skip' for anything they already have, with concrete examples (olive oil, salt). It also explains the dry_run preview path. It stops short of naming a sibling alternative for non-recipe additions, so it is a strong 4 rather than 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation profile is covered. The description adds no behavioral context beyond that — nothing about authentication requirements, duplicate-item behavior, or whether existing list contents are preserved. It essentially restates what the schema already documents.

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, front-loaded with the action and scoped by the prerequisite hint. No filler, no redundancy in phrasing.

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 exists, so the description could usefully say what a successful add returns (or whether it is idempotent), but it does not. For a two-parameter write tool whose params are fully documented, the definition is minimally viable 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% and the items parameter even carries an inline example and the quantity-0 rule, so the schema does the heavy lifting. The description's 'Get list_id from ah_get_favorite_lists' merely repeats the list_id schema description verbatim, adding no new syntax or constraint information.

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

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

States a specific verb ('Add') and resource ('products to a named Albert Heijn favorite list'), which is enough to separate it from the shopping-list siblings by the word 'favorite'. It stops short of explicitly contrasting itself with ah_add_to_shopping_list or ah_add_free_text_to_shopping_list, so the differentiation is inferred rather than stated.

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 workflow prerequisite: get list_id from ah_get_favorite_lists, naming the sibling that supplies it. There is no explicit statement of when to prefer this over the shopping-list add tools, but the context is clear enough to act on.

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=false, covering the safety profile. The description adds genuine value by disclosing the return behavior ('confirmation listing the names of successfully added products'), which matters since no output schema exists, but says nothing about auth requirements, quantity limits, or failure handling for invalid product IDs.

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 tight sentences: purpose, input shape, and return value, with the core action front-loaded. No filler or redundancy.

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

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

For a single-parameter tool with full schema coverage, the description covers purpose, input shape, and return value, compensating for the absent output schema. It stops short of explaining mutation side effects or edge-case behavior, but nothing essential to a correct call 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?

Schema description coverage is 100%, so both product_id and quantity are already documented, including an inline array example. The description restates the same structure ('array of items, each with product_id (int) and quantity (int)') without adding syntax, constraints, or meaning beyond the schema — 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 states a specific verb (add) and resource (Albert Heijn shopping list) with the batch scope made explicit ('one or more products'). It does not, however, differentiate itself from siblings such as ah_add_free_text_to_shopping_list or ah_add_to_favorite_list, so an agent must infer which add-variant applies.

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 by the purpose statement — an agent can tell this is for adding products by product_id — but there is no explicit when-to-use guidance, no exclusion, and no pointer to the free-text or favorite-list alternatives among the many siblings.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds genuinely useful context beyond that: the operation is irreversible and guarded by a confirm="yes" requirement to prevent accidental wholesale clearing. It does not say what the order looks like after clearing, but that gap is minor.

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

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

Two tightly packed clauses, front-loaded with the destructive verb and scope, then the safety guard. No filler; every phrase carries routing or safety information.

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

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

For a single-parameter destructive mutation with no output schema and annotations covering the safety hints, the description supplies the remaining essentials: exact scope, irreversibility, and the confirmation guard.

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 only one parameter exists, so the schema already documents 'confirm' fully. The description repeats the confirm="yes" requirement and adds intent ('to prevent accidental use'), which adds light value but does not exceed the structured 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?

States a specific verb and scope: 'Remove ALL items from the active Albert Heijn delivery order (not the shopping list).' The explicit negative scope cleanly separates it from the sibling ah_clear_shopping_list, so an agent can route correctly 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?

The description clarifies the target (active delivery order, not shopping list), which is the key routing decision among siblings. It stops short of naming ah_clear_shopping_list or ah_remove_from_cart as alternatives for the case where only some items should go, so the exclusion is implicit rather than spelled out.

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 flag destructiveHint=true, but the description adds genuinely new information: the operation is irreversible and a confirm="yes" gate is mandatory. It stops short of describing what the response looks like after the clear.

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, zero filler, with the destructive scope front-loaded and the irreversibility/confirmation constraint immediately after it.

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 destructive tool with no output schema, the definition covers scope, irreversibility and the confirmation gate. Only the post-clear state (e.g. whether the list is emptied vs deleted) is left unstated.

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?

Only one parameter and schema description coverage is 100% — the schema already states 'Must be "yes" to confirm', and the description merely restates the same constraint without adding format or edge-case detail. 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?

States a specific verb (Remove) and resource (Albert Heijn shopping list) with an explicit scope quantifier (ALL items), which cleanly separates it from the sibling ah_remove_from_shopping_list that handles individual items.

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 by the scope (use when the whole list should be emptied) and the confirm="yes" prerequisite gives a concrete condition, but no alternative is named and no when-not guidance is offered.

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 declare readOnlyHint=false and destructiveHint=false, so the description carries most of the burden and does so well: it discloses that the created list is empty, warns that AH silently drops punctuation such as '-', and names the follow-up tool. It stops short of describing whether the id is returned in a wrapper object or listing other 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?

One compact sentence pair with the creation action front-loaded, then the normalization caveat, then the follow-up tool. No filler, and ordering follows the agent's decision path.

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 create tool with an output schema already covering the return value (the id), the description covers what it is, the empty-state behavior, the naming quirk, and the next step. Nothing an agent needs to 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?

Schema coverage is 100% for the single required 'name' parameter, so the baseline would be 3. The description goes beyond the schema by explaining that the name value is normalized server-side (punctuation like '-' is dropped), which is semantics an agent cannot get from the schema alone.

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 ('Create a new, empty Albert Heijn favorite list') and scopes it to the given name. It is immediately distinguishable from siblings like ah_get_favorite_lists, ah_delete_favorite_list, and ah_add_to_favorite_list.

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 routes the agent to the next step: 'add products with ah_add_to_favorite_list,' which names the correct alternative tool for populating the list. It gives clear context for use but does not state prerequisites (e.g. login requirement) or any when-not condition.

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, so the safety profile is covered. The description adds genuine extra context beyond that: the operation is irreversible, it destroys everything on the list, and a confirm="yes" gate is required. No auth or rate-limit detail, so not 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 short sentences, zero waste, with the destructive scope and irreversibility front-loaded ahead of the procedural 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?

For a two-parameter destructive tool with no output schema, everything an agent needs is present: what is deleted, that it is irreversible, the confirmation gate, and the source of the ID.

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 nonetheless adds meaning: it identifies where list_id originates (ah_get_favorite_lists) and reinforces the exact confirm value, which is more than the schema alone conveys.

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

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

Specific verb+resource ('Delete an Albert Heijn favorite list') with explicit scope ('and everything on it'), which clearly distinguishes it from the sibling ah_remove_from_favorite_list that removes individual items. An agent can select this without opening the 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 the prerequisite that list_id comes from ah_get_favorite_lists and states the confirm="yes" requirement, which is clear usage context. It does not explicitly state when-not to use it versus siblings like ah_clear_shopping_list, 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: it says the payload matches ah_search_products fields and instructs the agent to link a returned product/recipe name to its url when mentioning it. A slight gap remains in that return shape is deferred to another tool rather than described, but with an output schema present this is minor.

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?

Five short sentences, front-loaded with the core purpose, then the workflow linkage, then the output convention. Each sentence carries distinct information, though the trailing url-linking instruction is a formatting convention rather than tool mechanics and could be trimmed.

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 two-parameter read tool with an output schema and readOnlyHint annotation, the description covers purpose, parameter sourcing, the next-week edge case, and return-field expectations. An agent has everything needed to call it correctly on the first attempt.

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 already documents both parameters, including the enum values for period and the origin of segment_id. The description's parameter notes ('set period=next for next week's bonus', 'get segment_id from bonus_segment_id') largely restate 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 states a specific verb (Get) and resource (individual products in a bonus promotion group), and immediately contrasts it with the aggregate view by telling the agent it is for drilling into a deal like '2+1 gratis kaas'. This clearly distinguishes it from ah_get_bonus_offers and ah_search_products 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?

It gives explicit when-to-use guidance ('drill into a deal'), tells the agent exactly where the required segment_id comes from (the bonus_segment_id field of ah_get_bonus_offers results), and covers the edge case of next week's promotion with period='next'. Nothing about tool selection 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 only declare readOnlyHint, so the description carries the useful behavioral load: default period is the current week, period='next' data is published a few days before the bonus week begins, and group deals lack an id but expose a bonus_segment_id. These are non-obvious traits an agent could not infer from the schema or annotations.

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

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

Well front-loaded: purpose first, then disambiguation, then parameter nuances, then return fields and the linking instruction. It is dense and mostly earns its length, though the enumerated return fields and the url-linking instruction add bulk that a tighter description could shed.

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 an output schema exists, return values need not be restated, yet the tool's behavior, filtering options, week semantics, and the hand-off to the group-products sibling are all covered. Nothing needed to 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?

Schema coverage is 100%, so baseline is 3, but the description adds domain meaning: period='next' timing semantics, a concrete Dutch query example ('kaas'), and the AH-specific label 'Eerder gekocht' for previously_bought. It does not add syntax beyond the schema, hence 4 rather than 5.

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 ('Get Albert Heijn bonus/promotional offers') and immediately distinguishes itself from ah_search_products. The scope (weekly bonus offers, group vs single deals) is precise enough that an agent can choose it without opening the 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?

Explicitly names the tool NOT to use ('not ah_search_products') and the trigger condition ('what is on bonus/sale/discount'). It also routes the agent onward to ah_get_bonus_group_products with the exact condition (group deals carrying a bonus_segment_id but no id). Both alternatives and their selecting conditions are stated.

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

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

readOnlyHint already covers safety, and the description adds real behavioral content: the payload contains order state, item names/quantities, total price and total discount, plus an instruction to hyperlink product/recipe names to their urls. It doesn't cover edge cases such as an empty or expired cart, but against annotation coverage this is solid.

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

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

Three sentences, front-loaded with the core action and scoped with the sibling alternative. The return-value enumeration and the url-linking instruction are marginally beyond what this tool needs, but nothing is wasted or buried.

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?

Zero parameters plus an existing output schema means the remaining burden is selection and expectation-setting, and the description covers both: when a cart exists, what it contains, and how to reference items in the reply. Nothing an agent needs to call 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?

There are zero parameters, so the schema has nothing for the description to annotate; the baseline for a no-arg tool is 4. The description correctly adds no invented parameter semantics.

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

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

Specific verb+resource ('View the items in the active Albert Heijn delivery order') with the scope clarified as the order cart after slot selection. It explicitly distinguishes itself from the shopping list, which is the most likely sibling to confuse it with, so an agent can select correctly 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?

States the precondition for an order existing (a delivery or pick-up slot must be chosen) and names the alternative tool (ah_get_shopping_list) for the pre-slot period. This is explicit when-to-use/when-to-use-else guidance rather than 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, so the safety profile is covered. The description adds genuine value beyond that: Dutch time zone, the fact that this only shows availability (no booking side effects), and a sample return format ('15:00-17:00').

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 tight sentences, each earning its place: purpose first, the booking constraint second, and return format last. No redundancy or filler.

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

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

For a low-complexity, single-optional-parameter read tool with an output schema covering return values and annotations covering safety, the description supplies everything an agent needs (what it lists, what it cannot do, and the shape of 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?

Schema description coverage is 100%, so the single 'days' parameter (including its default of 7) is already fully documented in the schema. The description adds only implicit time-zone framing ('per day', 'Dutch time') and no syntax beyond what the schema provides, so baseline 3 is correct.

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 (List) and resource (delivery time windows), plus scope (at the member's address, per day, Dutch time). No sibling tool covers delivery slots, and an agent can immediately tell this apart from cart/order/product tools.

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

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

The description clarifies that booking is NOT possible through this tool and only happens in the AH app or on ah.nl, which is a useful exclusion guiding correct invocation. It does not name alternative sibling tools, but none exist for this domain, so 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?

The readOnlyHint=true annotation already establishes that this is a safe read operation. The description adds that returned IDs can be used with the add/remove/delete favorite-list tools and summarizes the returned fields, but it does not disclose pagination behavior, authentication needs, or rate limits.

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, front-loaded with the tool's purpose and followed by the single actionable next step. No filler or redundant wording.

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 zero-parameter read-only tool with an output schema and readOnlyHint, the description covers purpose and follow-up routing completely. Return value details are appropriately left to the output schema.

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

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

There are zero parameters and schema description coverage is 100%, so the description correctly does not need to explain parameter semantics. Baseline for a no-parameter tool is 4.

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 ('List all Albert Heijn favorite/saved shopping lists') plus the returned fields (names and item counts), which lets an agent distinguish it from the singular ah_get_shopping_list. It also names the downstream tools that consume the returned list IDs.

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 clear context for what the tool is for and what to do with the returned list IDs, but never states when to choose it over ah_get_shopping_list or any prerequisite such as an authenticated session. No explicit when-not guidance or exclusions are 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 readOnlyHint=true already declaring safety, the description adds substantial value by disclosing the internal algorithm (fetching fulfillments, expanding items, counting) and the exact output fields (product_name, product_id, order_count, last_ordered_date). It also includes a specific post-processing instruction about linking product names to URLs, which is behavioral context not present in annotations.

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

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

The description is a single, dense sentence that front-loads the core purpose and then details the mechanism and output. It is efficient with no wasted words, though the post-processing instruction could be separated for better clarity.

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

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

Given the presence of an output schema, the description need not explain return values, but it does specify the exact fields returned. It also covers the computation method and provides a linking guideline, making it complete for an agent to understand the tool's behavior and usage.

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

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

Schema coverage is 100% and the single parameter (min_order_count) is fully documented in the schema with its default value. The description mentions the threshold behavior but does not add syntax or format details beyond what the schema provides, fitting the baseline of 3 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?

The description uses a specific verb ('Get frequently ordered products') and explains the underlying mechanism (analysing order history, expanding fulfillments, counting per product). It clearly distinguishes this from siblings like ah_get_orders or ah_get_products by focusing on aggregated frequency.

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 through the min_order_count threshold explanation, which clarifies the filtering behavior. However, it does not explicitly state when to prefer this tool over alternatives like ah_get_favorite_lists or ah_search_products, leaving the agent to infer the 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?

Annotations already declare readOnlyHint=true, and the description adds meaningful context beyond that: the dedicated bargainItems GraphQL endpoint and the 'today-only' time-scoped nature of the results. Auth/rate-limit behavior is not mentioned, but the safety profile is well covered.

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 is front-loaded, followed by prerequisite and data-source details. The trailing instruction about linking product/recipe names to their urls is a useful output-handling note, though it is somewhat tangential to tool selection.

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 an output schema present, return-value explanation is unnecessary, and the description covers data source, time scoping, and prerequisites. It is nearly complete for a read-only lookup, missing only auth/rate-limit 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 coverage is 100%, but the description adds value beyond it by clarifying the actual requirement (a store_id is needed) and the relationship between store_id and postal_code as primary vs. fallback inputs, information the schema leaves unstated with 0 required parameters.

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 ('Get last-chance / vandaag-af / clearance items from an Albert Heijn store') with clear domain scoping. It implicitly distinguishes itself from ah_get_bonus_offers by emphasizing 'today-only markdown deals', but does not explicitly name sibling tools to sharpen the boundary.

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 routing: requires store_id and directs the agent to ah_search_stores, or offers postal_code as an alternative when the store is unknown. This clearly names the helper tool and the fallback condition, though it does not contrast this tool against related offer/inventory tools.

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

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

Annotations already declare readOnlyHint=true, so the safe-read profile is covered; the description adds genuine behavioral value by disclosing that email is masked and bonus_card_number is truncated to the last 4 digits. It still doesn't state the authentication requirement, which is relevant for a member-specific tool.

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

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

Two short sentences, front-loaded with the action, with the return payload summarized second. Every clause carries information and nothing is padded.

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?

An output schema exists, so the description is not obliged to enumerate return values, yet it gives a useful précis of the payload. For a zero-parameter, read-only tool this is close to complete; the only omission is the authentication precondition.

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 tool takes zero parameters and the description correctly introduces no invented inputs, leaving nothing to misinterpret. The baseline for a no-parameter tool is 4 since there is no parameter semantics to add.

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 ("Get your Albert Heijn member profile") and further scopes it by describing exactly which fields come back. No sibling tool in the list covers member profile retrieval, so the purpose is unambiguous without needing explicit differentiation.

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 only implied: an agent can infer this is the tool for 'who am I / my loyalty details', and there is no competing sibling for that need. However, the description never states when to call it (e.g., after ah_login, only for authenticated users) or any preconditions, so it stays at the minimum-viable level.

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, so the safety profile is covered. The description adds value beyond that by disclosing the return contents (products with names, quantities, prices) and an output-handling convention: link product/recipe names to their url when mentioned. It stops short of noting empty orders or failure modes.

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, each earning its place: what it does, what it returns, how to source the ID, and how to render the result. The core purpose is front-loaded and there is 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?

An output schema exists, so return-value structure need not be explained, and readOnlyHint covers safety. The description supplies the remaining context an agent needs: parameter provenance and the linking convention. Minor gaps (empty/nonexistent order handling) keep 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?

Schema description coverage is 100% and the single order_id parameter is already documented as 'Numeric order ID from ah_get_orders'. The description's provenance note largely restates the schema, so per the baseline rule a 3 is appropriate even though it is not misleading.

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 ('Get the full item list for a specific Albert Heijn delivery order by its ID') and immediately clarifies the granularity, distinguishing it from the sibling ah_get_orders which lists orders rather than their line items. An agent can tell them apart 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 prerequisite chain: 'Get order_id from ah_get_orders', which tells the agent this tool must be preceded by the list tool and how to obtain the required parameter. It does not state any when-not conditions or error behavior, but the routing 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?

readOnlyHint=true is already supplied, so safety is covered. The description adds meaningful behavior: the default result set is upcoming orders, past=true flips it, and the response shape (id, date, time_window, total_price, status) is disclosed. The phrase 'with a modifiable flag' is vague, but the semantics of the flag are clarified by 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?

Three compact sentences, front-loaded with purpose and default behavior, then the flag, then the hand-off to the detail tool. No filler 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?

An output schema exists, so enumerating return fields in prose is optional, but everything an agent needs to invoke the tool correctly is present: default scope, the past flag, and the next-step routing. No gaps remain for a two-optional-parameter list tool.

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

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

Schema description coverage is 100%, so both parameters are documented structurally; baseline is 3. The description reinforces the meaning of past by contrasting upcoming vs delivered orders and notes the default upcoming scope, but adds no format, units, or edge-case detail 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?

States a specific verb and resource ('List Albert Heijn online delivery orders') and immediately scopes it to two modes (upcoming by default, delivered with past=true). An agent can distinguish this from ah_get_order_details, which is explicitly named as the drill-down sibling.

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 clear context: default is upcoming orders, and past=true switches to delivered orders. It also routes the agent forward ('Use the returned id with ah_get_order_details'), which is exactly the follow-up guidance an agent needs. It stops short of stating when *not* to use this tool or when to prefer another listing alternative.

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?

readOnlyHint=true already establishes the safety profile, and the description adds real value by disclosing that the return shape matches ah_search_products, so the agent knows the output contract without opening the schema. It also relays a link-formatting requirement for presenting results, though it says nothing about result counts 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?

Three tight sentences, front-loaded with the core purpose, then usage scenarios, then output/format guidance. No filler and nothing buried.

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 annotations covering the read-only safety profile, a full output schema, and 100% param coverage, the description is nearly self-sufficient. The one nuance it could add is whether an empty alternatives list is possible, but nothing essential 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?

Schema description coverage is 100%: product_id's provenance (from ah_search_products or ah_get_shopping_list) and the limit default/max are fully documented in the schema. The description adds nothing beyond this, 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?

States a specific verb and resource ('Get products Albert Heijn suggests instead of a given product') and sharpens the scope with 'similar products and substitutes'. An agent immediately understands this returns recommendation alternatives rather than search results.

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

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

Gives concrete triggering scenarios ('when it is sold out or to find a cheaper or organic option'), which frames when to reach for this over ah_search_products. It stops short of explicitly naming ah_search_products as the alternative to use for direct lookups.

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?

readOnlyHint=true already establishes the safety profile, and the description adds useful context: the batch cap of 20, the fields returned, and the include_nutritional_info switch. It omits auth requirements and failure behavior for unknown IDs, so it is solid 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?

Three front-loaded sentences that lead with the verb, resource, and cap before the optional flag and the linking instruction. The final sentence about linking product names to URLs is behaviorally useful but slightly tangential to invocation.

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?

An output schema exists, so return values need not be explained, yet the description still summarizes them helpfully. With only two parameters, both covered, and readOnlyHint present, the definition is complete enough to invoke 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%, so the baseline is 3. The description restates the max-20 limit (already in the schema) and paraphrases include_nutritional_info ('also return calories, fat, protein, etc.'), adding only marginal meaning beyond the structured fields.

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 ('Get detailed information about one or more Albert Heijn products by ID') with scope (max 20) and enumerates the returned fields. It is clearly distinguishable from siblings like ah_search_products and ah_get_product_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 routes the agent to ah_search_products as the source of product IDs, which is a genuine usage precondition. It does not, however, say when to prefer this over ah_get_product_alternatives or other product-related siblings, so it falls short of full when/when-not guidance.

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

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

Annotations declare readOnlyHint=true, so safety is already covered, but the description adds substantive content: the returned payload (items with name, quantity, unit price, line total, discounts, payment method) and the prerequisite that the id must originate from ah_get_receipts. No mention of auth or error behavior for a missing/invalid id, which keeps it short of 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?

Three sentences, zero filler: purpose, payload, and prerequisite in that order. The id-source instruction is front-loaded as the final actionable sentence where an agent will read it last before calling.

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 a full output schema and readOnly annotation, the description supplies everything needed: what it fetches, what comes back, and where the id comes from. Nothing required for correct invocation 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?

Schema description coverage is 100% and the single 'id' parameter is already documented as 'Receipt transaction ID from ah_get_receipts', which the description largely repeats. No added format, example, or validation semantics beyond the schema's own text.

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 ('Get full details of a single ... in-store receipt (kassabon) by its id'), scoped to the in-store receipt domain. This distinguishes it cleanly from ah_get_receipts (the list) and ah_get_order_details (orders, not kassabonnen).

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 routes the agent: 'Get the id from ah_get_receipts first,' which establishes the required call ordering. It does not, however, state when to prefer ah_get_order_details for online orders versus this tool, leaving one sibling boundary 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?

readOnlyHint=true already establishes the safe-read profile, so the description's added value is the disclosure of returned fields (id, date, total) and the implicit 'recent' scoping. It says nothing about pagination, ordering, how 'recent' is bounded, or whether authentication via ah_login is required, which is a meaningful gap for a listing tool.

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

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

Two tight sentences with zero filler, front-loading what the tool returns before the pointer to the detail sibling.

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?

An output schema exists, so return values need not be elaborated, and the description is sufficient for a simple one-optional-param list tool. The only omission is any mention of auth prerequisites given the presence of ah_login/ah_logout siblings.

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 single 'limit' parameter is fully documented in the schema with its default, so the baseline of 3 applies. The description adds no additional semantics about the limit.

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 ('List recent Albert Heijn in-store receipts'), including the Dutch term kassabonnen, and explicitly distinguishes itself from ah_get_receipt_details by noting that this tool returns only summary fields while the sibling returns items.

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 routes the agent to ah_get_receipt_details 'with the id to see individual items', which is a clear next-step condition. It stops short of the full 5 because it never clarifies the boundary against ah_get_orders, a sibling an agent could plausibly confuse with receipts.

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 declare readOnlyHint=true; the description adds the servings-scaling behavior, the shape of the returned data, and a post-retrieval linking convention for urls. No auth or rate-limit notes, but for a read-only lookup this is solid added context.

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

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

Three short sentences, each load-bearing: what is returned, how to scale it, and what to do next. The core purpose is front-loaded before the workflow advice.

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?

An output schema exists, so return-value documentation is not required, yet the description still names the returned sections. Combined with the scaling note and the shopping workflow, an agent has everything needed to call it 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%, so both parameters are already documented, including that recipe_id comes from ah_search_recipes. The description's note on servings scaling restates the schema's own wording rather than adding new semantics, 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?

States a specific verb (Get) and resource (Allerhande recipe by id) and enumerates the payload: ingredients, preparation steps, and nutrition per serving. It is clearly distinguishable from the sibling ah_search_recipes, which only finds ids.

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 context for two behaviors: set servings to scale quantities, and use ah_search_products plus ah_add_to_shopping_list to shop for the ingredients. It does not mention the more direct sibling ah_add_recipe_to_shopping_list, so the routing advice is helpful but not exhaustive.

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?

readOnlyHint=true is already declared in annotations, so safety is covered structurally; the description adds lifecycle behavior annotations cannot convey (the list is consumed by slot selection and returns only after the order completes). The one omission is any note on auth/prerequisite state, though ah_login siblings make that largely implicit.

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

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

Four short sentences, front-loaded with purpose, then lifecycle, then return shape, then the linking instruction. Every sentence carries actionable information and none restates structured 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?

Although an output schema exists, the description still tells the agent what the items contain and gives a post-call formatting requirement (link product/recipe names to their url), which is guidance the schema cannot express. The lifecycle caveat closes the main behavioral gap.

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

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

Zero parameters, so per the rubric the baseline is 4; there are no arguments whose semantics need explaining. The description's mention of returned item names/quantities/product IDs is output information, not parameter semantics, so it neither helps nor hurts here.

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

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

Specific verb ('Get') plus the exact resource ('contents of the Albert Heijn shopping list'), with a native-language gloss (boodschappenlijst) that removes ambiguity. It also implicitly distinguishes itself from ah_get_cart by naming that sibling, so an agent can separate the two list-like tools.

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

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

Explicitly states the condition under which this tool is NOT usable ('after a delivery slot is chosen... the list is unavailable') and names the alternative to use instead ('use ah_get_cart then'). That is a clear when-to-use/when-not/alternative triple.

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 annotations only declaring readOnlyHint=false and destructiveHint=false, the description carries the real behavioral burden and does so well: codes are single-use, expire quickly, and an already-authenticated session returns the account name. It doesn't mention session lifetime, token storage, or what happens on an expired/invalid code, which keeps it short of 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 numbered steps plus two short trailing sentences; the flow is front-loaded and every sentence (expiry, already-logged-in behavior) carries distinct, actionable 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?

There is no output schema, so the description must describe returns, and it does: a login link plus instructions on the first call and the account name when already logged in. For a one-optional-parameter auth tool this is 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% and the single `code` parameter is fully documented there, so baseline is 3. The description restates that the full link or just the code is accepted and that omitting it starts a login, adding no semantics 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?

States a specific verb and resource ('Log in to Albert Heijn') and immediately distinguishes itself from siblings by describing the two-step flow unique to this tool. An agent can tell it apart from ah_logout and the shopping-list 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?

Explicitly says when to call with no arguments (to start) and when to call with `code` (to finish after the user logs in), including the exact redirect shape to look for. It also covers the already-logged-in case, 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?

Annotations already flag destructiveHint=true, and the description reinforces this by naming what is destroyed (stored tokens) and the post-condition (must re-authenticate). It does not state whether the server-side session is invalidated or whether any local data beyond tokens is affected, leaving a small gap.

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

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

Three short sentences, front-loaded with the core action and mechanism, followed by usage and the recovery step. Every sentence carries distinct information with 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?

For a zero-parameter, no-output-schema tool whose safety profile is already covered by annotations, the description supplies everything needed: mechanism, use cases, and the next call to make.

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 tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies the action is unconditional and needs no arguments.

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 (log out) plus the resource/mechanism (deleting stored tokens), and implicitly contrasts with the ah_login sibling. An agent can tell exactly what this does 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?

Explicitly names two triggering scenarios (switch accounts, reset a broken session) and the required follow-up (call ah_login to re-authenticate). Nothing about when to use it 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=false and destructiveHint=true, so the agent knows this mutates state. The description reinforces the single-item scope (versus ah_clear_cart) but says nothing about idempotency, behavior when the product is not in the cart, or whether the cart total recalculates. Adequate but not rich given the annotations carry the safety profile.

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, zero filler. The primary action is front-loaded, with source and alternative following in descending priority.

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 mutation with no output schema and annotations that already declare destructiveness, the description covers purpose, scope, input provenance, and sibling routing. Nothing an agent needs to invoke it correctly is absent.

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, but the description adds real value by stating where product_id comes from (ah_get_cart) rather than just describing its type. That provenance guidance is the only semantic detail an agent could get wrong here.

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

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

Specific verb+resource ('Remove a single product from the active Albert Heijn delivery order') with an explicit scope qualifier ('single', 'active ... order'). It cleanly separates this tool from ah_remove_from_shopping_list and ah_clear_cart without the agent needing to open 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 upstream data source ('Use product_id from ah_get_cart') and routes the agent to the correct sibling when the target is the shopping list rather than the cart. Both the when-to-use and the alternative are stated explicitly.

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 mutation profile is covered by structured data. The description adds the identifier-provenance requirement but says nothing about permanence, list lifecycle when emptied, or failure behavior for non-member products, which would be valuable context for a destructive 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?

Two tight sentences with zero filler; the operation is front-loaded and the dependency hint follows immediately. Nothing is redundant or padded.

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 two-parameter, fully-required, fully-documented mutation whose safety profile is carried by annotations, the description is sufficient to invoke correctly. Minor gaps remain around outcome/error semantics and whether removal is reversible, but nothing essential 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?

Schema description coverage is 100% with both parameters documented in-schema, so the baseline is 3. The description's mention of list_id provenance largely restates the schema's own description, adding no new syntax or constraint detail for product_ids.

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 ("Remove products from a named Albert Heijn favorite list"), which an agent can immediately distinguish from the sibling ah_add_to_favorite_list and from ah_remove_from_shopping_list (different resource: shopping list vs favorite list). The scope (products, named list) is precise.

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 gives the prerequisite lookup path: "Get list_id from ah_get_favorite_lists," which routes the agent to the right sibling for the identifier. It does not state any when-not conditions or error cases (e.g. product not in list), so it falls 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.

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the mutation/removal risk is covered structurally. The description adds the two-mode removal model but says nothing about reversibility, behavior when an item is not on the list, or partial-failure handling, so it goes only modestly beyond the annotations.

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

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

Three short sentences, front-loaded with the action and resource, then the mode-selection rule, then the discovery pointer. No filler 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?

With no output schema and two fully described optional parameters, the description covers both invocation paths and where to obtain IDs, which is sufficient to call the tool correctly. It is slightly thin on outcome/error behavior for a destructive operation.

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 descriptions already explain 'use for product items' vs 'use for items without a product ID', so the description's guidance largely restates it. It does add the pointer to ah_get_shopping_list as the source of product_ids, which is minor value over 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 (Remove) plus resource (items in the Albert Heijn Boodschappenlijst) and explicitly scopes it to one-or-more items. This clearly separates it from ah_clear_shopping_list (remove all), ah_add_to_shopping_list, and the similarly named ah_remove_from_cart / ah_remove_from_favorite_list.

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 concrete routing rules: product items use product_ids, free-text items use names, and product_ids should come from ah_get_shopping_list. It does not, however, name the alternative for bulk removal (ah_clear_shopping_list), so the when-not case 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 only declare readOnlyHint=true, so the description usefully adds the max-10-query constraint, the default limit behavior, the promotion-only toggle, and a per-query result field list plus a presentation instruction (link product names to their url). It adds real context beyond the safe-read annotation, though it doesn't cover pagination or failure 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?

Front-loaded with purpose and the usage-critical details first. It is somewhat long, and enumerating all 23 filter values duplicates the schema enum rather than only paraphrasing categories, which is mild redundancy.

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

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

With an output schema present, return-value explanation is optional, yet the description still lists per-query fields and adds the name-to-url linking instruction. Enough context exists to call the tool correctly; only sibling routing and pagination nuances are absent.

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 earns more by explaining filter semantics the enum doesn't (prijsfavoriet = AH's budget label, grouped diet/allergen categories), clarifying sort option 'most_bought (by this user)', and restating the queries cap with worked examples.

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 ('Search Albert Heijn (Dutch supermarket) products by keyword'), and the keyword-search framing distinguishes it from id-based siblings like ah_get_products and from ah_search_recipes.

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 clear operating guidance — pass one or more queries (max 10), prefer Dutch terms, use bonus=true for promotions, and how filters combine (AND semantics). It does not explicitly contrast with siblings such as ah_get_products or ah_get_bonus_offers, so no true when-not guidance.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context beyond that: the search language preference, the id-to-detail workflow, and the result-linking convention. It does not cover rate limits or result ordering, which keeps it short of 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?

Three sentences, each earning its place, and it is front-loaded with what the tool searches before moving to query tips, return shape, and follow-up workflow. 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?

An output schema exists, so return values need no explanation, yet the description still summarizes the key fields to aid selection. Combined with the ah_get_recipe routing and the linking instruction, an agent has everything needed to invoke and use this 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?

Schema description coverage is already 100%, so the baseline is 3. The description adds genuine semantic value for the query parameter by specifying that Dutch terms are preferred and giving domain-appropriate example terms, going beyond the schema's example. Limit is left 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 (Search) and resource (Allerhande recipe collection), and names the concrete domain (Albert Heijn). This clearly separates it from the sibling ah_search_products, which searches products rather than recipes.

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 usage guidance: Dutch search terms work best with concrete examples ('pasta', 'vegetarisch', 'stamppot', 'kip curry'), names the follow-up tool ah_get_recipe for ingredients and steps, and states the linking convention for results. The agent knows both how to query and what to do next.

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, so safety is covered. The description adds real behavioral context beyond that: the implicit fallback to the member profile address and the fact that the returned store id is the input to ah_get_last_chance_items, which is not derivable from 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?

Three tight sentences, front-loaded with purpose and fallback behavior. The enumerated return fields are partly redundant with the existing output schema, which is the only minor waste.

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

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

For a one-parameter read tool with annotations and an output schema, nothing an agent needs is missing: purpose, default behavior, and how the returned id is consumed downstream are all stated.

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 postal_code parameter already documents the format and the member-address fallback, so the description largely restates what the schema provides. Baseline 3 applies 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+resource ('Find Albert Heijn stores') plus the scoping constraint (near a Dutch postal code), which is unmistakable against siblings like ah_search_products or ah_get_last_chance_items.

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?

Explains the conditional default ('if no postal_code is given, automatically uses the address from the member profile') and points to the downstream tool that consumes the returned id (ah_get_last_chance_items). It gives clear context but does not explicitly compare against an alternative store-lookup tool (there is none).

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. The description goes beyond them by disclosing the required order state (which is not obvious) and by spelling out that quantity=0 destroys the line item. It stops short of return values or any confirmation of what the mutation yields, so 4 rather than 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?

Front-loaded with the core action, then prerequisites, then alternatives; every sentence carries routing or state information. The delivery-slot parenthetical is slightly heavy but is doing real explanatory work.

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 exists, but for a two-parameter mutation with annotations covering the destructive profile, the description supplies everything else needed: prerequisites, id provenance, removal semantics, and alternative tools.

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 and both parameters are already documented in the schema (including 'quantity 0 removes the item'). The description adds genuine value by telling the agent where product_id comes from (ah_search_products or ah_get_cart), which the schema does not.

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 precise verb+resource+scope: 'Set the quantity of a product in the active Albert Heijn delivery order.' It names the siblings it is not (ah_add_to_shopping_list for pre-order collection, ah_remove_from_cart as an alternative), so an agent can route correctly 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?

Explicit prerequisites (an order must exist, created by choosing a delivery slot), explicit alternatives with the condition that selects each (ah_add_to_shopping_list before an order exists; ah_remove_from_cart instead of quantity=0), and a stated special-value convention.

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