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

Annotations already declare the safety profile (readOnly=false, destructive=false, openWorld=true), and the description adds genuinely new behavior: the default ingredient-filtering policy and the fact that no order is placed. It stops short of disclosing what happens on repeat calls (idempotentHint=false) or how include_ingredient_ids and skip_ingredient_ids interact if an id appears in both.

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: what it does and its default exclusions first, then how to override, then the explicit non-goal. 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 no output schema, the description should hint at the result; it only says it doesn't place an order, not what the cart looks like afterward. Otherwise, for a 4-param mutation with thin schema coverage, the default-filtering policy and override mechanism make it callable without further guesswork.

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 only 25% — just recipe_id is documented — so the description must compensate. It does add real meaning for include_ingredient_ids and skip_ingredient_ids (including their source, get_recipe), but 'portions' is never mentioned, leaving scaling behavior and the default of 2 undocumented anywhere.

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 ('Add a recipe's needed ingredients to the cart') and pins the scope with the concrete 'add all' button analogy and the boundary 'Does not place an order.' The recipe-level framing inherently distinguishes it from the single-item sibling add_to_cart and from remove_recipe_from_cart.

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

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

Explicitly describes the default behavior (pantry items, probable-at-home ingredients and alternatives are excluded) and then names the two levers for changing it: include_ingredient_ids for items the user lacks, skip_ingredient_ids for needed items the user already has. It also rules out order placement, so the agent knows when this tool is *not* enough.

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 this is a non-read-only, non-idempotent, non-destructive, open-world mutation, so the bar is lower. The description's one extra fact (no order is created) is a genuine boundary, but it omits whether repeated calls stack quantities, whether an existing line item is replaced, and whether login is required.

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, front-loaded sentences with no filler, and the scoping caveat follows the action statement. It is efficient, though its brevity borders on under-specification for a mutation tool.

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 tool with reasonable annotation coverage and no output schema, the definition is close to sufficient. Missing quantity semantics and merge-on-duplicate behavior are the main gaps an agent would need 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 coverage is only 50%: product_id is documented in the schema, while 'count' has only type/default/min/max constraints and no explanation of whether it sets or increments the line quantity. The description says nothing about either parameter and so fails to compensate for the coverage gap.

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 product to the cart') that is immediately distinguishable from get_cart, remove_from_cart and clear_cart. It does not, however, differentiate itself from the very similar sibling add_recipe_to_cart, which a selecting agent would need.

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?

'Does not place an order' is a useful negative boundary that rules out treating this as checkout. But there is no positive guidance on when to prefer this over add_recipe_to_cart, nor any prerequisite such as needing a product_id from search_products or a completed login.

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, idempotentHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds only the bulk scope ('every item'), not the irreversibility warning, auth needs, or behavior on an already-empty cart that would add real value beyond 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?

A single short sentence with the action front-loaded and no filler. It is efficient, though its brevity is close to the minimum needed for a destructive bulk operation.

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, non-read-only, idempotent, destructive tool with full annotation coverage and no output schema, the description states enough to call it correctly. The only missing piece is explicit contrast with remove_from_cart and expected behavior on an empty cart.

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 schema is empty at 100% coverage, which is the baseline-4 case. There is nothing for the description to disambiguate and it introduces no confusing parameter wording.

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

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

The description states a specific verb and resource ('Remove every item from the cart'), and the word 'every' implicitly scopes it as a bulk clear as opposed to the sibling remove_from_cart, which handles a single item. It is clear but never names or contrasts the sibling explicitly.

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 bulk-emptying variant rather than the single-item remove_from_cart, but the description gives no explicit when-to-use or when-not-to-use guidance, nor any prerequisite note.

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

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

Annotations already declare readOnly=false, destructive=false and openWorld=true; the description adds genuinely new context about where the recipe lives and that it does not touch the cart or place an order, which reassures an agent about side effects. It does not mention what happens on duplicate names or whether repeated calls create duplicates (relevant given idempotentHint=false).

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 ordered purpose → prerequisite → side effects, with no filler. Each sentence adds information the schema or annotations do not already provide.

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 three-parameter mutation tool with no output schema, the description covers purpose, input sourcing, quantity semantics and side-effect boundaries. Remaining gaps (meaning of portions, error behavior on duplicates, what is returned) are minor but real.

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 only 33%, so the description carries real weight: it explains that product_id comes from search_products and that quantity means 'number of packages of that product', covering the undocumented nested fields. The 'portions' parameter remains unexplained beyond its schema bounds, keeping it short of a 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 and resource ('Save a recipe of the user's own in the Picnic app') and grounds it in the app's own term 'Eigenes Rezept'. It clearly distinguishes itself from search_recipes/get_recipe/delete_recipe and, via 'Does not touch the cart or place an order', from add_recipe_to_cart and add_to_cart.

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

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

Gives an explicit prerequisite workflow: 'Find each ingredient with search_products first and pass its id', naming the sibling tool to use beforehand. It also rules out cart/order effects, implicitly steering agents to add_recipe_to_cart for that purpose, though it never names that alternative directly.

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, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered structurally. The description adds the genuinely new scope constraint (user-created only) and names the creating tool as the id source, but says nothing about irreversibility, permissions, or what happens to a recipe already in a cart.

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 immediately followed by the constraint. Zero filler and nothing an agent must read past.

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 destructive tool with full annotation coverage, the description covers action, eligibility, and id provenance. Only permanence/failure behavior is unstated, and destructiveness is at least implied by the annotations.

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

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

Schema coverage is 100% and the single parameter's description already states "Id returned by create_recipe". The description's "created with create_recipe" reinforces rather than extends this, so baseline 3 applies — the schema does the work.

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 a recipe") with an explicit scope tie-back to create_recipe, which distinguishes it from read-oriented siblings like get_recipe and search_recipes. An agent knows immediately what is removed and which recipes the tool covers.

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?

"Only for user-created recipes, never Picnic's own" is a clear when-not condition, which is the main routing question for a delete tool. It doesn't name an alternative for non-user recipes (there is none in the sibling list), so the missing piece is minor.

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 read-only/idempotent/non-destructive, and the description adds substantive behavior beyond them: it keeps only products whose name contains every query word, ranks them, recognizes organic status from name keywords (Bio, Bioland, Demeter, Naturland), and returns best plus a few alternatives without mutating the cart.

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 purpose, then preference semantics, then the cart workflow, so an agent can stop reading early. The preference block is a dense run-on that could be bulleted, but no sentence is 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?

With no output schema, the description still explains the return shape (best and a few alternatives per item, packs to buy, total cost, leftover) and the follow-up call. The only omission is the items maxItems=20 cap and minItems=1, which the schema enforces anyway.

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 reported as 0% for the enum fields, so the description must carry the load, and it does: every preference value is defined ('cheapest' accounts for amount needed, 'best_value' is price per kg/litre, 'organic' is Bio-only cheapest first, etc.), amount syntax is illustrated, exclude is explained with examples, and per-item preference override of the global preference is stated.

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: finds the best Picnic product for each ingredient of a recipe or shopping list, with a named ranking goal. It is clearly distinct from the sibling search_products, which does not do per-ingredient ranking or cost/leftover math.

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 clear usage context (recipe or shopping-list ingredients) and an explicit workflow: it does not touch the cart, so confirm choices and then call add_to_cart with packs as count. It never explicitly contrasts with search_products for single-item lookups, so the alternative routing is left implicit.

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, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description still adds real value by disclosing what the response contains and the unit of the price (cents), which is not in any structured field.

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 sentence, front-loaded with the action and resource, with the return contents appended. Nothing is wasted and nothing needs trimming.

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-param read tool with no output schema, the description usefully sketches the return shape (item counts, total in cents). Minor gaps remain: behavior on an empty cart and whether the cart is user- or session-scoped are 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?

The tool takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. The schema is empty and fully described.

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 ("Show the current cart") plus the payload contents (item counts, total price in cents). This clearly separates it from the mutation siblings add_to_cart/remove_from_cart/clear_cart, though it never names an alternative explicitly.

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 read path for the cart versus the add/remove/clear siblings. There is no explicit statement of when to call it (e.g., before checkout) or when not to.

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, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the read-only sentence largely restates structured data. It does add useful behavioral context that results are ordered soonest-first and include an order-by time, but says nothing about limit/pagination or behavior with an empty cart.

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 compact sentences, with the core listing behavior front-loaded and the read-only caveat following. Every clause adds information and no sentence is wasted.

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 read-only list tool with no output schema, the description covers purpose, scope, ordering, and a key return field (time to order by). It falls short only on limit/pagination behavior and empty-cart edge cases, which are minor for this complexity level.

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

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

The single `limit` parameter has 0% schema description coverage, so the description should explain it, but it never mentions result caps or paging. The parameter's default/maximum bounds are only inferable from the schema, and the description gives no guidance on how many slots are returned or how to request more.

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 ('bookable delivery windows') scoped to the current cart, plus ordering ('soonest first') and payload ('time to order by'). No sibling tool is similar, so differentiation is moot but the purpose is unmistakable.

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 sets a boundary: 'The tool only reads the slots, it does not book one,' which tells the agent not to expect a booking action. There is no named alternative because no sibling overlaps, but it lacks explicit 'use when' phrasing such as requiring a non-empty cart.

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

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered; the description adds genuinely useful behavior the annotations don't carry, namely sort order and the explicit omission of line items. It stops short of describing pagination or what happens as orders age out, which would have made it 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 sentences, zero filler, with the returned shape front-loaded and the exclusion placed last where it reads as a caveat. Every clause carries distinct 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-optional-parameter read tool with no output schema and rich annotations, the description covers return fields, ordering and a key limitation. The remaining gap is the `limit` parameter and default page size, which the description leaves entirely to the 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 is one optional parameter, `limit`, with 0% schema description coverage, and the description never mentions it. The schema's default (10), minimum (1) and maximum (50) still convey the constraint structurally, but the description does not state what the limit counts or how it interacts with 'recent'.

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 the user's recent completed deliveries') and immediately pins down ordering ('newest first') and returned fields (order time, delivery window, total paid in cents). The explicit exclusion ('does not list the products in each order') further sharpens the boundary, so an agent knows exactly what this tool yields versus a product/ingredient tool in the sibling set.

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 scope ('recent completed deliveries') implies when it applies, but there is no explicit statement of when to call it versus other tools, nor any prerequisite or exclusion guidance. No sibling overlaps directly with order history, which limits the harm, but usage is inferred rather than stated.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive). The description adds genuine behavioral context beyond that: the ingredient 'kind' taxonomy and the non-obvious default that only 'needed' ingredients are selected for the cart. It stops short of covering error behaviour (e.g., invalid recipe_id) or auth needs.

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

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

