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 safety profile ('Read-only'), which is the single most useful trait here, but says nothing about permissions, freshness/refresh behavior, or ordering of results.

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 lines, zero waste, with the core purpose front-loaded and the sibling disambiguation immediately after. 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 zero-parameter read tool with an output schema, the description supplies everything an agent needs: what it returns conceptually, that it is non-mutating, and where the adjacent data lives. Return-value details are already covered by the output schema.

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

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

The tool takes zero parameters, so the baseline is 4; there is no argument syntax for the description to explain. Nothing in the text adds or detracts from parameter 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?

States a specific resource and its contents ('Currently tracked orders with status and ETA'), and explicitly disambiguates from the sibling order_history by contrasting in-progress vs. past orders. An agent can select this tool 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?

The description names the alternative (order_history) and the condition that selects it (past orders), which is exactly the routing an agent needs. It stops short of stating an explicit 'do not use this for X' rule or noting any prerequisite, so it is clear context rather than exhaustive 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?

With no annotations, the description carries the full burden and does so well: it discloses increment-on-duplicate semantics, that no charge occurs, that price is server-validated on write, and a real cross-store stocking hazard with the exact fields (cart warning, item.unavailable_on_depot) to inspect afterward.

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 core action and the no-charge fact, then layers parameter notes and the depot warning in scannable paragraphs. Slightly verbose, but every section carries actionable 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?

An output schema exists, so return-shape detail isn't required, yet the description still tells the agent exactly which returned fields to check. Combined with the mutation semantics and store-availability caveat, it covers everything needed to invoke and recover from this cart write.

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 0%, so the description must compensate; it explains product_id's provenance (the id from a search result) and price's origin and validation, which adds real meaning. Quantity is left undocumented, so it does not fully cover all three parameters.

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

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

States a specific verb+resource ('Add a product to the cart') plus a non-obvious behavioral qualifier ('increments if already present', 'No charge'), which distinguishes it from sibling update_cart_item that overwrites/removes items.

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

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

Explicitly routes to the sibling alternative ('drop any flagged item with update_cart_item(id, 0)') and says when to pass price. It implies but does not state the prerequisite flow (search_products -> add_to_cart -> view_cart), so it falls just short of full when/when-not guidance.

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

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

With no annotations, the description carries the full behavioral burden and largely fails it. Cancellation is a mutation that is typically irreversible, yet the description says nothing about reversibility, side effects such as refunds or stock release, required permissions, or error conditions for orders that cannot be cancelled.

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 zero filler. The action is stated first and the id source is appended compactly, which is exactly the right shape for a one-parameter tool.

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

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

The output schema exists, so return values need not be described. But for a destructive, unannotated mutation tool with an undocumented parameter, the description omits the irreversibility and precondition details an agent needs to invoke it safely, leaving it only minimally 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 0%, so the description must compensate for the single order_id parameter. It does add real provenance value by naming the tools that produce a valid id, but it says nothing about the id's format or validity constraints, so it only partially compensates for the coverage gap.

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

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

States a specific verb and resource ("Cancel an order") plus the identifying parameter ("by id"), which is unambiguous and distinct from every sibling tool. It stops short of explicitly contrasting itself with siblings, but no sibling offers cancellation, so differentiation is effectively 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 parenthetical points the agent at where the id comes from (confirm_order/active_orders), which implies the usage context: cancel an order you previously confirmed or listed. However, it never states when not to use it, prerequisites (e.g. only before shipment), or whether the order must be in a particular state.

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?

Without annotations, description fully discloses that the tool charges nothing (safe, read-only) and describes behavior for error cases (order will be refused and requires cart fixes). No side effects are omitted.

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

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

Four sentences, each serving a distinct purpose: purpose, cost clarification, usage flow, error handling. No redundancy or fluff; well-structured and front-loaded.

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

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

Given no parameters and the presence of an output schema, the description adequately covers what the preview contains and how to handle warnings. No missing context for a preview 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?

No parameters exist, so schema coverage is 100% and description adds no parameter info. Baseline for 0 parameters is 4, and no additional semantics needed.

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?

