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

No annotations are provided, so the description carries the full burden and does well: it flags that this WRITES to the user's real account, discloses the activation side effect for inactive lists and how to suppress it, and explicitly enumerates untouched resources. It omits auth/permission requirements and failure behavior, keeping it short of a 5.

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

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

Three short sentences, zero filler, with the write-to-real-account warning and the side effect front-loaded. 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?

For a mutation tool with no annotations and no output schema, the description covers the critical facts: it is a real write, it may activate the list, and it is scoped away from basket/checkout/orders/payments. Return-value expectations and error handling are not addressed, but the essentials are present.

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 three parameters (items, dedupe, ensure_active) are already documented in the schema. The description's 'free-text items' phrasing and mention of ensure_active confirm intent but add 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+resource ('Add one or more free-text items to the user's Jumbo shopping list') with an example, and explicitly bounds scope against sibling concerns ('Never touches the basket, checkout, orders or payments'). An agent can distinguish it from jumbo_get_shopping_list, jumbo_remove_shopping_list_items and jumbo_get_basket without opening a schema.

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

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

Gives clear context for when to use it (adding free-text items to the shopping list) and a concrete alternative behavior ('set ensure_active=false to skip' activation). It does not explicitly name sibling tools or when to prefer them, but the exclusions make the boundary 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?

No annotations are provided, so the description carries the full burden. 'Live' hints at a real-time fetch and implies a read-only operation, but nothing is said about authentication (a jumbo_login sibling exists), rate limits, or what the returned balance represents or whether it can be stale.

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 earns its place and the resource is named immediately after the verb.

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 getter with no output schema, the description is minimally adequate but leaves the caller guessing about the authentication context and the shape/units of the returned balance. It says what it fetches but not enough about the surrounding requirements.

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 are no parameter semantics to clarify. Baseline 4 applies; the description correctly implies the balance is implicitly scoped to the authenticated customer.

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'. This clearly separates it from siblings like jumbo_get_receipt_details or jumbo_search_products, though it doesn't explicitly distinguish itself from adjacent balance-like tools such as jumbo_get_stamps or 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?

There is no statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. The sibling set contains several other 'get' tools (jumbo_get_stamps, jumbo_get_deposits, jumbo_get_profile) and the description offers no routing help among them.

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

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

With no annotations present the description carries the full burden, and it does disclose read-only semantics, the exact fields surfaced, and the backing GraphQL operation. It omits environment facts an agent might need, such as session/auth requirements (jumbo_login exists as a sibling) or behavior on an empty basket.

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, front-loaded with the capability and followed by the return contract and the exclusion list. No filler or restatement of the tool name.

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 summarizes the returned shape (line fields plus subtotal), which is exactly what an agent needs for a zero-parameter read. Auth state and empty-basket/error behavior remain unstated, though complexity here is low.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline for a parameterless tool is 4. The description correctly implies no inputs are needed to retrieve the current basket.

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 ('Read-only view of the current Jumbo basket') and enumerates the payload (lines, quantity, unit price, line total, promotions, subtotal). This clearly separates it from the shopping-list, receipt, and store siblings, which operate on entirely different resources.

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 negative scope: 'No basket writes, no checkout, no order, no payment operations,' which tells the agent when not to expect mutation capability. It stops short of naming a sibling alternative for the write path (e.g., the add/remove shopping-list tools), so routing is informed but not fully directed.

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

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

With no annotations, the description carries the full burden and does disclose that this is a read-only, order-scoped query and describes the shape of the result (catalogue + returned deposits + returned total), which matters since there is no output schema. It omits auth requirements, rate limits, and behavior on an unknown order_id, so it falls short of fully transparent.

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 resource and its contents front-loaded and the required-parameter constraint following. Every clause earns its place.

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

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

For a one-parameter read tool with no output schema and no annotations, the description covers what the tool does, what it returns, and the scoping rule. Auth/permission expectations and error behavior are not covered, but the core information an agent needs to call it correctly is present.

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% for the single order_id parameter, and the schema already notes it comes from order history/receipts. The description only restates that order_id is required and adds the rationale that the query is order-scoped, which is modest added value over the schema. Baseline 3 is appropriate.

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

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

States a specific verb (Read) and resource (statiegeld/deposit information for one order) and enumerates exactly what the payload contains: the deposit catalogue, the returned deposits, and the returned total. No sibling tool covers deposits, so it is distinguishable from the rest of the jumbo_* family without opening any schema.

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

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

