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 without description help. The description adds that the response includes the subtotal, which is modest extra context, but it says nothing about empty-cart behavior, currency, or freshness of the 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?

A single front-loaded sentence with no filler; every word earns its place and the key information (cart contents + subtotal) is stated immediately.

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

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

With zero parameters, read-only annotations, and a dedicated output schema, the description does not need to explain return values. It is nearly complete; only minor edge-case behavior (empty cart, currency) is unaddressed, which the output schema likely covers.

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

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

The tool takes zero parameters, which is the baseline-4 case per the rubric. There are no arguments whose semantics could be clarified or omitted.

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 (the cart) and scope (its current contents plus subtotal), which is enough for an agent to distinguish it from the mutation siblings cart_add and cart_remove. It does not name those siblings explicitly, so it falls short of a 5.

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

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

The word 'now' implies this is the read-side tool for inspecting cart state, and the sibling names (cart_add, cart_remove) make the division of labor inferable. However, the description never states when to call it versus cart_add/cart_remove or checkout_status, leaving usage to inference.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the description only needs to add context. It adds that the call returns the cart and that it is scoped to one-time purchases, but says nothing about how repeated calls behave (non-idempotent — does quantity accumulate?) or any auth requirements.

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, zero filler, with the core action and the purchase-mode constraint front-loaded. Nothing is redundant with the schema or annotations.

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 needn't document the returned cart. However, for a two-parameter mutation with 0% schema coverage, the description omits the one behavior an agent most needs (quantity accumulation semantics) and gives no indication of preconditions or failure modes.

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 description explains neither parameter. The critical ambiguity — whether 'quantity' adds to an existing cart line or replaces it, and what 'asin' must refer to — is left entirely unresolved by both the schema and the description, so the description fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('Add a product to the cart') and clarifies scope with the one-time-purchase qualifier, which implicitly distinguishes it from a subscription flow. It does not, however, contrast itself with adjacent siblings such as cart, cart_remove, or checkout_request, so sibling differentiation is left to the name.

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 'one-time purchase, not Subscribe & Save' is a real exclusion that tells the agent when this tool is the wrong choice. But it names no alternative tool and gives no prerequisites (e.g., must the product be returnable/available), so guidance remains implied rather than actionable.

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, openWorldHint=true, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds only 'Returns the cart,' which is redundant given an output schema exists, and says nothing about what happens when the product is absent or whether the removal is reversible.

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 with no wasted words. Everything earns its place except perhaps the redundant return note.

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

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

For a mutation tool with an output schema present, the return value need not be explained, and annotations cover the safety profile. However, the description omits error behavior (e.g., product not in cart) and parameter meaning, leaving gaps an agent would want filled.

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?

With 0% schema description coverage, the description must carry the parameter. It implies that the single argument identifies the product to remove, but never states that it is an ASIN or gives any format constraint, leaving the parameter only weakly clarified.

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

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

The description states a specific verb and resource ('Remove a product from the cart'), which clearly distinguishes it from the sibling cart_add. It stops short of naming an alternative explicitly, so it doesn't reach the top of the scale, but the intent 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as cart_add or cart. The usage context is only implied by the verb 'remove'.

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 only say it is a non-read-only, non-destructive, open-world call; the description adds the crucial detail that 'nothing is placed', that a browser review page opens showing total/items/address/card, and that it returns 'pending' asynchronously rather than completing. This is exactly the behavioral context the annotations cannot convey.

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

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

Three front-loaded sentences with zero filler: the action and its non-committal nature come first, then the UI flow, then the async contract. Every sentence carries distinct 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?

Despite being a mutation-adjacent, open-world tool, the description covers safety ('nothing is placed'), the user-visible flow, the return status, and the required follow-up call. With an output schema present, no further return-value detail is needed.

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. The description correctly says nothing about inputs because there are none, and it explains the implicit target ('the current cart'), which is the only semantic an agent needs.

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 ('approve buying the current cart') and immediately disambiguates from the sibling polling tool by naming checkout_status. An agent can distinguish this from cart, cart_add, and checkout_status 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?

