Lenius

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world. The description adds real value beyond them by disclosing the date default behavior and the shape of the result (next dates, preparation time, upcoming closed days), which is exactly the context an agent needs for a read-only query.

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 dense but well-formed sentence that front-loads the core purpose and appends the default behavior and return contents. Nothing is wasted, though the parenthetical default slightly interrupts the flow.

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

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

There is no output schema, so the description carries the burden of describing returns, and it does: available times, next dates, preparation time, and closed days. Combined with full schema coverage and rich annotations, an agent has enough to call the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning the schema lacks: the date parameter's default (the first date with times), which the schema only labels 'YYYY-MM-DD'. It also implies the shop/fulfillment pairing through context. 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?

States a specific resource (available pickup/delivery times for a shop on a date) with additional scope (next dates, preparation time, closed days). An agent can tell this is an availability-lookup tool, distinct from order_status or quote_order, though it never names a sibling to sharpen the distinction.

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 — check availability before placing an order — but there is no explicit when-to-use, when-not, or mention of an alternative tool. The 'default: the first date with times' tells the agent the date param is optional without stating when to omit it.

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

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior. The description adds useful context by saying 'Saves nothing' and enumerating the result fields, which matters because no output schema exists; it does not cover auth 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?

A single dense sentence front-loads the core question and then lists returned values. It is compact with little waste, though the list of outputs makes it somewhat long.

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 check with no output schema, the description is fairly complete because it explains returned values and the no-save behavior. It still omits usage guidance and parameter semantics, which are meaningful gaps for a nested-address 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 50%, and the description adds no parameter-level meaning beyond saying 'to an address.' It does not explain the optional shop parameter, its find_shops linkage, or the nested address fields, leaving the schema to carry the limited documentation that exists.

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 check: whether a shop delivers to an address, plus delivery fee, thresholds, minimum order, other fees, and next delivery time. It is clearly more than a tautology, but it does not explicitly distinguish itself from siblings such as quote_order or validate_cart.

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

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

No when-to-use guidance or exclusions are provided. Mentioning that calculation is the same as checkout implies consistency, but it does not tell an agent when to choose this tool over quote_order, validate_cart, or checkout-related 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?

Goes beyond the annotations (readOnly, idempotent, non-destructive) by explaining a real behavioral quirk: shops do not track quantities, so quantity is always null. It also discloses that quote_order re-verifies at order time, which matters for an agent deciding how much to trust the result.

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 outcome definition, then the null-quantity caveat and the ordering cross-reference. 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 read-only, no-output-schema availability check, the description covers what is returned conceptually (available/sold out, null quantity) and when results may change. Only return-format/pagination-style details are absent, which is minor here.

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

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

Schema coverage is only 50%, and the description adds no meaning about the two parameters. It never mentions product_ids (including the max of 50 items) or the shop parameter's conditional requirement, so it does not compensate for the coverage gap.

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

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

States a specific check ('Whether products can be ordered now') with the two possible outcomes (available or sold out), which is more concrete than the title. It does not explicitly differentiate itself from siblings like get_product or search_products, but the verb+resource are unambiguous.

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; the closest thing to guidance is the note that 'quote_order checks again when ordering', which hints this check is not required before ordering. There is no explicit when-to-use/when-not-to-use framing or named alternative for availability checks.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds real value beyond them by disclosing what is returned — including derived fields like price per kg and a comparative summary (cheapest, most expensive, which have sizes or required choices) — which tells the agent the output shape without an output schema.

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

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

Two sentences, front-loaded with the verb and scope, then the required input source. The attribute list is dense with parentheticals but every element is informative; only the nested parentheses ('price (and sizes, price per kg)') slightly hurt scannability.

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 results, and it does so thoroughly including the summary semantics. Only minor gaps remain: nothing about error behavior when an ID is invalid or belongs to another shop, and the shop parameter's scoping rule is left entirely to the schema.

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

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

Schema description coverage is only 50%, but the description compensates by restating the 2–5 cardinality (matching minItems/maxItems) and the origin of product_id values. The 'shop' parameter and its 'from find_shops' / own-address exemption are documented in the schema but not reinforced here, leaving a small gap.

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

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