It gives a prerequisite (order_id is required) and a scoping constraint (the returned-deposits query is order-scoped), which implies usage for a single known order. However, it names no alternative and states no when-not-to-use condition, so the guidance remains 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the returned content categories but says nothing about authentication needs, result limits, ordering, or how the three modes differ behaviorally (e.g., precedence if both sku and query are passed).

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 well-formed sentence with the returned resource front-loaded. It is efficient and wastes no words, though the trailing promotions clause makes the sentence slightly dense.

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

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

With no output schema and no annotations, the description is the only source of behavioral context, and it covers the return content but omits usage routing and behavioral constraints. Adequate but with clear gaps for a three-mode tool with optional params.

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 parameter descriptions already explain each mode (SKU vs query vs promotions_only) with examples. The description adds no syntax or semantic detail beyond that, so the baseline 3 applies.

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

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

The description uses a specific verb ('Get') with a clearly named resource ('product recommendations, alternatives, and cross-sell suggestions') and enumerates the three input modes (SKU, query, promotions). It is easy to grasp what the tool returns, though it never explicitly distinguishes itself from close siblings like jumbo_search_products or jumbo_get_promo_digest.

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 hints at three usage modes (by SKU, by query, or promotions_only) but provides no when-to-use guidance, no prerequisites, and no naming of alternatives. An agent must infer from the schema alone whether this or jumbo_search_products / jumbo_get_promo_digest is the right call.

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

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

With no annotations, the description carries full behavioral burden, yet it only lists return fields. It does not state authentication requirements (notable given a jumbo_login sibling exists), whether the call is read-only, error behavior, 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?

A single front-loaded sentence with the resource and returned data enumerated; no filler or redundancy. Every clause maps to actual payload content.

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

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

