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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description goes further by disclosing that it WRITES to the real account and that an inactive list is activated as a side effect (with the opt-out flag). The explicit scope exclusion (basket, checkout, orders, payments) is valuable mutation 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 tight sentences, front-loaded with the action and scope, then side effects, then boundaries. Every sentence earns its place 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 3-parameter write tool with full schema coverage and no output schema, the description covers purpose, side effects, and boundaries well. It does not describe what the call returns (e.g. whether added/skipped items are reported), which is a minor 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 description coverage is 100%, so items, dedupe, and ensure_active are already fully documented in the schema. The description echoes the example and activation behavior but adds no syntax or format detail beyond the schema, 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?

States a specific verb (add) and resource (Jumbo shopping list), with a concrete example (['eieren']). It is clearly distinguishable from siblings like jumbo_remove_shopping_list_items and jumbo_set_shopping_list_item_completed.

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 ensure_active interaction and the scope boundary (never touches basket/checkout/orders/payments), giving clear context for invocation. It stops short of explicitly naming alternatives such as jumbo_search_products for finding exact product names.

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, and the description adds the meaningful behavioral fact that these are in-process caches (per-process, non-persistent) rather than shared or stored state. It also enumerates what is reported — enabled state, hits, misses, hit rate, entries, evictions — which compensates for the absent output schema. It does not say whether counters reset or how evictions are attributed, hence 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 sentences, zero filler: the first front-loads what is reported and in what granularity, the second front-loads the use case. Every clause carries information an agent would otherwise lack.

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 parameters, no output schema, and readOnlyHint already present, the description covers the essentials by listing the reported fields and the cache scope. Minor gaps remain — no mention of response shape (single object vs. per-cache entries) or whether stats are cumulative since start — but nothing that would cause a mis-call.

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 per the baseline there is nothing to disambiguate; the description correctly spends no words on arguments. The enumerated metric names function as an informal preview of the return payload, which is a small bonus rather than a parameter explanation.

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?

Names a specific verb (report) and a concretely scoped resource (the in-process GraphQL-response and store-geocoding caches), then enumerates the reported metrics. No sibling in the list deals with caches, so an agent can separate this diagnostics tool from the data-retrieval tools 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?

"Use to verify that cached Jumbo responses are reused instead of re-fetched" gives a clear triggering scenario. It stops short of stating exclusions or naming an alternative (e.g., when to prefer a live data call over reading stats), but for a zero-argument diagnostics endpoint the context is unambiguous.

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 tells the agent this is a safe non-mutating read, so the description's main contribution is the word 'live', implying a real-time fetch rather than cached data. No auth/session requirement, rate limits, or edge cases (e.g., empty balance, unenrolled customer) are disclosed.

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; every word ('live', 'loyalty points balance') carries information. Nothing is padded or restated from 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?

For a zero-parameter read with no output schema, the description conveys enough to select and call the tool, though it could note the returned shape (points figure, expiry) or any session prerequisite. The gaps are minor given the tool's simplicity.

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; there is nothing for the description to clarify and nothing misleading in the schema.

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

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

States a specific verb and resource ('get ... loyalty points balance') and scopes it to the customer's live Jumbo Extra balance. It is distinguishable from siblings like jumbo_get_stamps or jumbo_get_deposits by the resource name, but the description does not explicitly contrast itself with those near-neighbors.

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 guidance on when to call this versus jumbo_get_stamps, jumbo_get_deposits, or jumbo_get_profile, and no prerequisites such as whether a login/session is required first (jumbo_login exists as a sibling). Usage must be inferred entirely from the name.

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 by structured data. The description adds genuinely useful context beyond that: the exact returned fields and the backing GraphQL ActiveBasket operation, plus an explicit exclusion list of write/checkout/order/payment operations. It does not mention auth requirements, so it falls short of 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 tight sentences: the resource and returned contents come first, then the scope exclusions. Every clause carries information and nothing is repeated 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 compensates well by enumerating the returned fields and confirming the read-only, non-transactional nature of the call. The one omission is the prerequisite of an authenticated session, which matters given jumbo_login and other session-bound siblings exist.

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 an empty object at 100% coverage, so the baseline is 4. There is nothing parameter-related for the description to clarify, and it correctly does not invent any.

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 gives a specific verb ('Read-only view') and resource ('the current Jumbo basket'), and enumerates the payload (lines, quantity, unit price, line total, promotions, subtotal). It does not name a competing sibling, but no sibling in the list also returns the active basket, so the resource itself is differentiating.

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 'current Jumbo basket' plus the negative scope ('No basket writes, no checkout, no order, no payment operations'), which tells the agent what this is not for. There is no explicit when-to-use statement or prerequisite (e.g. that a session from jumbo_login is required), and no alternative tool is named.

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 annotation already declares this is a safe read operation. The description adds useful context beyond that by specifying the returned data categories and the order-scoped nature of the query. It does not contradict the annotation and does not need to disclose mutation or auth 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?

