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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true; the description's 'Nothing is ordered yet' usefully reinforces that the mutation is non-committal and it discloses the return payload. It does not cover availability/stock failures, quantity merge behavior, or addon/topping validation.

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

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

Two short sentences, front-loaded with the action and then the key constraint. 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 need no prose. However, with 0% schema coverage the description should compensate for the undocumented quantity/addon/topping parameters, and it does not.

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 four parameters exist, yet the description mentions only 'a product' (product_id). Quantity, addon_ids, and topping_ids receive no semantic explanation anywhere, leaving the agent to guess their meaning and accepted values.

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

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

States a specific verb and resource ('add a product to the cart') plus the side effect on return ('return the updated cart'). 'Nothing is ordered yet' separates it from place_order, though no sibling is named 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: 'Nothing is ordered yet' nudges the agent to use this before place_order, but there is no explicit when/when-not guidance or reference to update_cart_item for adjusting quantities.

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

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

Annotations already cover readOnly=false, destructive=false and openWorld=true, so the description's only addition is the scope of removal. Notably, 'remove everything' sits in tension with destructiveHint=false, which could mislead an agent about reversibility; the description neither confirms nor resolves this.

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. It is appropriately sized, though the brevity comes at the cost of the usage and consequence information a destructive-scope tool would benefit from.

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 and annotations exist, so return values and safety hints are covered. What remains missing is any statement of when to prefer this over sibling cart-mutation tools or whether the clear is reversible.

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 there is nothing for the description to disambiguate. Baseline 4 applies for a zero-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 ('Remove') and resource ('everything from the cart'), so the operation is unambiguous. It does not differentiate itself from siblings such as update_cart_item or add_to_cart, leaving the agent to infer 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?

No when-to-use guidance, no alternatives named, and no warning about the consequence of emptying the cart. With update_cart_item in the sibling list, an agent gets no help choosing between clearing wholesale and removing items individually.

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 mark this as read-only and open-world, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the day parameter defaults to today, the output values are meant to be used as delivery_time, and 'ASAP' has a specific meaning.

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 core purpose, then the workflow detail. Every clause earns its place with no redundancy.

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

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

The tool is simple, has an output schema, and the description covers the key parameter semantics and integration with ordering tools. It omits minor details such as timezone or what happens when no slots are available, but overall it is sufficient for correct invocation.

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. It does by specifying the date format (YYYY-MM-DD) and the default behavior (today), which is exactly the missing semantic information for the single 'day' parameter.

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 resource and scope: available delivery slots for a given day. It clearly distinguishes this tool from siblings by naming the ordering tools (review_order / place_order) that consume its output, so an agent can place it in the workflow without checking other schemas.

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 explains the primary use case: get slots for a day, then pass a slot's value as delivery_time to review_order or place_order. It also clarifies that 'ASAP' is a valid value. It does not explicitly state when not to use this tool, but no sibling provides the same data, so the guidance 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The added has_choices caveat is genuinely useful but is workflow guidance rather than behavioral disclosure about the call itself (e.g., no mention of pagination despite 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 tight sentences plus a caveat, front-loaded with the core resource and scope. No filler, though the final note reads as an abrupt fragment.

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, return values need not be described, and the description covers the key inputs and the downstream workflow dependency. It is complete enough for an agent to call and chain correctly, missing only explicit sibling routing to search_menu.

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 carry the load. It does explain the origin of store_id (from list_restaurants) and clarifies that category is optional and limited to a single value, which adds meaning the bare schema lacks.

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 resource and scope: the menu of one restaurant, optionally narrowed to a single category. It implicitly distinguishes itself from list_restaurants (source of store_id) and search_menu, though it doesn't name search_menu explicitly as the alternative for querying dishes.

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 concrete context: store_id comes from list_restaurants, and products flagged has_choices=true require get_product_options before add_to_cart. That is real cross-tool routing, though no explicit 'when not to use this' vs search_menu is offered.

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, openWorldHint), so the description's added value is the ordering guarantee ('newest first') and the domain caveat about 'Transactie kosten' being an old payment fee rather than a food item. That caveat is real context an agent could not infer from structured fields.

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 scope and ordering before the field list. The enumerated return fields partially duplicate the output schema, but the sentence is short enough that little is wasted.

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

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

For a zero-parameter read tool with an output schema and read-only annotations, the description supplies everything needed to select and invoke it, plus a useful domain caveat. 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?