The description is front-loaded with the resource then the returned fields, with no filler sentences. The ingredient-kind explanation is long but each clause conveys distinct semantics an agent needs in order to interpret 'needed' vs 'alternative'.

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

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

There is no output schema, so the description carries the return-value burden, and it does so thoroughly by listing fields and per-portion nutrition. Remaining gaps are minor: not-found behaviour, and whether amounts or Picnic products can be 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 is a single parameter with 100% schema description coverage, and the schema already states the id's origin (search_recipes or create_recipe), so the description need not duplicate it. With only one fully documented parameter, there is little left to clarify, though the description adds nothing directly about recipe_id.

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

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

The description opens with a specific verb+resource ('Show a recipe') and immediately enumerates the fields returned, so there is no ambiguity about what the tool produces. It does not explicitly contrast itself with search_recipes or create_recipe, which keeps it below a 5.

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 by the resource ('Show a recipe') and by the schema note that recipe_id comes from search_recipes or create_recipe. The description itself never states when to call this versus search_recipes or add_recipe_to_cart, nor any prerequisites.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds only the notion of removing a *quantity*, and says nothing about what happens when count exceeds the cart quantity, whether the call errors or partially removes, or what state the cart is left in.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though the brevity reflects under-specification as much as tight writing.

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

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