Two tightly written sentences with no filler. The purpose and required parameter are front-loaded, and the order-scoped constraint is stated immediately after, so the agent gets the essential information first.

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

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

For a simple single-parameter read tool with annotations covering safety and a fully documented schema, the description is complete. It even names the return contents despite there being no output schema, so an agent knows what kind of deposit data to expect.

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 required in the schema. The description reinforces that requirement and adds the rationale that the query is order-scoped, but it does not add syntax, format, or value constraints beyond what the schema provides.

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

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

States a specific verb (Read), resource (statiegeld/deposit information), and scope (for one order), and names the return contents: deposit catalogue, returned deposits, and returned total. An agent can distinguish it from sibling tools like jumbo_get_balance or jumbo_get_stamps 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?

The description establishes a clear prerequisite (requires an order_id) and explains that the query is order-scoped. However, it does not name alternatives or state when-not to use it versus related receipt or balance tools, leaving usage context implied rather than explicit.

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 consistent with a 'get' tool, so the safety profile is covered by annotations. The description adds the read-only mode breakdown but says nothing about authentication, rate limits, or freshness of promotional data, so it adds only marginal 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?

A single front-loaded sentence covering all three modes with no filler. It is slightly cramped by the trailing promotional clause, but nothing 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?

With zero required parameters and no output schema, the description should clarify the default behavior when no argument is supplied (does it return nothing, or a general recommendation set?) and give some sense of the returned data. That ambiguity is left unresolved.

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 supplies richer per-parameter detail (including examples like '293407STK' and 'havermelk') than the description does. The description merely restates the modes, adding no syntax or format meaning beyond the schema, 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 product recommendations, alternatives, and cross-sell suggestions') and enumerates the three operating modes. It is clearly distinct from siblings like jumbo_search_products, but it never names that sibling 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?

Usage is only implied by mapping each mode to a parameter (SKU vs. query vs. promotions_only), with no explicit statement of when to pick this over jumbo_search_products or jumbo_get_promo_digest. A reader can infer intent but gets no exclusions or routing 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?

readOnlyHint=true already tells the agent this is a safe read. Since there is no output schema, the description's enumeration of returned fields (loyalty profile, name, customer ID, Extra's card details, receipt preferences) is genuinely useful behavioral context. It stops short of stating whether authentication is required, which matters given a jumbo_login sibling.

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; the verb and resource lead and the field list follows. Appropriately sized for a zero-parameter read tool, though the field list is a flat enumeration rather than prioritized 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?

With no output schema, the description partly compensates by naming the returned data, but it omits whether a session/login is required and what happens if the user is unauthenticated or has no loyalty account. For an account-scoped read tool among login-bearing siblings, that is a meaningful 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?

The tool takes zero parameters, so the baseline is 4. There is no parameter syntax or filtering behavior for the description to add, and it correctly says nothing misleading about inputs.

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

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

Clear verb+resource ('Get customer loyalty profile') with an enumeration of the returned fields, which separates it from siblings like jumbo_get_balance or jumbo_get_stamps. It does not explicitly name an alternative, but the resource is specific enough that an agent can identify 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?

The description states what data comes back but gives no when-to-use guidance, no prerequisites, and no mention of sibling tools such as jumbo_get_balance or jumbo_get_stamps that also return account data. The intended trigger 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?

Annotations already declare readOnlyHint=true, so the safety profile is partly covered, but the description goes further by enumerating what is out of scope (no writes, no basket, no checkout, no order/payment operations). It also discloses the computation pipeline (receipt mining → assortment resolution) and the fields returned, which annotations alone do not convey.

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 ordered as question → mechanism/output → safety boundary, with zero filler. Each sentence earns its place and the most decision-relevant context (the user question) is front-loaded.

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

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

With no output schema, the description carries the burden of describing returns and does so fully: offer price (was/now), discount, promo type, validity window and unit price. Combined with the explicit read-only scope, an agent has everything needed to call and interpret it.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters including defaults and bounds. The description hints at the frequency-mining semantics (purchase frequency over recent receipts) but adds no syntax or format detail beyond the schema; baseline 3 applies.

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

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