Description clearly states the tool previews the order including items, delivery fee, ETA, address, payment, and total. It is a specific verb-resource pair that distinguishes it from sibling tools focused on location, addresses, and products.

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 instructs to always run before confirming order, to show total to user and ask for confirmation, and details conditions (warning, available_for_checkout false, unavailable items) that require fixing the cart and re-previewing. Provides clear when-to-use and when-not-to-proceed 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?

With no annotations, the description carries the full burden. 'No charge' usefully clarifies this is a cart mutation and not a checkout/payment action, but it omits whether removal is reversible, whether it clears pending orders, or whether confirmation is needed.

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

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

Two short, front-loaded sentences with no filler. The destructive action is stated first and the financial clarification second.

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

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

An output schema exists, so return values need no explanation, and the tool takes no parameters. For a simple no-arg mutation, the description covers the key ambiguity (no financial impact); only reversibility/confirmation behavior is left unstated.

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

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

Zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. Schema coverage is 100% and the empty argument object is self-explanatory.

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 ('Remove everything from the cart') with an explicit scope ('everything'), which distinguishes it from add_to_cart and update_cart_item by implication. It does not name a sibling tool 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?

There is no statement of when to use this tool, when not to, or which alternative (e.g. update_cart_item for partial removal) applies. Usage is only inferable from the name and description.

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 and it does so richly: 'Irreversible — real money', refusal conditions (recent preview, matching confirmed_total, cart version/total match at submit), the drift behaviour ('nothing is charged'), and the 3-D Secure wait_user_action flow with redirect_url. These are exactly the traits an agent needs before invoking a money-moving operation.

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

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

Front-loaded with the verb and the risk warning, then ordered preconditions, then the return semantics. The 3-D Secure sentence and the trailing 'cancel_order cancels' are slightly terse but each earns its place; nothing is filler.

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

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

A money-moving mutation with no annotations and an output schema present. The description covers the risk, the precondition logic, the drift/refusal behaviour, and the wait_user_action return path, while the output schema handles the return shape. Nothing an agent needs to call this safely is missing.

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

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

Schema coverage is 0%, so the description must compensate for the single parameter, and it does: it explains what confirmed_total means ('that exact total'), where it comes from (the previewed total), and the validation rule (must match the preview). The only gap is that it doesn't give the numeric format, but that is minor for a number field.

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 ('Place the order') plus the consequential action ('CHARGE the card'), and explicitly distinguishes itself from checkout_preview and cancel_order by naming both. Nothing about the purpose is left 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?

Gives explicit when-to-use ('Call ONLY after checkout_preview was run and the user explicitly said yes') and when-not-to (order is refused unless preconditions hold), and names the sibling to run before it. This is the strongest possible form of 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?

No annotations are provided, so the description carries the full burden. It does disclose 'Read-only', which is the key safety trait for a list operation, but says nothing about pagination, ordering, or behavior of the layout_slug default.

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

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

Three short sentences, front-loaded with the action and followed by the prerequisite and the safety note. Every sentence earns its place; no padding.

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

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

An output schema exists, so return values need no explanation. For a simple two-parameter read, the description plus schema is nearly sufficient, with only the unexplained layout_slug leaving a small 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 0%, so the description must compensate and partially does: it explains where group_id values originate. However, the layout_slug parameter (default 'grocery') is never mentioned or explained in the description or schema.

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

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

States a specific verb and resource ('List the categories inside one catalog group, by group id'), which is clearly distinct from the flat sibling list_categories and from get_category_products. It stops short of an explicit contrast statement, but the scope is 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?

Explains the prerequisite path: group ids come from list_categories, each group carrying an id. That tells the agent when this tool applies (after browsing groups) without spelling out a when-not-to-use rule.

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 behavioral burden and does so well: it declares 'Read-only', discloses pagination mechanics (raise `limit` to page further using `total_products`) and a latency side effect (one extra lookup to resolve the parent group). It stops short of covering error behavior or auth requirements, so it is strong but not exhaustive.

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

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

Front-loads purpose and read-only status, then layers sourcing, filtering, and paging details in short sentences; nothing is redundant. It is somewhat dense with backticked field names and could be tightened, but each clause carries actionable information.

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

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