For a destructive, non-idempotent mutation with no output schema and one undocumented parameter, the description is too thin. It should indicate error/partial-removal behavior and the resulting cart state, neither of which is available anywhere else in the structured data.

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

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

Schema coverage is 50%: product_id is documented in-schema, count is not. The word 'quantity' in the description maps loosely to count and clarifies that removal can be partial rather than whole-line, but it gives no default, bounds, or behavior for counts above what's in the cart.

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 a quantity of a product from the cart), which is clearly distinct from add_to_cart and clear_cart by name and text. It does not explicitly contrast itself with siblings such as remove_recipe_from_cart or clear_cart, so it stops short of full 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives (e.g. use clear_cart to empty the cart, or remove_recipe_from_cart for recipe-based items). The agent must infer from the name alone that this is for partial/line-item removal.

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, idempotentHint=true, openWorldHint=true, and readOnlyHint=false, so the safety profile is fully covered by structured data. The description adds essentially nothing beyond that — it does not say whether the recipe itself is deleted, whether already-placed orders are affected, or what state the cart is left in.

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?

It is a single short sentence with no padding, which is good, but it is under-specified rather than concise. The vague word 'again' consumes space without adding 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 destructive, open-world mutation with no output schema, the description omits what an agent most needs: the blast radius of the removal and the resulting cart state. With only one well-documented parameter the schema burden is low, but the behavioral gap is not filled anywhere else.

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 recipe_id parameter is already documented as coming from search_recipes or create_recipe. The description contributes no additional meaning about the identifier, so 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 verb phrase 'take ... out of the cart' with the resource 'a recipe's ingredients' gives a rough sense of the action, but the trailing 'again' adds ambiguity rather than specificity. It does not distinguish itself from the sibling tools remove_from_cart or clear_cart, so an agent cannot tell whether it removes one ingredient, a recipe's whole contribution, or everything.

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?

