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

With no annotations, the description carries the full burden; the verb 'Show' and the presence of a confirmation hash suggest a side-effect-free preview, which is useful. It also discloses that shipTo changes the total by including shipping, but leaves open whether the hash expires, whether the cart is mutated, or what currency/precision the total uses.

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 useful content is packed into one front-loaded sentence plus a scoping note, with zero filler. The bilingual duplicate doubles length for a single locale's benefit, which is defensible but not free.

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 description compensates for the absence of an output schema by enumerating the returned fields, which is genuinely helpful. But with no annotations, an entirely undocumented nested shipTo object, and no mention of the confirmation hash's downstream role, an agent still lacks what it needs to call this confidently.

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 only shipTo gets any treatment — and only its effect on the total, not its structure — despite it being a nested object with completely undocumented fields. cartId and agentId are entirely unexplained in both schema and description.

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

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

The description states a concrete output set (lines, quantities, total, confirmation hash) which identifies this as a cart quote/preview rather than the order itself, implicitly separating it from gnv_checkout_place. However, it never names the cart or the checkout sibling explicitly, so the differentiation relies on 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?

The mention of a 'confirmation hash' implies this is the preview step preceding gnv_checkout_place, but the description never states when to call it, whether the hash is required downstream, or how it differs from gnv_cart_create or gnv_order_status. Usage is inferable rather than documented.

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