Output schema exists so return values need not be spelled out, yet the description still previews the response shape (subcategories, products, total_products). Combined with parameter sourcing and paging guidance, an agent has everything needed to call this correctly on the first attempt.

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

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

Schema description coverage is 0%, so the description must compensate and it does: category_id's source, limit's paging role via total_products, subcategory's accepted form (an id or title from the result), and the grocery-only relevance of group_id/layout_slug. Every one of the five parameters gets meaning beyond the bare JSON types.

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

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

States a specific verb and resource ('List products in a catalog category') and immediately scopes it as read-only, which cleanly separates it from list_categories (category enumeration) and search_products (keyword search) in the sibling set. An agent can tell what it returns without opening the schema.

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

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

Explicitly routes the agent to list_categories/get_category_group to obtain category_id, explains when to pass subcategory, and states that group_id/layout_slug are 'only needed for non-grocery storefronts' - a genuine when-not condition. It also notes the extra lookup cost when group_id is omitted, so the trade-off is visible.

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 supplied, so the description carries the full burden. The read-only, non-mutating nature is conveyed by 'Get full details' and the list of returned fields, but nothing is said about permission needs, error/not-found behavior, or whether the order_id is scoped to the current user.

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 purpose and the returned fields, followed by the one operational instruction. No filler.

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

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

For a one-parameter read tool with an output schema already defining the return shape, this covers purpose, payload contents, and how to source the id. Minor gaps around not-found or permission failure behavior keep it from being exhaustive.

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 0% and the single parameter has no inline documentation, but the description compensates by stating the id's provenance ('from order_history or active_orders'). It still omits any format expectations for the id string.

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

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

States a specific verb and resource ('Get full details of a specific order') and enumerates exactly what comes back: items, totals, address, status, payment. Naming order_history and active_orders as the id sources implicitly distinguishes this detail-fetch from those list-style siblings.

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

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

'Pass an order_id from order_history or active_orders' tells the agent both the prerequisite and where to obtain the value, which is clear usage context. It stops short of explicit when-not guidance (e.g., that it is not for cart contents or pre-checkout previews, which are handled by view_cart/checkout_preview).

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 discloses read-only behavior and gives unusually detailed behavioral notes about the nutrition block, including null cases and a warning when Lavka's per-portion data does not follow from per-100g data.

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 first sentence is front-loaded and efficient. The nutrition section is lengthy and partly explains return values despite an output schema existing, but it is structured and every detail is useful rather than repetitive.

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

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

An output schema exists, so the description need not explain return values, yet it adds enough context about parameter forms, read-only behavior, and nutrition edge cases for an agent to call the tool correctly. Nothing essential is missing.

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

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

Schema description coverage is 0% for the single parameter, so the description must compensate. It does so fully by defining `product` as an id, slug, or Lavka link page/URL, which is essential information not present in the schema.

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

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

States a specific verb and resource: 'Get one product' with the exact fields returned. It clearly distinguishes this sibling tool from `search_products` by scope: one product versus a search/list operation.

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

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

Explains that `product` comes from a search result, an id/slug, or a Lavka link, which gives clear context for when and how to use it. It does not explicitly name when not to use it or compare against a sibling, 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 explicitly marks the tool as read-only, which is key behavioral info. With no annotations, it carries the full burden, and it does this well. Could add more about error states, but the output schema likely covers return details.

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

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

Two short, front-loaded sentences with no wasted words. Essential info is delivered efficiently.

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 0 parameters and an output schema, the description fully covers what the tool does, its read-only nature, and usage order. No gaps remain.

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?

No parameters exist, so baseline is 4. The description adds no parameter info because none are needed.

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 it shows whether the Lavka session and delivery location are configured. It uses a specific verb ('Show') and resource, and is distinct from sibling tools like set_location or search_products.

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

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

Explicitly states to call this first before other tools to check setup, providing precise when-to-use guidance and suggesting a sequence.

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

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

No annotations provided, but description declares 'Read-only', disclosing side-effect-free behavior. Additionally explains how returned label is used, enhancing transparency.

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 concise sentences with no wasted words. Purpose and usage guidance are front-loaded and efficiently communicated.

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?

As a simple list tool with output schema, the description fully covers what the tool does, its read-only nature, and how to use its output. No gaps remain.

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?