With no output schema, the description usefully enumerates returned fields (profile, name, customer ID, card details, receipt preferences), which is the right place for that information. The main omission is auth/ownership context in a tool set that includes jumbo_login.

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 are no parameter semantics to explain; the baseline for a 0-param tool applies. The description correctly adds no spurious parameter discussion.

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 ('customer loyalty profile') and enumerates the data returned (name, customer ID, Extra's card details, receipt preferences). This is clearly distinguishable from siblings like jumbo_get_balance or jumbo_list_receipts, 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?

The description gives no when-to-use guidance, prerequisites, or alternative tools to consider. It implicitly suggests calling it when profile data is needed, but nothing is 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 no annotations, the description carries the full burden, and it explicitly declares 'Read-only: no writes, no basket, no checkout, no order or payment operations' — a genuinely useful safety disclosure. It stops short of mentioning auth requirements (there is a jumbo_login sibling), rate limits, or behavior when no receipts exist.

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

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

Three sentences, front-loaded with the user-facing question, then the mechanism, then the safety profile. No restatement of the tool name and no filler; every clause carries information.

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

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

There is no output schema, but the description enumerates the returned fields (was/now price, discount, promo type, validity window, unit price), which compensates well. Combined with the read-only disclosure, the picture is nearly complete, with only auth/precondition detail missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds conceptual meaning: 'mines recent receipts' clarifies what days governs and 'purchase frequency' clarifies what min_times governs. It does not explain the category substring matching or how limit interacts with resolution of frequent items, so it stays just above baseline.

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

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

The description states a concrete verb chain (mine receipts → resolve to assortment product → report offers) against a named resource, and it is framed by the exact user question it answers. It is clearly distinguishable from siblings like jumbo_get_product_recommendations and jumbo_search_products, which do not combine purchase history with current promotions.

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 'of the things I actually buy, what is on offer right now?' framing gives an agent a clear condition for selecting this tool over a generic product search. However, it never names an alternative tool or states when NOT to use it (e.g. for browsing promotions on items you have never bought).

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Get' implies a read, and it usefully discloses the fields returned, but it says nothing about authentication, what happens when a transaction_id is not found, or any rate/error behavior. For a simple getter this is adequate but leaves real gaps.

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 front-loaded sentence with zero waste; the enumerated return fields earn their place because there is no output schema to convey them elsewhere.

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?

Because there is no output schema, the description correctly compensates by listing the returned fields, and with only one required parameter the input side is simple. However, with no annotations and no mention of failure or auth behavior, it stops short of being fully complete for an unannotated 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?

There is a single parameter with 100% schema description coverage, so the schema already documents transaction_id and its source. The description adds no format, prefix, or validation detail beyond what the schema supplies, making this the baseline case.

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

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

The description states a specific verb ('Get') and resource ('receipt details') and even enumerates the returned fields (line items, unit prices, discounts, total, payment method, Extra's points), which lets an agent distinguish it from jumbo_list_receipts and jumbo_search_receipts. It does not name those siblings explicitly, so differentiation is only implied by the 'specific Jumbo receipt' scoping.

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 tool versus jumbo_list_receipts or jumbo_search_receipts. The only hint about provenance lives in the schema ('from jumbo_list_receipts'), not in the description, so the agent must infer the retrieval workflow.

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

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

With no annotations, the description carries the full disclosure burden, and it does add value by spelling out the exact return contents (active status plus per-item fields). It remains silent on auth/permission requirements despite a jumbo_login sibling, and on error or empty-list behavior, so it is adequate but not rich.

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 verb and resource and then lists return contents without waste. The Dutch alias ('lijstje') is a cheap, useful disambiguation for a domain-specific name.

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 correctly takes on the job of describing the return payload, which it does thoroughly. Only minor gaps remain: no statement of auth requirements or behavior when the list is empty or inactive.

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, which is the baseline-4 case; the description correctly implies no filtering or identifier input is needed. There is nothing further for it to document.

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

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

States a specific verb and resource ('Get the user's Jumbo shopping list') and goes further by enumerating the returned payload (active flag, item id/term/sku/completed), which makes its role as the read-side counterpart to the add/remove/set siblings obvious. It never names those siblings explicitly, so it falls short of 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?

The description gives no when-to-use, when-not-to-use, or alternative tool guidance. An agent can infer it is the read operation for the shopping list, but nothing states prerequisites (e.g. that jumbo_login may be required) or when a different listing tool is preferable.

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

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

No annotations are provided, so the description carries the full burden. It implicitly establishes a read-only, non-mutating operation and discloses the shape of the returned data, but says nothing about authentication requirements (a jumbo_login sibling exists), error conditions, or whether results are cached/live. Adequate, not rich.

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 action first and the returned data enumerated after the colon. Every clause earns its place and there is no filler.

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

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

With no output schema, the description compensates well by naming the three categories of data returned, which is exactly what an agent needs to decide whether to call it. The only missing piece is the auth/prerequisite context implied by the presence of jumbo_login.

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 no parameter semantics to explain and the baseline of 4 applies. The description cannot and need not add anything 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?

The description gives a specific verb ('Read') and resource ('digital stamps') and then enumerates exactly what is returned: per-campaign stamp counts, active saving (spaar) campaigns, and the buying-stamps balance. This enumeration distinguishes it from adjacent read tools like jumbo_get_balance and jumbo_get_deposits without needing to name them.

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 verb 'Read' — an agent can infer this is the retrieval tool for stamp data. There is no explicit statement of when to prefer this over siblings such as jumbo_get_balance, nor any prerequisite (e.g. login) noted, so the guidance is adequate but thin.

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

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

No annotations exist, so the description carries the full behavioral burden. It names the returned fields (date, store location, transaction ID), which is genuinely useful, but says nothing about authentication/loyalty-account requirements (a jumbo_login sibling exists), sort order, or rate limits. 'List' weakly implies a safe read, but that is inference, not disclosure.

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, front-loaded with the verb and resource, with zero filler. Even the parenthetical '(kassabonnen)' earns its place by matching Dutch-language queries.

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, zero-required-parameter read tool, the description plus a fully documented schema is close to sufficient, and with no output schema the description usefully enumerates returned fields. It still omits default ordering, pagination limits beyond the schema, and any hint that login may be required.

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% for both parameters (page, page_size) including defaults and min/max bounds, so the schema does all the work. The description adds no pagination or page-size semantics, which is the expected baseline when coverage is complete.

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 (Jumbo supermarket store receipts) with a scope qualifier ('recent'), so the agent knows this is an unfiltered recent-receipts listing. It does not, however, distinguish itself from the sibling jumbo_search_receipts, leaving the list-vs-search split implicit.

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?

'Recent' hints at browsing recent receipts with no query filters, which implies search_receipts is for targeted lookups, but this is never stated. No when-not conditions, prerequisites (login?), or named alternatives are given.

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

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

With no annotations, the description carries full behavioral burden and does well: it discloses that the server uses persistent pre-configured Auth0 tokens (so no credential parameter is expected), that it verifies an active connection, and that it returns a user loyalty identity. Failure/expiry behavior is not described, but the auth model is clearly communicated.

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 primary action and followed by the mechanism/return context. No filler, though the second sentence is slightly packed with two ideas (auth model and return value).

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 no-parameter, no-annotation, no-output-schema tool, the description supplies the key missing context: the auth mechanism and what the call returns. It is nearly sufficient, missing only error/expiry handling that an agent might want to know.

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

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

There are zero parameters, so per the rubric the baseline is 4. The description correctly implies no input is needed, and nothing about parameter meaning is left ambiguous.

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

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

The description names a specific verb-and-resource pair ('check authentication status' / 'establish session with Jumbo'), which clearly distinguishes it from all the data-retrieval siblings in the list. Its purpose is unambiguous, though it does not explicitly contrast itself against any named sibling.

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

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

Usage is implied: an agent should call this to verify connectivity or start a session. There is no explicit when-to-use or when-not-to-use framing, and no ordering guidance (e.g. call before other tools), so the agent must infer the trigger condition.

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

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

With no annotations, the description carries the full burden, and it does important work: it flags that this WRITES to the user's real Jumbo account – a critical disclosure for a destructive operation. It doesn't cover reversibility or auth requirements, 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?

Three compact sentences, front-loaded with the action and resource, with the write warning and scope constraint earning their place. 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?

Given a single-parameter mutation tool with no output schema and no annotations, the description covers action, source of ids, write semantics, and scope. It stops short of noting what happens on failure or which account is affected, but is nearly complete.

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

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

Schema coverage is 100% and the single parameter item_ids is fully documented in the schema, so the description needn't add param detail. The description does note ids come from jumbo_get_shopping_list, which is useful but minor; baseline 3 is appropriate.

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

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

States a specific verb (remove) and resource (Jumbo shopping list items) with the identifier source. It clearly distinguishes itself from the inverse sibling jumbo_add_shopping_list_items and from read-only list tools like jumbo_get_shopping_list.

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

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

Names the source of ids (jumbo_get_shopping_list) and scopes the tool to the shopping list only, giving the agent clear context. It doesn't state explicit exclusions or alternatives for edge cases, so it falls just short of a 5.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose the shape of the response (prices, active discounts, unit prices, web links, SKUs), which is genuinely useful, but it says nothing about authentication requirements, rate limits, pagination behavior, or empty-result handling.

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 the purpose front-loaded and the return payload summarized second. There is no filler or repetition of the tool name.

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, but the description compensates by enumerating the fields returned, and the limit parameter bounds the result size in place of documented pagination. Only auth/permission context is missing, which is minor for a public catalog 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 description coverage is 100%, so all three parameters (query, limit, sort) are already documented in the schema, including the enum values for sort and the min/max for limit. The description adds no parameter-level detail beyond that, so the baseline of 3 applies.

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

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

States a specific verb (search) and resource (the entire Jumbo supermarket grocery catalog) scoped by keyword, and enumerates the returned fields. It is clearly distinguishable from siblings like jumbo_search_stores or jumbo_get_product_recommendations by resource, though it never explicitly names or contrasts them.

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: 'search ... by keyword' tells the agent this is the finder for products, but there is no guidance on when to prefer it over jumbo_get_product_recommendations, jumbo_search_stores, or jumbo_get_basket, and no exclusions or prerequisites 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?

No annotations are provided, so the description carries the full burden, and this is a low-risk read operation. It adds the meaningful qualifier that the search is limited to 'recent' receipts, but says nothing about authentication (jumbo_login exists as a sibling), result limits, matching semantics, 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 sentence that front-loads the verb and resource and spends its remaining words on scope and examples. Every clause earns its place and there is no filler.

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

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

For a simple two-parameter read tool with no annotations and no output schema, the description covers what is searched but not the shape of the result (matching line items vs. receipts, whether matches are aggregated per receipt, or ordering). The output schema does not exist to fill that gap, leaving moderate incompleteness.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema, establishing the baseline of 3. The description's examples do clarify that the query accepts Dutch product keywords and multi-word phrases, which is a modest addition over 'Product keyword to search for', but it says nothing extra about max_receipts.

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 ('search ... receipts') with a clear scope: grocery items purchased across recent Jumbo receipts by keyword. The examples ('havermelk', 'bio ei', 'skyr') pin down what a query looks like. It differentiates itself implicitly from jumbo_list_receipts and jumbo_get_receipt_details, but never names a sibling to make the distinction explicit.

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

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

Usage is implied rather than stated: an agent can infer this is for finding whether/where an item was bought, as opposed to looking up a single receipt. There is no explicit when-to-use, when-not-to-use, or comparison against jumbo_search_products (catalog) or jumbo_list_receipts (chronological listing).

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

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

With no annotations, the description carries the full burden, and it partially meets it by naming the return fields (address, distance, opening hours, facilities). It omits behavior that matters here: all three parameters are optional, so nothing explains what happens on an empty call, whether authentication is required, or how far 'nearby' extends.

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 with zero filler: purpose and accepted inputs come first, return contents second. Every clause earns its place and nothing is repeated from the 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 no-annotation, no-output-schema tool, the description is adequate: it covers input modes and return fields. It leaves gaps an agent would want filled — behavior when no arguments are supplied, auth requirements, and any limit on the number of stores or the search radius.

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 basline is 3: the schema already documents query as a Dutch city/address/postal code and gives coordinate examples. The description only restates the coordinate pair as latitude/longitude and adds no format, radius, or precedence rules for combining query with coordinates.

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 nearby Jumbo supermarket stores') plus the three search modalities (city name, address, coordinates), so an agent can immediately tell this apart from the product/receipt/shopping-list siblings. No ambiguity about what the tool returns or what it operates on.

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 the usage context (locating stores via one of three inputs) and no sibling tool competes for that job, so the alternative is implicit. However, it never states when to prefer query-based search versus coordinate search, nor that a query is unnecessary when coordinates are supplied. Guidance is implied, not 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?

With no annotations, the description carries the full burden, and it does disclose the key trait: this WRITES to the user's real Jumbo account. However, it omits auth/login prerequisites, whether the toggle is reversible, and any confirmation or side-effect details, so important behavioral context is still missing.

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 with zero filler; the core action is front-loaded and the clarifying exclusion follows immediately. Nothing redundant or padded.

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

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

For a one-boolean toggle with no output schema and no annotations, the description covers the action, the target account, and the negative scope, which is nearly everything needed. Only the write's prerequisites and result behavior are left unaddressed.

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 boolean parameter with 100% schema description coverage ('true to activate, false to deactivate'), so the schema already does the work. The description restates the activate/deactivate meaning but adds no syntax or edge-case detail beyond it, making the baseline 3 appropriate.

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

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

States a specific verb pair (activate/deactivate) and resource (the user's Jumbo shopping list / 'lijstje'), which cleanly separates it from jumbo_get_shopping_list, jumbo_add_shopping_list_items and jumbo_remove_shopping_list_items. The parenthetical alias also helps an agent map it to the user-facing term.

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

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

Gives clear usage context (toggle the list on/off) and an explicit when-not ('it does not add or remove items'), which steers the agent away from the item-mutation siblings. It stops short of naming those alternative tools, so routing is inferred rather than spelled out.

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

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

With no annotations provided, the description carries the full burden, and it does disclose the most important behavioral trait: this WRITES to the user's real Jumbo account, with capitalization for emphasis. It also clarifies both directions of the operation (toggle on and off). It does not cover auth requirements, idempotency, or error behavior, so it falls short of a complete disclosure.

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, front-loaded with the action and its two modes, followed by the critical write disclosure. No filler text.

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

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

For a two-parameter tool with full schema coverage and no output schema, the description covers the action, both parameter meanings, and the account-write risk. Remaining gaps (auth/permission requirements) are modest given the schema already points to jumbo_get_shopping_list as the source of item_id.

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

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

Schema description coverage is 100%, and both parameters are documented there, including where item_id comes from. The description's mapping of completed=true to 'tick off' and false to 'un-tick' restates the schema rather than adding new semantics, so the baseline of 3 applies.

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

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

Specific verb ('tick off / back on') on a specific resource ('an item on the user's Jumbo shopping list'), with the boolean semantics stated inline. It is clearly distinguishable from siblings like jumbo_add_shopping_list_items and jumbo_remove_shopping_list_items, which modify the list rather than an item's completion state.

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, but there is no explicit when-to-use guidance relative to siblings (e.g., 'use jumbo_get_shopping_list first to obtain item_id', or how this differs from removing/adding items). No prerequisites or exclusions are stated in the description itself.

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