The tool takes no parameters, so the baseline is 4. The description correctly characterizes the call as implicit-scope (logged-in account) rather than parameterized, which prevents an agent from hunting for a user or date argument.

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 scope ('past orders of the logged-in account', 'newest first') plus the fields returned, which lets an agent separate it from review_order, place_order and reorder. It doesn't explicitly name a sibling, but the resource 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?

Usage is implied by the scope ('logged-in account'), but there is no explicit when-to-use or when-not-to-use guidance and no alternative named, e.g. review_order for a single order or reorder for repeating one.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the bar is lower. The description still adds real domain semantics beyond the schema: addon groups require exactly one option id, toppings are optional, max_in_group caps selection, and prices are per-item surcharges rather than totals.

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, no filler, and the core purpose is front-loaded before the selection rules. The opening fragment is telegraphic ('Choices for a product') but the rest compensates 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?

With an output schema present, the return structure needn't be spelled out, yet the description adds valuable interpretation rules (one option id per addon group, max_in_group, surcharge pricing). For a single-parameter read tool this covers what an agent needs 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 0% for the single product_id parameter, but the description is written around 'a product' and so implicitly ties the argument to the product whose options are returned. The parameter name is self-evident, but no explicit syntax, format, or sourcing guidance is added, so it does the minimum.

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 ('Choices for a product') and the follow-on sentences make clear it returns selectable addon/topping options, so an agent can tell what it gets back. However, it lacks an explicit verb and never differentiates itself from siblings like get_menu or search_menu, which also surface product-related data.

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 tool versus get_menu, search_menu, or add_to_cart. The rules given ('each addon group needs exactly one option id', 'respect max_in_group') govern how to interpret the result, not when to reach for this tool. Usage is only weakly implied.

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 and openWorldHint, so safety is covered. The description adds a genuinely non-obvious behavioral quirk — restaurant names are not exposed as text and must be identified by description and categories — which is exactly the kind of context structured fields cannot carry.

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, no filler, with the core action front-loaded and the identification caveat kept as a separate short line that 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 not be described, and the description still previews them helpfully. For a zero-parameter read-only listing tool it is essentially complete; only the lack of scoping/usage context keeps it from a 5.

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

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

Zero parameters, so the baseline of 4 applies. There is nothing further the description could add on parameter 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 and resource ('List the restaurants on IJburg Eats') and even previews the returned fields (short description, menu categories). It implicitly separates itself from get_menu/search_menu by being the enumeration tool, but never names a sibling explicitly, so it stops 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?

No when-to-use or when-not-to-use statement. The agent must infer that this is the browsing/entry-point call, with no guidance on whether to prefer search_menu or get_menu once a restaurant is known.

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 flag destructive/openWorld/non-idempotent, and the description adds critical context beyond them: the tool spends real money, the total is validated against review_order and can be refused, and the order is only final once payment is completed. That is exactly the behavioral disclosure an agent needs for an irreversible purchase.

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 money-spending warning, then prerequisites, then parameter constraints and post-payment flow in four tight sentences with no filler. 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?

Covers the sequencing prerequisite, the total-validation refusal, and the payment_url handoff. Output schema exists so return-value details needn't be repeated, and the description still surfaces the one output (payment_url) the agent must act on.

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 carries the burden and does well: expected_total's equality constraint with review_order's total_to_pay and note's optional restaurant/driver message are both meaningfully explained. delivery_time is left unexplained, a minor gap since it defaults to ASAP.

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 ('PLACE A REAL ORDER') and immediately distinguishes it from the sibling review_order, which the agent must call first. The uppercase emphasis on 'REAL' and 'costs money' makes the consequential nature unmistakable.

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

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

Explicit precondition: only call after the user confirms the review_order result, with expected_total matching review_order's total_to_pay. It also states the failure condition (refused if total changed) and the post-call flow for iDEAL/card, leaving no ambiguity about when and how to 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?

Discloses non-obvious behavior beyond annotations: partial failures are reported as skipped/needs_choice rather than erroring, and 'nothing is ordered' clarifies the write scope against the readOnlyHint=false annotation. Output schema exists, so the reported result categories are reinforced rather than uniquely required here.

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?

Dense but front-loaded: primary action first, then edge-case handling, then the terminal caveat ('Nothing is ordered'). Every clause carries routing or failure-mode information; only the nested parenthetical is slightly heavy.

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-param cart mutation with an output schema, the description covers the full agent workflow (source of input, partial-match handling, next tool to call) and states the operation is not order placement. Nothing needed to call it correctly is missing.

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

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

Schema coverage is 0% and the single param is undocumented in the schema, but the description compensates by naming its source (order_id from get_order_history). This is the key semantic an agent needs and it is supplied.

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

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