No parameters exist, so schema coverage is effectively 100%. Description adds meaning beyond schema by noting addresses are listed by name, compensating for lack of params.

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?

Clearly states the tool lists saved Lavka delivery addresses by name. Distinguishes from siblings by explicitly mentioning the returned label is used with use_address, showing differentiation.

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

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

Indicates when to use (to list addresses) and how to use the output (with use_address). Lacks explicit when-not-to-use but adequate for a simple read-only tool.

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 explicitly states 'Read-only' and discloses that the call returns the entire menu hierarchy rather than a filtered subset. It does not cover auth/permission requirements or pagination, which are the remaining gaps for an unannotated tool.

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

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

The description is short and front-loaded, leading with what the tool browses before drilling into return shape and parameter meaning. Every sentence earns its place, though the multi-line formatting is slightly loose for the amount of 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 an output schema present the description need not detail return values, yet it still sketches the group/categories structure. Combined with the parameter explanation and read-only note, an agent has enough to invoke it correctly; only auth/permission context 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 0%, so the description must compensate, and it does: it defines what layout_slug selects, names the default ('grocery'), and gives two concrete hub values. It adds real semantic value beyond the bare string-typed schema property.

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 ('Browse the Lavka catalog menu: category groups with their categories') and enumerates the returned shape (group id/title, categories id/title). It also names the follow-up sibling get_category_products, so an agent can distinguish this listing tool from the sibling that consumes its 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?

Explains that a returned category id is used with get_category_products, which gives clear follow-on context, and clarifies that layout_slug selects the storefront with concrete alternatives ('grocery' default vs 'pharmacy'/'pet_store' hubs). It stops short of explicit when-not-to-use guidance, but the routing intent 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?

With no annotations provided, the description carries the full behavioral burden and does declare 'Read-only', which is the key trait. It also explains the default-card fallback behavior. It does not cover auth requirements, rate limits, or pagination, but for a zero-parameter list tool this is solid coverage.

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

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

Three short sentences, each earning its place. The core purpose and read-only nature are front-loaded, followed by the actionable follow-up step.

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

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

An output schema already exists, so the description need not document return values, yet it still highlights the two fields that matter (id and default). Combined with the read-only declaration and sibling routing, nothing essential for correct invocation is missing.

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

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

The tool takes no parameters, so the baseline is 4. The description's mention of a returned `id` is output-side information rather than parameter semantics, but it correctly connects the result to the set_payment_method workflow.

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

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