Clear context for use (approving the current cart) and explicit next-step routing to checkout_status for polling, plus the note that the user can approve or decline. It lacks an explicit when-not condition (e.g., empty cart), but the surrounding guidance is strong.

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 (safe read) and openWorldHint=true. The description adds meaningful semantics about the status values, but doesn't mention the return structure, whether polling is needed, or auth requirements. The value added to the safety profile is minimal.

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

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

The description is a single, well-structured sentence with no wasted words and front-loads the key concept (approval status) and its possible values.

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

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

Given a single-parameter tool with an output schema, the description covers the main status values and the fact that placed includes order_number and failed includes detail. It lacks explanation of what approval_id is and how to obtain it, but the output schema likely handles return details.

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 should explain the required approval_id parameter. It does not define its format or source. However, with only one required parameter and an output schema, the burden is lower; baseline 3 is appropriate.

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

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

The description clearly identifies the resource (an approval) and enumerates its possible states, which tells the agent this is a status-reporting tool. It does not explicitly contrast with the sibling checkout_request, but the specific enumeration and phrasing distinguish it from a generic status check.

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 (checking the state of a checkout approval), but gives no explicit guidance on when to use it versus alternatives like checkout_request or orders. No when-not or prerequisites are stated.

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

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

Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds genuinely useful behavioral context: Amazon serves 10 orders per page and max_pages caps how many pages are actually fetched, which tells the agent the call is paginated and bounded.

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 what the tool returns before the parameter and pagination details. Every sentence carries information; only the slightly cryptic 'year-YYYY' token costs it a perfect score.

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

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

For a two-parameter read tool with an output schema and safety annotations, the description covers the resource, both parameters, and the pagination model. Return-value shape is correctly left to the output schema, though sibling differentiation remains unaddressed.

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

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

Schema description coverage is 0%, so the description must carry the burden and largely does: it enumerates the accepted period values ('last30', 'months-3', 'year-YYYY') that the schema omits as an enum, and explains what max_pages controls. It does not state the default behavior or whether an invalid period errors.

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: order history, enriched with each item's return window. It is clear what the tool returns, but it never names or contrasts itself with the sibling returnable_items, so an agent must infer which one to pick when it only wants return-eligible items.

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

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

Usage is only implied by the resource name; there is no explicit when-to-use, when-not-to-use, or alternative tool named among returnable_items/product/cart. The pagination note hints at cost trade-offs but never frames it as guidance for choosing this 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the meaningful scope constraint that exactly one product is returned per ASIN, but says nothing about missing/invalid ASIN behavior or any lookup constraints.

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 naming the returned fields and the key parameter; there is no filler. It is arguably terse to the point of under-specification rather than bloated.

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 takes one simple identifier and an output schema exists to describe the return shape, so the description need not explain response values. For a single-param read tool this is nearly complete; only the not-found case is unaddressed.

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

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

Only one parameter exists and the schema provides no description for it (0% coverage). The description compensates somewhat by clarifying 'asin' identifies a single product and hinting where such an identifier originates ('from orders'), but gives no format or validation detail.

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

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

States a concrete resource (one product by ASIN) and the exact fields returned (title, price, availability), so an agent knows this is a catalog lookup rather than a cart or order operation. It does not explicitly name a sibling to distinguish itself from, which keeps it just short of a 5.

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

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

The parenthetical '(e.g. from orders)' implies the typical workflow: the ASIN comes from an order, then this tool enriches it. That is a useful but implicit usage cue; there is no explicit when-to-use/when-not statement or named alternative among the 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=true and openWorldHint=true, so safety is covered. The description adds meaningful behavior beyond that: the 3-month lookback, the open-window filter, and the sort order, all of which shape how an agent interprets 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?

A single front-loaded sentence that conveys scope, filter, and ordering with no filler. 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?

An output schema exists, so return-value fields need no explanation here. The description supplies the scope and ordering needed to call the tool correctly; only explicit routing against sibling tools is missing.

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

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

The tool takes zero parameters, so the baseline of 4 applies. Schema coverage is 100% but there is nothing parameter-wise to document.

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

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

The description states a specific resource and scope: items with an open return window from the last 3 months, ordered by soonest deadline. An agent can tell this returns a filtered, sorted collection distinct from the generic 'orders' sibling, 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?

The 'return window still open' framing implies the use case (deciding what can still be returned), but there is no explicit when-to-use guidance and no named alternative such as 'orders' for viewing items outside the return window.

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