States a specific verb and resource (add past order's items to cart) plus the matching mechanism (matched by name against the current menu). Clearly distinct from add_to_cart and get_order_history, and it names the latter as its input source.

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: get order_id from get_order_history, handle needs_choice by asking the user and calling add_to_cart with matched ids plus pick, then continue with review_order. Both the trigger and the follow-up alternatives are given.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, and the description is consistent with that, adding the important workflow fact that it mutates delivery time but must not commit the order. It does not discuss side effects on the cart or error behavior, keeping it short of a 5.

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

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

Three front-loaded sentences with no fluff; the purpose leads, workflow follows, parameter hint last. The return-value enumeration is slightly redundant given an output schema exists.

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?

Covers purpose, the confirmation workflow, and payment semantics. Since an output schema exists, the return list need not be restated, and the main remaining gap is delivery_time value format.

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 carry the parameter burden. It does well for payment (names payment_options and examples MSP_Ideal/WINKEL_Cash) but leaves delivery_time format unspecified (e.g., from get_delivery_times vs a timestamp), so compensation is partial.

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 precise verb+resource ('Prepare checkout without ordering') and enumerates the effects (sets delivery time, returns items/address/payment/total_to_pay). The phrase 'without ordering' cleanly distinguishes it from the sibling 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?

Explicitly names the alternative tool (place_order) and the gate that selects it ('Show this to the user and get explicit confirmation before calling place_order'). This is exactly the when-to-use/when-not guidance an agent needs.

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 and openWorldHint, so safety and scope are covered. The description adds one genuine behavioral detail beyond them: matching is case-insensitive and spans all restaurants. It says nothing about result limits, ranking, or empty-result 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 tightly written sentence with the resource and match fields front-loaded; no filler to trim.

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 tool is a simple one-parameter lookup. The description covers the essentials; only cross-sibling routing guidance 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% and the single parameter 'query' is undocumented in the schema. The description compensates by defining what the query is matched against (name, description, category) and that matching is case-insensitive, which is real semantic value.

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 (restaurants' products) plus the fields matched (name, description, category). An agent can distinguish it from get_menu or list_restaurants, though the description never names those siblings to sharpen the contrast.

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 guidance on when to prefer this over get_menu, list_restaurants, or get_product_options. The keyword-search framing implies a lookup use case, but the agent is left to infer the boundary with the full-listing 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?

Annotations already declare readOnlyHint=false and destructiveHint=false; the description adds the non-obvious behavioral rule that quantity=0 deletes the line, which the schema cannot express. It does not describe error behavior (e.g. invalid row_id) or whether the result is reversible, but with annotations covering the safety profile this 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?

A single front-loaded sentence with no filler; the operation comes first and the two operational details are parenthetically appended. Every clause earns its place.

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

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

For a two-param cart mutation with annotations and an output schema (so return values need no explanation), the description covers the essential gotchas. Minor omissions (failure modes when row_id is stale) keep it from being fully 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 carries the burden, and it does so for both params: row_id is defined as coming from view_cart output and quantity gets a special sentinel meaning (0 = removal). This is meaningful semantics beyond the bare 'string'/'integer' schema 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+resource ('Change the quantity of a cart line') and distinguishes itself from siblings like add_to_cart and clear_cart by naming the exact mutation it performs. An agent can identify the operation without opening the schema.

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

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

Points the agent to view_cart as the source of row_id and reports that quantity=0 removes the line, which is the key routing condition (no separate remove tool needed). It does not explicitly contrast itself with add_to_cart/clear_cart, so it stops 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful content scope (what the cart view includes) but does not disclose behavioral traits such as empty-cart handling, authentication needs, or error conditions. This is adequate given the annotations but not rich.

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

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

One short, front-loaded fragment that lists the relevant cart fields without any filler. Every word earns its place and the resource is stated first.

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

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

For a zero-parameter, read-only tool with annotations and an output schema, the description covers the essential purpose and returned data. It could mention empty-cart behavior, but that is a minor omission given the low complexity and existing structured metadata.

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 has zero parameters and the schema description coverage is 100%, so there are no parameter semantics to document. The baseline of 4 applies for a parameterless 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?

The description names the specific resource ('Current cart') and enumerates the key fields it exposes (items with row_id, delivery cost, total, minimum-order status). This clearly identifies it as the read counterpart to add_to_cart, update_cart_item, and clear_cart, though it relies on the tool name for the explicit verb 'view'.

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 explicit guidance on when to use this tool versus siblings like review_order or get_order_history. The purpose is implied by the name and content list, but the description itself provides no when-to-use or when-not-to-use context.

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