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

Annotations already cover readOnlyHint/openWorldHint/destructiveHint, but the description goes further: it names the auth scope (buyer_cart_read, OAuth grant), discloses that prices are INTEGER base-units with exponent 6, explains that unavailable_reason uses ORDER-CREATION gates, and notes that ordered lines leave the cart. These are behavioral facts an agent could not infer from the annotations.

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

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

Front-loaded with the core identity, then structured bullets for the mutation boundary, the availability-gate rule, and the purchase path. Dense and largely waste-free, though internal jargon ('PR-4', 'exp 6') adds a little decoding overhead for an agent unfamiliar with the codebase.

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

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

With no output schema, the description carries the burden of describing the return shape, and it does so (product, variant, quantity, unit price, store, orderability plus unavailable_reason). Combined with the mutation boundaries and the downstream ordering chain, an agent has everything needed to call it correctly 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 baseline is 4 and there is nothing further the description could add on that axis. Its field-level notes (unit price encoding, availability flag) describe outputs rather than inputs, which is still useful but outside 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+resource ('The human's own cart, READ-ONLY') and enumerates exactly what is returned: product, variant, quantity, unit price, store, orderability. It is clearly distinguishable from siblings like webaz_buyer_orders or webaz_wallet_view because it scopes to the cart and declares read-only status up front.

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 what the tool cannot do ('You cannot add, change, remove or check out — that stays with the human at webaz.xyz') and routes the agent to the correct alternative chain for purchasing: webaz_quote_order → webaz_order_draft → webaz_submit_order_request. It even adds the constraint 'one variant per order, each approved by the human', which prevents a common misuse.

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