States a concrete verb chain (mines receipts, resolves items, reports offers) and the exact resource: currently promoted items among frequently purchased products. The compound behavior is spelled out, making it clearly distinct from jumbo_search_products (assortment lookup) and jumbo_search_receipts (raw receipt search).

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 lead framing 'of the things I actually buy, what is on offer right now?' gives a clear use context that separates it from raw product/receipt search tools. It does not explicitly name or exclude the sibling alternatives, so it falls short of the 5-level routing 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?

readOnlyHint already declares safety; the description adds real value by detailing the returned fields (deposit/statiegeld, Extra's points, payment method). It does not contradict annotations, but it stops short of describing format or error 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?

One dense sentence, front-loaded with the verb and the enumerated fields. Nothing is redundant and every field listed carries informational value for the agent.

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

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

With no output schema, the description usefully enumerates the returned data so the agent knows what to expect. Combined with the fully documented single param, the definition is close to complete for a simple read tool.

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

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

Schema coverage is 100% and there is a single required parameter fully documented in the schema, which even names its source tool. The description adds no syntax or format detail beyond that, so baseline 3 is appropriate.

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

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

States a clear verb (get) and resource (receipt details) and enumerates exactly what is returned: line items, unit prices, discounts, total, deposit, payment method, points. It does not explicitly name the sibling jumbo_list_receipts in the text, but the schema ties the transaction_id back to 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?

Usage is implied: fetch details for one specific receipt identified by transaction_id. There is no explicit guidance on when to use this versus jumbo_list_receipts or jumbo_search_receipts, though the schema hint 'from jumbo_list_receipts' quietly signals the sequence.

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 disclosed return shape (active status plus per-item fields), which is genuinely beyond the annotation. It does not cover auth requirements, empty-list behaviour, or pagination, so it stops 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?

A single sentence that front-loads the resource and then the returned fields; no padding, no 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?

With no output schema, the description usefully compensates by listing the return contents, and there are no parameters to document. It could be more complete by noting whether an empty/absent list is returned or that a login is required, but nothing essential to invoking it is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to clarify at the parameter level; the baseline of 4 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 (the user's Jumbo shopping list, with the Dutch alias 'lijstje') and enumerates the payload (active flag, items with id/term/sku/completed). An agent can tell this read tool apart from the sibling add/remove/set mutations 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?

Usage is implied by the getter name and the alias, but there is no explicit when-to-use guidance, no mention of prerequisites (e.g. authentication via jumbo_login), and no statement of when to prefer this over jumbo_get_basket or the receipt/balance 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?

readOnlyHint=true already tells the agent this is a safe, non-mutating read. The description adds the shape of the payload, which is useful since there is no output schema, but it says nothing about authentication (jumbo_login exists as a sibling) or any session/prerequisite 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?

One sentence, front-loaded with the verb and resource, with the payload contents following the colon. Nothing is redundant and nothing needs to be cut.

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 carries the burden of describing the return value, and it does so by listing the three categories of data returned. The main omission is whether a login/session is required, which is implied by the presence of jumbo_login among its 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?

The tool takes zero parameters, so the baseline of 4 applies. The description correctly does not waste space inventing argument 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?

Names a specific verb (Read) and resource (digital stamps), then enumerates exactly what it returns: per-campaign stamp counts, active spaar campaigns, and buying-stamps balance. This partially separates it from balance-oriented siblings like jumbo_get_balance and jumbo_get_deposits by scoping the balance to stamps, though it never explicitly names those siblings.

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

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

Usage is implied by the resource name: call it to inspect stamps. There is no stated condition for choosing it over jumbo_get_balance or jumbo_get_deposits, and no prerequisites, but the tool has no arguments, so the selection ambiguity is limited.

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 annotation already establishes that this is a safe read operation. The description adds meaningful behavioral context by explaining that it aggregates across store receipts and reports total returned, total charged, net balance, and per-receipt breakdown.

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

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

The description is two tightly written sentences with no wasted wording. The core action and scope are front-loaded, and the reported outputs follow immediately.

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 read-only aggregation tool with fully documented optional parameters, the description is largely complete and even lists the return metrics in the absence of an output schema. It could be stronger by clarifying how year and start_date/end_date interact if both are provided, but no critical information 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 all four parameters are already documented in the schema. The description reinforces the date-range versus calendar-year usage but does not add syntax or precedence details beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource: calculate returned and charged statiegeld across store receipts over a date range or calendar year, and it names the reported metrics. It is clear what the tool does, though it does not explicitly differentiate itself from sibling tools such as jumbo_get_deposits.

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

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

The description implies when to use the tool by specifying a date range or calendar year, which gives useful context. However, it does not say when not to use it or name an alternative such as jumbo_get_deposits, so the routing guidance is only partial.

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 the shape of each returned item (date, store location, transaction ID), which is useful context, but says nothing about ordering, pagination behavior, or result limits beyond what the schema notes.

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 the verb, resource, parenthetical clarification, and returned fields. Every clause earns its place 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?

For a simple read-only list tool with a fully documented two-parameter schema and no output schema, this is nearly complete. The only meaningful gap is the lack of routing against the sibling receipt-fetching 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 description coverage is 100% and both parameters (page, page_size) are fully documented with defaults and bounds in the schema, so the baseline of 3 applies. The description adds no parameter-level meaning beyond what the schema already provides.

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

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

The description gives a specific verb (List) and resource (Jumbo supermarket store receipts, with the Dutch term 'kassabonnen' as a helpful synonym), plus the fields returned. It is clear what the tool does, but it does not distinguish itself from the sibling tools jumbo_search_receipts or jumbo_get_receipt_details, leaving the agent to infer the difference.

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 when-to-use guidance and no mention of alternatives, despite jumbo_search_receipts and jumbo_get_receipt_details sitting in the sibling list. The word 'recent' hints at a recency scope, but no exclusions or selection 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?

With readOnlyHint=true already covering the safety profile, the description adds genuinely useful context: the server relies on persistent pre-configured Auth0 tokens, so this is a connection verification rather than a credential exchange, and it returns user loyalty identity. It does not describe failure behavior (e.g., what an unauthenticated result looks like).

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

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

Two sentences, front-loaded with the action and followed by the mechanism. No filler and nothing repeated from the title or schema.

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 parameterless, no-output-schema tool, the description covers mechanism and the identity returned, which is enough to call it correctly. Only the shape of a failed/unauthenticated result 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?

Zero parameters, so there is nothing to document and the baseline is 4. The description correctly implies the call 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+resource ('Check authentication status') and a secondary capability ('establish session with Jumbo'), and no sibling tool touches authentication, so an agent can distinguish it immediately.

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 — an agent would reasonably call this to verify the connection before other jumbo_* calls — but the description never states when to call it, when not to, or that it should precede other operations. No alternatives are named.

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 bar is lower; the description nonetheless adds that this WRITES to the user's real Jumbo account, emphasizing real-world irreversibility. It does not explain what happens to item state or whether removal can be undone, so it adds useful context but not rich detail.

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 scope, with zero filler. Every clause carries useful information (id provenance, write warning, scope limit).

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, the definition covers action, id source, scope, and the write-to-real-account warning, while annotations cover the destructive profile. Nothing material 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% with a single well-described param, so the baseline is 3. The description adds provenance beyond the schema by stating the ids originate from jumbo_get_shopping_list, which tells the agent how to obtain valid values.

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

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

States a specific verb (remove) plus resource (shopping list items) and scope ('Shopping list only'), which cleanly separates it from the sibling add/set tools. An agent can identify the operation 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?

It names the upstream source of the ids ('ids come from jumbo_get_shopping_list'), giving a clear workflow cue, and constrains usage with 'Shopping list only'. It stops short of stating when not to use it or naming alternatives explicitly, so it is clear context but not full routing 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?

readOnlyHint=true already declares the safety profile, so the description is free to add value — and it does, enumerating the exact payload fields an agent will get back (prices, active discounts, unit prices, links, SKUs) in the absence of an output schema. It is silent on behavior beyond that, such as empty-result handling 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 sentences, zero filler. The core action and scope come first, the return payload second, which is the right front-loading for a search 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?

With no output schema, the description's field enumeration does real work in telling the agent what a result looks like. Combined with fully documented parameters and a readOnly annotation, an agent has enough to call it correctly; only pagination/result-size behavior is left to the schema's limit description.

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%: query, sort enum with both values explained, and limit with default and max all carry rich in-schema descriptions. The description adds no parameter-level meaning, 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 — search the Jumbo grocery catalog by keyword — and names the returned data (prices, discounts, unit prices, links, SKUs). It is clearly distinguishable from the receipt- and store-oriented siblings by the word 'catalog', though it never names any 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 implied: keyword lookup across the whole catalog, which positions it as the broad discovery tool versus narrower siblings like jumbo_get_product_recommendations. However, no when-to-use vs when-not-to-use guidance or alternative routing is 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?

readOnlyHint=true already tells the agent this is a safe read; the description adds the scope, that searching spans 'recent' receipts, which is useful context. It does not describe result format, matching behavior, or what happens when nothing matches.

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 the verb and resource first, followed by concrete examples. 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 simple two-parameter read tool with full schema coverage and a safety annotation, the description is adequate but thin. With no output schema, it could say more about what is returned (matching line items, receipt references) to fully orient the agent.

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

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

Schema coverage is 100%, so both parameters are fully documented in the schema. The description adds keyword examples ('havermelk', 'bio ei', 'skyr'), giving a flavor of acceptable queries, but no format or syntax beyond that.

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

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

Clear verb (search) plus resource (grocery items purchased across recent Jumbo receipts) and method (by keyword), with concrete examples. It is distinguishable from jumbo_search_products in spirit but never names or contrasts with siblings 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?

The description implies its use case (finding items you bought) but gives no explicit when-to-use guidance versus alternatives like jumbo_search_products, jumbo_list_receipts, or jumbo_get_receipt_details. Usage 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?

readOnlyHint=true already tells the agent this is a safe read, and the description usefully adds what is returned (address, distance, opening hours, facilities). It does not disclose whether latitude/longitude must be supplied as a pair, what happens with zero arguments, or any result limits/pagination.

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

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

Two tight sentences: the search capability and its inputs come first, the return payload second. 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 read-only search with no output schema and no required parameters, the description covers both inputs and expected return fields adequately. The only minor gap is behavior when no argument is supplied, since all three parameters are optional.

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%, with each parameter documented including examples, so the baseline is 3. The description restates the same three input modes without adding format rules (e.g., postal-code format, coordinate pairing) beyond the schema.

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

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

The description states a specific verb and resource ('Search nearby Jumbo supermarket stores') plus the accepted input modes (city, address, coordinates). It is clearly distinct from product/shopping-list siblings by resource, though it never names an alternative tool to differentiate 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 implied by listing the acceptable query forms (city name, address, coordinates), so an agent can infer when this tool applies. However, there is no explicit when-to-use/when-not guidance, no mention of the geographic-search sibling or of what to do when geolocation is unavailable.

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 already declaring readOnlyHint=false and destructiveHint=false, the description adds useful behavioral context: it writes to the user's real Jumbo account and is scoped to list activation rather than item modification. It does not cover authentication needs or reversibility details, but it meaningfully supplements 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?

Two short sentences, front-loaded with the action and immediately followed by the critical write-scope caveat. Every sentence earns its place with no redundant or vague language.

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 boolean toggle with full schema coverage and annotations, the description provides enough to invoke correctly: it names the resource, states the effect, and clarifies the write scope. It omits secondary details such as authentication requirements or what happens to existing items when deactivated, but no output schema exists and the annotation covers safety.

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 boolean parameter is already documented as 'true to activate, false to deactivate.' The description mirrors the activate/deactivate meaning but adds no syntax or edge-case detail beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific verb phrase ('Activate or deactivate') and resource ('the user's Jumbo shopping list'), and explicitly distinguishes itself from item-level operations by saying it does not add or remove items. An agent can immediately tell this apart from siblings like jumbo_add_shopping_list_items and jumbo_remove_shopping_list_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?

It clearly states the context (toggling list active state) and gives an exclusion ('does not add or remove items'), which implicitly routes the agent to the add/remove siblings for item changes. It does not name those siblings explicitly, so it stops short of a perfect routing instruction.

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=false and destructiveHint=false, so the write nature is partly covered; the description goes further by warning 'This WRITES to the user's real Jumbo account,' which is meaningful context for a state-changing call. It still omits auth requirements and reversibility/error behavior, 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 tight sentences: the action and its two directions come first, then the account-write warning. Every clause earns its place 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?

For a two-parameter toggle with annotations present and no output schema, the description covers what it does, both directions of the flag, and the real-account side effect. Missing only auth expectations and failure behavior, which keeps it from a 5.

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

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

Schema description coverage is 100% and the schema already spells out item_id's source and completed's true/false meaning, so the description's toggle explanation largely repeats structured data. 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 (tick off / back on) and resource (item on the user's Jumbo shopping list), and the bidirectional toggle framing clearly separates it from jumbo_add_shopping_list_items and jumbo_remove_shopping_list_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 toggle semantics (mark done vs undone), but there is no explicit when-to-use guidance or routing to alternatives such as removing the item instead of ticking it.

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