There is no statement of when to use this instead of remove_from_cart, clear_cart, or add_recipe_to_cart. The word 'again' faintly implies it reverses an earlier add_recipe_to_cart, but the agent has to infer that pairing rather than being told.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered without the description. The description adds value by disclosing the returned fields (id, name, price in cents, unit size, unit price), which is genuinely useful since there is no output schema, but says nothing about result limits, pagination or match behaviour.

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 purpose front-loaded and the return shape following immediately. Every sentence earns its place.

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

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

Listing return fields partially compensates for the missing output schema, and the annotations cover safety. But for a tool sitting among recipe and ingredient siblings, the description never clarifies the domain boundary and leaves the limit parameter and matching behaviour unexplained.

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

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

Schema coverage is 50%: query is documented with an example, but limit has no description and the description adds nothing about it — not even that it caps result count up to 30. The description also gives no hint about query semantics such as language, partial matching or case sensitivity.

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 the Picnic catalogue") plus the exact return shape, so the agent knows this is a product lookup. It does not differentiate itself from the sibling search_recipes or find_ingredients, which an agent could plausibly confuse with it.

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

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

No statement of when to use this instead of find_ingredients or search_recipes, and no note that it searches products rather than recipes beyond the ambiguous word "catalogue". The only routing signal is the tool name itself.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds a return-field summary (id, name, duration, labels) which substitutes meaningfully for the absent output schema — more than the annotations provide. It stops short of noting result ordering or whether label filters are supported.

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: what is searched, then what comes back. The most important information (scope) is front-loaded and no sentence is padding.

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

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

For a two-parameter read-only search with no output schema, the description supplies the return shape and the data scope, which is the essential missing piece. Remaining gaps are the undocumented 'limit' parameter and matching behavior, which are minor but non-trivial for an open-world search.

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 only 50%: 'query' is documented in the schema but 'limit' has no description anywhere. The description gives no guidance on query syntax (substring? fuzzy? multilingual, given the German example), nor on the limit range of 1–20 or what happens on overflow, so it fails to compensate for the coverage gap.

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+resource ('Search ... recipes') and even scopes the search to two corpora: Picnic's own recipes and the user's recipes. It does not explicitly contrast with siblings like search_products or get_recipe, but the resource word 'recipes' plus the scope makes it clearly separable.

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 scope statement ('Picnic's own recipes and the user's recipes') implies when this tool applies, but there is no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives such as search_products or get_recipe for a known id. Usage must be inferred.

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

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

Goes well beyond the annotations: one-time 127.0.0.1 address, 5-minute expiry, the exact credentials requested, SMS/e-mail code step, token written to the system credential store, and an explicit security assurance that the password never reaches Claude. This is exactly the extra context a non-destructive but non-idempotent, open-world tool needs.

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

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

Front-loads the action ('Open a sign-in page...'), then layers mechanism, security, and usage trigger in descending priority. Dense but every clause carries information an agent cannot get from the schema or annotations.

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

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

Adequate for a zero-param tool with no output schema: the agent knows what will happen and why. A small gap is that it does not say what to do after signing in (e.g., retry the tool that reported the missing session), though that is reasonably inferable.

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 the baseline is 4. The description correctly implies no input is required and instead describes the interactive flow the user will go through, which is the useful substitute for a parameter list 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?

States a specific verb and resource ('Open a sign-in page for Picnic'), plus the execution locus (user's browser) which separates it from any hypothetical server-side auth. No sibling tool shares this purpose, and the auth scope is unmistakable.

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 trigger condition: 'Use it when another tool reports that no session is stored.' That is a concrete, checkable precondition rather than an implied one, and it correctly frames this as the fallback for the session-dependent siblings.

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