States a specific verb and resource ('List the user's saved cards') and adds the distinguishing detail of surfacing the default card. It explicitly names the sibling set_payment_method, so an agent can tell this read/list tool apart from the setter 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?

Explains the downstream workflow: take a returned `id` and pass it to set_payment_method, otherwise the account default card is charged. This gives clear context for when the tool matters, though there are no explicit exclusions or prerequisite conditions.

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 state "Read-only" plus the pagination contract (take last_order_id from the previous result and pass it back to fetch the next page). It omits max limit bounds, sort order, and any auth/rate-limit context, so it is good but not complete.

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

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

Front-loaded with the core purpose, then read-only status, then pagination mechanics in two short sentences. Minor redundancy in "pass it as last_order_id" restating the same parameter name, but nothing wasteful overall.

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

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

An output schema exists, so the listed return fields are a harmless bonus rather than a necessity, and the pagination contract is the key missing piece an agent would otherwise lack. The only real gap is the unexplained limit parameter for a simple 2-param read tool.

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

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

Schema coverage is 0%, so the description must compensate for both parameters. It explains last_order_id well as a pagination cursor (meaning the schema's bare title does not convey), but limit is never mentioned, leaving one of two parameters undocumented anywhere.

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

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

States a specific verb and resource ("Get list of past orders"), and the word "past" implicitly contrasts with the sibling active_orders. It never names an alternative sibling explicitly, so it falls short of the 5-level sibling differentiation.

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

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

Usage is only implied by the phrase "past orders"; there is no explicit statement of when to prefer this over active_orders or get_order, and no exclusions. The pagination instruction is helpful but is a mechanics note rather than selection 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?

No annotations are provided, so the description carries the full burden. It does disclose two important traits: the search is read-only, and results are scoped to the current delivery location (implying a set_delivery_address dependency). It omits rate limits, pagination behavior for the limit param, and whether results are ranked or filtered.

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 plus a result-shape note, with the core action and location scoping front-loaded. No filler.

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

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

An output schema exists, so return values needn't be described, yet the description usefully flags id/slug and their downstream consumers. It is nearly complete for a search tool, missing only input-side semantics (query matching, limit meaning) and any mention of the location prerequisite's 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 0%, so both parameters (query, limit) rely entirely on the description, which says nothing about them. The description instead explains the *return* fields (id, slug), which is useful but does not compensate for the undocumented input semantics.

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

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

States a specific verb (Search) and resource (the Lavka catalog) scoped to the current delivery location, and names the sibling tool (get_product) that consumes its results. An agent can distinguish it from get_product 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?

The description implies usage by explaining how to chain results into add_to_cart and get_product, which is genuinely useful routing context. However it never states when to use this versus browsing or direct lookup, nor any exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the full burden. It discloses that resolution happens via Lavka's own geo search, which is useful, but says nothing about side effects (does this replace the active delivery address, affect the cart, or persist a new address?), failure behavior for unresolvable text, or permissions.

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 the capability front-loaded and a concrete example that earns its place. Slight redundancy between 'ANY address' and 'works for a new city', but no meaningful waste.

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

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

An output schema exists, so return values need not be explained, and the geo-resolution behavior is covered. However, for a mutation with zero annotations and 0% parameter coverage, the description omits what state changes and how the remaining two parameters behave, leaving real gaps.

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 0% for 4 parameters. The example only illustrates query and flat; comment and entrance are left entirely undocumented in both schema and description, and no format expectations (e.g. what query must contain) are given beyond the sample string.

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 ('Set delivery to ANY address by free text') and adds a distinguishing scope note ('works for a new city') that separates it from saved-address siblings like use_address. It stops short of naming any sibling explicitly, so it is clear but not fully differentiated.

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 'works for a new city' / 'ANY address' phrasing implies the intended case (arbitrary, unsaved addresses) versus siblings such as use_address or list_addresses, but no alternative is named and no when-not guidance is given. Usage is inferable rather than stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral transparency. It adds that the location persists to config, which is a useful behavioral trait. However, it does not disclose side effects (e.g., overriding previous location), authorization requirements, or rate limits. For a simple setter, this is adequate but not comprehensive.

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 extremely concise, consisting of two short sentences. The key purpose is front-loaded in the first sentence, and the second sentence adds parameter guidance. Every word is earned; no fluff or repetition.

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

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

Given the tool's low complexity (4 optional parameters, simple setter) and the existence of an output schema, the description covers the main points: what it does, when to use it, and how to use it. It could mention error handling or output format, but the output schema likely covers returns. The description is nearly complete for this simple 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?

The input schema has 0% parameter description coverage, so the description must compensate. It explains that lat+lon or address_id are alternative ways to provide the location, which adds semantic grouping. However, it does not explain the 'label' parameter, leaving its purpose unclear. The description partially compensates but not fully.

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 ('Set') and resource ('delivery location'), and clarifies it is a prerequisite for catalog/cart calls. It clearly states the action but does not explicitly differentiate from the sibling tool 'use_address', which might also set a location. The purpose is clear but lacks sibling 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?

The description explicitly states that the tool is required before catalog/cart calls, providing a clear usage context. It also specifies the two ways to provide the location (lat+lon or address_id). However, it does not mention when not to use it or provide alternative tools, missing the full 'when/when-not/alternatives' 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?

No annotations are provided, so the description carries the full disclosure burden. It usefully states the change persists and defines the empty-string revert behavior, but omits auth requirements, what happens to in-flight orders, and error behavior for invalid ids. For a mutation tool with zero annotation coverage this is only partially sufficient.

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 effect and then the parameter sourcing and fallback. Every clause carries information; nothing is redundant with the schema or 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?

An output schema exists, so return values need not be described. For a single-parameter setter the description covers effect, source of the value, and the revert case; only edge-case/error behavior and permission requirements are absent, which is a minor gap.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it explains that card_id should be an id from list_payment_methods and that an empty string has special revert semantics. It stops short of stating id format or validation rules, but the single parameter's meaning is clear.

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 ('Choose which saved card orders will charge') and resource (the payment method used for charging), with the persistence note clarifying the durable effect. It also names the sibling list_payment_methods as the source of valid ids, so an agent can distinguish it from the listing tool without opening either schema.

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

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

Gives clear operational context: use an id obtained from list_payment_methods, and pass an empty string to revert to the account default. That covers the primary and fallback invocation paths, but there is no explicit when-not guidance or mention of prerequisites such as being in a checkout flow.

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. It discloses two valuable behavioral facts (declarative 'exact' set semantics rather than increment, and that zero removes the line) plus the no-charge reassurance. It omits what happens when product_id is not already in the cart, any auth requirements, and whether the operation is idempotent.

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, no filler, with the core action and the critical zero-quantity edge case 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?

An output schema exists, so return values need no explanation, and no annotations means the safety profile is largely self-evident for a non-charging cart edit. The remaining gap is the undocumented product_id semantics, which the description does not close.

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 0%, so the schema contributes nothing beyond types and required-ness. The description compensates for quantity by defining the zero-value edge case, but product_id is left entirely unexplained (must it already be in the cart? is it a catalog id?). Partial compensation only.

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 ('Set the exact quantity of a cart item'), and the word 'exact' implicitly contrasts this with the additive sibling add_to_cart. An agent can route between the two 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?

Usage is implied rather than stated: 'quantity=0 removes it' tells the agent this tool doubles as a removal path, but there is no explicit when-to-use vs add_to_cart, clear_cart, or view_cart. Adequate for a simple two-parameter cart mutation, but no alternatives or prerequisites are named.

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

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

The description reveals that the tool re-points catalog, cart, and prices, and that a saved address carries city/street/house. It also notes optional flat/entrance/comment parameters. Without annotations, this provides adequate behavioral context, though it omits potential error states (e.g., name not found) or permissions.

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

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

Three sentences, each serving a distinct purpose: purpose, effect, parameter details. No fluff, front-loaded with the core 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?

Given an output schema exists (not shown), the description does not need to detail return values. It adequately covers the tool's functionality, parameters, and impact, and distinguishes from siblings. It is complete for a tool with 4 params and a clear use case.

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 0%, but the description adds meaning: 'matched by name' for required name, and 'pass flat/entrance/comment if the order needs them' for optional params. This clarifies their purpose beyond the schema's bare titles.

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 the action: 'Switch delivery to one of your saved addresses, matched by name.' It specifies the verb ('switch') and resource ('delivery to a saved address'), and contrasts with sibling tools like list_addresses (listing) and set_location (likely setting a different location).

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 explains when to use the tool: when you want to switch delivery to a saved address. It mentions that catalog, cart, and prices are location-scoped, implying the tool re-points everything. However, it does not explicitly state when not to use it or compare directly with siblings like set_location.

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 burden and does so reasonably: it declares read-only, and explains the semantics of three returned flags (warning, unavailable_on_depot, available_for_checkout) including what to do when they fire. It does not cover auth requirements or error behavior, but for a zero-parameter read tool the disclosure is solid.

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

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

Front-loads purpose and read-only status in the first two sentences, then uses a short bulleted list for the flags and closes with the corrective action. Every line adds distinct information; 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 zero-param read tool with an output schema, the description supplies exactly what structured data cannot: the meaning of each readiness flag and the remediation path. An agent has everything needed to call it and act on 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?

The tool takes zero parameters, so the schema-vs-description comparison is moot and the baseline of 4 applies. The description correctly spends no words on arguments and instead explains the returned flags.

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

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

States a specific verb and resource ('Show the current cart contents and running total') and adds scope detail (order-readiness reporting) that separates it from siblings like checkout_preview and clear_cart. The read-only framing plus the named sibling update_cart_item makes its role 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?

Gives clear context (call it to inspect the cart and its order-readiness) and routes the agent to the alternative when problems appear: 'Remove/replace flagged items with update_cart_item(product_id, 0) before checkout.' There is no explicit when-not or timing statement beyond the implicit pre-checkout use.

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