Specific verb ('Compare') plus resource ('2–5 specific products side by side') and an explicit enumeration of the compared attributes (price, sizes, price per kg, description, options, age limit, prep time, availability). It is clearly distinguishable from get_product (single product detail) and search_products (discovery) by the string of comparison dimensions and the summary output.

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

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

States the use case precisely — comparing 2–5 already-identified products — and tells the agent where the required inputs come from ('Get product_id from search_products or get_menu'), which is the critical routing instruction. It stops short of naming an explicit alternative or exclusion (e.g. 'use get_product for a single item's full detail'), so it is strong but not fully specified.

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 a safe, idempotent, closed-world read, so safety needs no restating. The description adds genuinely non-obvious behavior: passing a date/time makes the call return the nearest available times, not just a static shop list. It stops short of describing the overall result shape or any result cap.

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 front-loaded sentences with the location requirement first and the refinements second. The 'Optional:' enumeration mildly duplicates what the schema already lists for the same five parameters, costing a little density but nothing confusing.

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

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

There is no output schema, so the description carries the burden of explaining returns — it covers only the availability-times case and is silent on what a shop result contains and on behavior when city/postal_code are omitted (all six params are optional). Adequate but leaves real agent questions unanswered.

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 every parameter (city, date, time, query, fulfillment, postal_code) is already documented with format and examples in the schema. The description paraphrases query, fulfillment, and date/time without adding syntax, defaults, or edge-case meaning beyond what the schema provides — the baseline 3.

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

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

States a concrete verb and resource ('Find Lenius takeaway restaurants and shops') plus the required locator (Danish city or postal code). This is clearly distinguishable from siblings like get_menu, place_order, and available_times, which operate on a shop once known.

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 frames query, fulfillment, and date/time as optional refinements and hints that supplying date/time triggers availability checking, but it never states when to prefer this tool over the sibling available_times, nor what happens if no city/postal_code is supplied. Usage is implied, not prescribed.

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

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

Annotations already give the safety profile (readOnlyHint=true, destructiveHint=false), so the description only needs additive context — and it supplies the full status lifecycle plus the long-poll behavior of wait_seconds, which is a real runtime trait. The note that 'while pending, the card shows the AltID QR code again' discloses a UI side effect the caller would not otherwise expect.

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

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

Three short sentences, front-loaded with the status vocabulary, then the wait semantics, then the pending-state UI note. Every clause carries information an agent needs; 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?

With no output schema, the description correctly takes on the burden of enumerating return states, which is the main thing the caller needs. It leaves minor gaps — e.g. behavior on an unknown/expired-too-long id and whether repeated polling is expected — but is largely self-sufficient.

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

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

Schema coverage is 50%: wait_seconds is already documented in the schema (including the 25-second cap), so the description's restatement adds little. age_check_id has no schema description, and the description only implies its role (something you pass to place_order) rather than explaining where it comes from — likely start_age_check. Minimum-viable for a two-parameter tool.

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 ('Status of an age check') and enumerates the exact state values the tool can report (pending, approved, failed, expired, revoked), which no sibling does. This clearly separates it from start_age_check, which initiates the flow rather than reporting on 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?

Explicitly routes the agent forward: 'approved (pass age_check_id to place_order)' tells it what to do with the result, and 'wait_seconds (max 25) waits while pending' tells it when to poll versus return immediately. No statement of when not to use it or what happens for the non-pending terminal states.

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

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

Annotations already declare this as a safe, read-only, idempotent operation, so the description does not need to repeat that. It does add useful behavioral context by enumerating the kinds of requirements returned, including terms_url, age checks, minimum order values, fees per fulfillment, and login alternatives, which is valuable because no output schema exists.

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

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

It is a single dense sentence listing many returned fields, so it is reasonably concise but not well structured for scanning. A short front-loaded statement of purpose followed by grouped return categories would be clearer.

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?

Without an output schema, the description carries the burden of explaining return content, and it does so fairly comprehensively by listing customer details, address, time, terms, payment, comment, age check, minimum order, fees, and login options. It is still incomplete on usage context and does not explain the shop parameter, but the core return shape is covered.

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 description links fulfillment to minimum order and fees, and product_ids indirectly to age-limited products, adding meaningful semantics beyond the enum and schema notes. The shop parameter is not explained in the description, but its schema description already covers the main nuance about shop address contexts.

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 the concrete resource: what is needed before ordering at a shop, including customer details, delivery, terms, payment, age checks, and fees. It is clearly a checkout-requirements lookup rather than an order-placement tool, though the verb is implicit rather than explicitly stated.

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

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

The phrase 'before ordering' implies when the tool is relevant, but the description does not explicitly compare it to alternatives such as validate_cart, get_shop_policies, or quote_order. It also does not state when this tool should not be used.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description adds genuinely useful context that this is a computed estimate from the shop's time rather than a GPS-derived figure, setting accuracy expectations, but says nothing about failure modes or freshness.

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 clauses with zero waste, and the substantive answer (what 'expected time' means) is front-loaded ahead of the clarifying caveat.

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 explains the composition of the returned value (chosen time + delay + minutes left). For a simple read-only lookup whose parameters are fully documented in the schema, this is close to complete, missing only how to interpret the result when no ETA exists.

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 (shop, order_id) are already documented with their sources (find_shops, place_order/my_orders). The description adds nothing about parameters, 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 states the resource precisely: the expected ready-for-pickup or delivery time, derived from chosen time plus shop delay. An agent can distinguish it from status tools like get_delivery_status or check_delivery by the 'estimate, not GPS' framing, though it does not name a 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: call this to learn when an order will be ready or delivered. There is no explicit when-to-use/when-not guidance and no named alternative (e.g. get_delivery_status for actual progress vs. ETA), leaving the agent to infer the routing.

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 annotations already establish this as a safe, idempotent read operation, and the description adds useful behavioral detail about the returned timeline, included timestamps, delay information, and data source. It does not discuss auth, rate limits, or exact response shape, but those gaps are less critical for a simple read tool with annotations.

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

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

The description is a single front-loaded sentence with no wasted framing. The timeline list and source clarification both earn their 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 two-parameter read tool with full schema coverage and no output schema, the description sufficiently explains what the returned timeline contains and what source it reflects. It could be slightly more complete by clarifying when to choose it over the other status-related siblings.

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

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

Schema description coverage is 100%, so both shop and order_id are already well documented in the schema. The description adds little parameter-specific meaning beyond saying the status is for an order.

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 clearly states that this returns an order's current status as a timeline and enumerates the stages returned, including times and delays. It also scopes the source as the shop rather than live courier tracking, but it does not name any sibling tool it should be preferred over.

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 clear usage boundary: use this for shop-sourced order status, not live courier tracking. However, it does not explicitly compare against nearby siblings such as order_status, check_delivery, or get_delivery_eta.

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

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

Annotations already declare read-only, idempotent, non-destructive, closed-world, but the description goes well beyond them with domain semantics an agent needs: prices include VAT, unit-based pricing (pcs, portion, pack, kg, g, l, cl, ml, m), weight in grams, preparation time in minutes implying minimum order notice, and the main image when set.

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

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

Front-loads the resource and packs field semantics into a compact paragraph, though the unit/prep-time clause is dense and slightly run-on. Every sentence still carries information an agent needs to interpret the menu output.

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 properly carries the return-value burden by describing categories, products, pricing/currency/VAT, availability, units, weight, prep time, and images. Combined with the 100% schema coverage, an agent has everything required to call and interpret the tool.

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

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

Schema description coverage is 100%, so both parameters are already documented; the description only restates that query filters matching products and that shop comes from find_shops, which the schema says itself. Baseline 3 is appropriate since it adds no syntax or format detail beyond the schema.

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

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

States a specific verb+resource ('The menu of a shop from find_shops') and enumerates the returned fields (categories, products, prices in DKK incl. VAT, availability). It explicitly ties itself to the sibling find_shops, so an agent can distinguish it from available_times, order_status, quote_order, and place_order.

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 a shop's menu, optionally narrowing with a query, with the shop value sourced from find_shops. However, there is no explicit when-to-use/when-not guidance and no mention of how it relates to ordering siblings like quote_order or place_order.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered; the description adds real value by disclosing the shape and breadth of the payload (special days, computed open-now status, closed periods for orders). It does not address data freshness or how 'open now' is evaluated, which keeps it from a 5.

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

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

A single dense sentence that front-loads the resource and ends with the routing hint to available_times; every clause names a concrete return component. Slightly packed, but 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?

There is no output schema, so the description carries the burden of conveying return contents, and it does so by enumerating all the major data groups. Remaining gaps (format, whether hours are timezone-local) are minor for a read-only lookup.

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 explains that 'shop' is the value from find_shops and is unnecessary on a shop's own address endpoint. The description adds nothing about the parameter, so the baseline of 3 applies.

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

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

The description enumerates exactly what the tool returns: weekly hours, special days (holidays, closed days, changed hours), current open status, and per-day order-placement windows with closed periods. That granularity lets an agent distinguish it from available_times without guessing.

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

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

It explicitly routes the agent to a sibling: "Use available_times for the exact times on a date," which implies this tool is for the general weekly/special-day overview. It stops short of stating exclusions relative to other shop-metadata siblings like get_shop_info, so it isn't fully exhaustive.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real value by enumerating the returned payload (status values, delay, items, total, order_url, seller), which matters because there is no output schema. It omits whether 'delay' is a field or a modifier and says nothing about errors for unknown order_ids.

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

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

A single sprawling sentence that leads with the return payload rather than the action, and buries the one routing hint ('Same as order_status') at the very end. The status enum list consumes most of the text, pushing the purpose and usage signal out of the front-loaded position.

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

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

For a two-parameter read with no output schema, enumerating return fields is the right instinct and mostly covers the gap. But ambiguity around order_status redundancy and the lack of any failure behavior leave the agent with open questions before calling.

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

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

Schema description coverage is 100%, with order_id explained as coming from place_order or my_orders and shop explained via find_shops. The description adds nothing beyond that, so baseline 3 applies.

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

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

The description identifies the specific resource and enumerates exactly what it returns: status enums, items, total, order_url, seller. It is a noun phrase rather than a verb-led statement, but an agent can still tell it fetches a single order. The closing 'Same as order_status' hints at the closest sibling, though ambiguously.

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 use this versus order_status, my_orders, or quote_order. 'Same as order_status' is the only nod to an alternative and it reads more like a duplication notice than a routing rule, leaving the agent unsure which of the two to 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?

Annotations declare readOnlyHint=false, and the description explains exactly why: if the payment could not be created before, it is started again — a disclosed side effect that reconciles with the non-read-only hint rather than contradicting it. It also discloses the degenerate output cases (paid/cancelled/expired) and the security-relevant constraint that no direct provider link is returned.

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 with the primary output (order_url, QR code) front-loaded, followed by fallback behaviors. The parenthetical quoting of 'Betal nu' is slightly noisy but earns its place by clarifying the page 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 carries the return-value burden and does so: it names order_url, a QR code, and the alternative notice messages for non-payable orders. An agent knows what to expect back in every state without opening anything else.

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

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

Schema description coverage is 100%, with order_id sourced from place_order and shop sourced from find_shops already documented in the schema. The description adds no parameter-level 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?

States a specific resource and return content: the shop's order page URL (order_url) plus a QR code for paying an order, and explicitly rules out a direct payment-provider link. The distinction from get_payment_status is implied by the 'link vs. status' framing, but no sibling is named outright, keeping it at 4 rather than 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?

Gives clear conditions: it applies while the order can still be paid, it retries payment creation if that previously failed, and it returns a notice instead for paid/cancelled/expired orders. That is solid conditioning, though it never explicitly routes the agent to an alternative sibling (e.g. get_payment_status) for those terminal states.

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 description says 'If the customer has paid, the order is updated as on the order page,' which implies the tool can mutate order state as a side effect. This contradicts the readOnlyHint=true annotation, so behavioral transparency is seriously compromised.

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

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

The description is front-loaded with the core purpose and then lists relevant status values and the important side-effect caveat. It is dense but every sentence adds useful 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 does a good job of explaining the returned status categories and amount. It also warns about a possible order update, though that warning creates the annotation contradiction rather than resolving 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 coverage is 100%, and both parameters are documented in the input schema, so the baseline is 3. The description does not add parameter-specific guidance 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 states a specific verb and resource: it looks up the actual payment status of an order at the payment provider now, not merely the stored status. It also enumerates the possible statuses and notes the amount, so an agent can distinguish it from stored-order or general order-status tools.

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

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

The description makes clear this is for retrieving the current provider-side payment state rather than the stored order state. It does not explicitly name alternative tools or when-not-to-use conditions, but the usage context is clear.

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

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

The description provides rich context about the returned payload—listing specifics like 'age limit,' 'preparation time,' and 'availability.' This goes beyond the behavioral safety provided by annotations (like readOnlyHint: true), setting clear expectations for the content the agent will receive.

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 tool value proposition is condensed into a single, powerful sentence. There is no filler, and the key differentiators are front-loaded and immediately visible.

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

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

Given the detail provided in the description about the output structure (price, variants, availability, images), the description is highly complete and gives the agent sufficient information to determine if this tool will fulfill a user's complex request.

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?

Since schema coverage is 100%, the baseline is 3. The description adds value by specifying that 'variants' contain 'their own price,' which describes a specific structural detail about the return data complexity that is not explicitly mandated by the simple input 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 provides an extremely specific scope by detailing the exact information included (full description, DKK price, all images, variants, etc.). This distinguishes it clearly from sibling tools that only handle specific subsets of data, like 'check_stock' or 'get_product_options'.

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 does not explicitly guide the user on when to choose this tool over others (e.g., comparing it to get_product_options). However, the implied usage is clear: use it when the goal is to retrieve a comprehensive view of a product that is already identified.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuine value by noting the prices come back in the exact shape quote_order/place_order accept, which is a non-obvious behavioral contract; it says nothing about pagination, missing options, or failure behavior.

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

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

A single dense sentence that front-loads the resource and then the payload detail, with no throat-clearing. It is slightly packed — the middle clause listing option kinds runs long — but every element 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?

With no output schema, the description takes on the burden of describing returns and does so competently: option kinds, required flags, option_id/choice_id, and price format. It doesn't describe overall response shape or how to handle products with no options, leaving a small gap for an agent parsing the result.

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

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

Schema description coverage is 100% and both parameters (shop, product_id) carry their own guidance, including where to source the values from. The description adds no parameter-level detail, so it sits at the baseline where the schema does all the work.

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

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

The description names the resource precisely ('the options of a product') and enumerates what those options contain (sizes, extras, ingredients, free text, required flags, ids, prices), which is well beyond restating the name. It stops short of an explicit verb like 'returns' and doesn't contrast itself with the closely related get_product sibling, so an agent still has to infer 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?

The reference to 'the format quote_order and place_order take' implicitly tells the agent this is a pre-ordering lookup, which is useful routing signal. However, there is no explicit 'use this when…' instruction and no stated exclusions (e.g., when to prefer get_product or search_products instead).

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only the payload contents, with no mention of auth needs, visibility restrictions (e.g. whether private fields are omitted per caller), 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 compact sentence with no filler, and the field enumeration is front-loaded. It loses a point only because the missing verb makes it read as a field list rather than a statement of action.

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

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

No output schema exists, so the description carries the burden of describing return contents — and it does enumerate the returned fields thoroughly. Combined with the fully documented single parameter, an agent has enough to call it correctly, though a short usage sentence would close the remaining 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% and the single `shop` parameter already documents its origin and the optional-case for a shop's own address. The description contributes nothing about the parameter, so baseline 3 applies.

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

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

The description enumerates what the tool surfaces (name, address, CVR, socials, pickup/delivery flags), which makes the resource recognizable, but it is a noun-phrase fragment with no verb and no differentiation from the sibling `find_shops`, which is the tool an agent would most plausibly confuse it with.

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 `find_shops` or the other shop-scoped tools; the only routing hint ('the shop value from find_shops') lives in the schema, not the description. Use context is implied by the field list at best.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description still adds real value by disclosing the breadth of returned content (withdrawal rights, payment, cancellation rules, fees, minimum order, company details), which is important given there is no output schema.

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

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

One sentence, front-loaded with the resource and then the enumerated contents. The list is dense but every item is meaningful content disclosure; no filler sentences.

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 return contents and does so thoroughly; the parameter is fully documented in schema. The remaining gap is sibling differentiation against get_shop_info, which an agent might reasonably confuse.

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 optional parameter with 100% schema description coverage, including the exact provenance ('shop' value from find_shops) and the own-address shortcut. The description adds nothing beyond the schema, but the baseline for a fully documented single parameter is a 4.

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

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

The description enumerates the concrete policy content returned (terms of sale, privacy, delivery, returns, complaints, right of withdrawal, fees, minimum order, seller company details), so an agent knows exactly what resource this fetches. It does not, however, distinguish this from the closely named sibling get_shop_info, leaving that boundary to inference.

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

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

There is no statement of when to call this versus alternatives such as get_shop_info or find_shops. The only contextual hint (shop param not needed on a shop's own address) lives in the schema, not the description, so the description itself provides no 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?

Annotations already declare this is a safe read-only, idempotent lookup. The description adds useful behavioral context by explaining that it returns phone, e-mail, and open-now status for shop contacts, and that it routes certain topics to Lenius support. It does not clarify what Lenius support returns or how missing contacts are handled.

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

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

The description is a single front-loaded sentence with no filler, and the purpose is stated first. Its parenthetical topic lists make it dense, but it remains appropriately sized for the amount of routing information conveyed.

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 required parameters, the description should clarify return values and optional-parameter behavior. It covers the main routing and contact fields but omits order_id semantics and what happens when shop or topic is absent.

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

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

Schema description coverage is 67%, so the description must add meaning. It helpfully maps topic groups to shop versus Lenius support, but the order_id parameter remains unexplained in both schema and description.

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 clearly communicates that the tool retrieves the right support contact, and it distinguishes between shop contacts and Lenius support based on topic. However, it lacks an explicit verb and does not name sibling tools, so the purpose is clear but sibling differentiation is 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?

The description implies when to use the tool by listing question topics such as orders, delivery, refunds, and technical problems. It does not state when not to use it, nor does it point to alternative sibling tools for related information.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds valuable behavioral context by enumerating the possible status values and noting delays, which compensates for the absent output schema.

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

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

A single front-loaded sentence that names the resource, its source, and the possible return values with zero waste. The status enumeration is useful for a tool without an output 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 simple read-only lookup with full schema coverage and no output schema, the description provides the missing return-value information (status list and delay note). Nothing essential for correct invocation is absent.

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

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

Schema description coverage is 100%, so the schema already documents both order_id and shop. The description adds no additional syntax or meaning beyond saying order_id comes from place_order, which the schema also states. 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?

The description states the resource (an order's status) and ties it to the place_order sibling, which is more than a tautology. It doesn't explicitly distinguish itself from get_menu or quote_order, but the order-specific framing makes its scope clear.

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 'from place_order': after placing an order, use this to check its status. There is no explicit when-not guidance or mention of alternative status-checking tools, so it meets the minimum viable bar.

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?

Beyond the annotations, the description discloses the payment model (card in advance on the shop's order page), when the shop receives the order, the confirmation e-mail trigger, and the age-check failure behavior. This is substantial behavioral context for a tool that performs a real commercial action.

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 dense but appropriate for a complex checkout workflow. It is front-loaded with the main action and follows with payment, confirmation, and age-check conditions, though the single paragraph could be more scannable.

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

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

For an 11-parameter, nested, no-output-schema tool, the description covers the critical workflow, payment state, key return values, and the important age-check fallback. It does not describe every failure mode or the role of other_stops, but the schema covers those details adequately.

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 high at 82%, so the schema already explains most parameters. The description reinforces accepted_terms and age_check_id semantics but largely repeats what those schema descriptions already say, so it meets the baseline rather than adding much new parameter-level meaning.

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: placing an order with a shop, framed as checkout. It distinguishes itself from the quote step by requiring the customer to have confirmed the quoted order and accepted terms, and it names the key return values (order number, order_url).

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

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

It gives explicit preconditions: only after the customer confirmed the quoted order and accepted terms. It also describes the age-limit branch clearly: without an approved age_check_id nothing is ordered, and the agent should call again with age_check_id once age is confirmed.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered; the description reinforces with 'Nothing is saved' and adds valuable output context (a card with product images, fees, and total) that annotations do not convey. It also flags validation behavior (checks time, products, minimum order, address), though it does not mention the trip_warnings output the schema hints at.

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?

Information-dense and mostly front-loaded: pricing scope first, then validation, then the no-persistence note and the workflow instruction. The long third sentence is somewhat run-on but each clause carries distinct 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 7-parameter tool with nested objects and no output schema, the description covers purpose, validation, persistence, and the shape of the returned card well enough to call it correctly. Minor gap: it doesn't surface the trip_warnings/warning behavior implied by other_stops.

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 71%, so most parameters (date/time from available_times, items options, address for delivery, other_stops) are already documented in the schema. The description restates the validated concerns (time, products, minimum order, address) but adds no syntax or format detail beyond the schema, 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 specific verb (price/quote) plus resource (order) and scope (lines, fees, discounts, total in DKK incl. VAT), and explicitly distinguishes itself from the sibling place_order by naming it as the follow-up step. An agent can tell it apart from place_order and order_status without opening either schema.

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

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

Clearly routes the agent: quote first, show the customer, then call place_order. The 'Nothing is saved' framing implies this is the non-committing preview versus the committing sibling. It lacks an explicit 'do not use for X' exclusion, but the workflow 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?

Annotations already declare it as a read-only, idempotent, closed-world lookup, so safety is covered. The description adds genuine value by enumerating the returned fields (product_id, price in DKK incl. VAT, availability, image, has-options), which matters because there is no output schema.

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

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

Two sentences, front-loaded with the action and the searchable fields, followed by the return shape. No filler; slightly long single sentence in the first half but 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?

For a simple 3-parameter read tool with full schema coverage and no output schema, the description supplies what's missing: what fields are matched and what comes back. Pagination/limit behaviour and the shop-scoping rule are left to the schema, which handles them adequately.

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 documents shop, limit (default 20, max 50) and query constraints, so the schema does the heavy lifting. The description's example query strings add usable flavor for the query parameter but nothing beyond that—baseline 3.

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

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

Names a specific verb and resource (search products) and specifies the searchable fields (name, description, category) with concrete example queries. It doesn't contrast itself with siblings like get_product or get_menu, but the 'free-text search' framing is distinguishable on its own.

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 query examples, but there is no explicit guidance on when to use this versus get_product (known id), get_menu, or check_stock, nor any note that the shop parameter is required unless calling from a shop's own address. Schema covers the shop caveat, so the description doesn't contradict—it just doesn't route.

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 cover the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), and the description adds substantial context beyond them: the 30-minute post-approval validity window, cross-shop reuse of the id, and the self-updating AltID card behavior. It also warns 'Never make your own QR code', a genuine operational constraint.

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 critical condition ('Only when... several shops') is front-loaded, and every sentence carries information. Slightly run-on parentheticals make it denser than ideal, 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?

No output schema exists, and the description implicitly conveys the return (an age_check_id to reuse) plus the visible card behavior. Complete enough for a one-parameter tool, though the returned payload shape is only inferable.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: min_age should be the highest age limit across all the orders and is sourced from get_menu/quote_order. This goes beyond the schema's bare 'The age to confirm, e.g. 18'.

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 ('start one age check with AltID') and immediately distinguishes itself from the sibling place_order for the single-shop case. An agent can tell exactly what this tool creates and when it differs from alternatives.

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

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

Explicitly scopes use to multi-shop orders containing age-limited products, names the exclusion (single-shop orders should call place_order, which shows the card itself), and instructs how to reuse the returned age_check_id. When/when-not/alternative are all present.

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 establish read-only, idempotent, non-destructive behavior, and the description adds meaningful context: all item problems are returned at once with per-item pricing, fulfillment parameters trigger additional time/address/minimum-order checks, and nothing is saved. It could say more about the returned problem structure, but it adds solid value beyond annotations.

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

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

The description is front-loaded with the core validation purpose and uses one dense but efficient sentence. It packs a lot of useful information without obvious repetition, though it is somewhat compressed.

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 complex tool with six parameters, nested option objects, and no output schema, the description covers the main validation dimensions and explicitly states non-persistence. It omits the 'shop' parameter context and the exact shape of validation responses, but remains largely 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 67%, and the description explains the conditional roles of fulfillment, date, time, and address. However, it does not mention the 'shop' parameter's context or add much detail about the nested option structures beyond what the schema already provides; 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?

The description uses a specific verb and resource ('Check a cart') and clearly frames the tool as pre-quote validation that 'saves nothing', which separates it from quote_order/place_order. It does not explicitly distinguish itself from related check_stock/check_delivery tools, keeping it just shy 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?

It implies the use case ('before quoting') but gives no explicit when-not guidance and does not name alternatives such as check_stock, check_delivery, quote_order, or get_checkout_requirements. The workflow context is useful but incomplete.

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