agentee-mcp

Preview order

get_order_preview

Read-onlyIdempotent

Show a full order preview before checkout, including re-priced lines, promo or bundle discount, shipping, saved address, and grand total; use it to confirm details before preparing the order.

Instructions

Show the full order before checkout: re-priced lines, promo or bundle discount (they don't stack — the better one applies), shipping, the address from set_shipping_address, and the grand total in the order currency (local for some destinations, e.g. UZS for Uzbekistan). Call it once the address is set and show the result to the human for confirmation before prepare_order. Read-only and safe to repeat; prices come from the live catalog, not from the cart. ready_to_prepare stays false while the address is missing or a line is unavailable — fix what issues lists (update_cart_item, set_shipping_address) first. An empty cart returns an error.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`note`	No
`error`	No	Present when the cart is empty.
`items`	No	Re-priced order lines.
`total`	No
`bundle`	No	Bundle price applied instead of the promo code, if any.
`issues`	No	Lines that became unavailable, if any.
`currency`	No
`discount`	No
`shipping`	No
`subtotal`	No
`promo_code`	No
`ready_to_prepare`	No	True when an address is set and all lines are orderable.
`shipping_address`	No	Address set via set_shipping_address (null if not set).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.2.0Oct 23, 2026

addedOutput schema / properties / bundle

Added value: +{
+  "description": "Bundle price applied instead of the promo code, if any.",
+  "type": "string"
+}

First observedOct 23, 2026

TDQS

A4.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is structured data. The description still earns credit for non-obvious behavior: prices come from the live catalog rather than the cart, promo and bundle discounts don't stack, ready_to_prepare stays false on missing address or unavailable lines, and an empty cart errors out. Those additions are real value beyond the annotations, though return shape and pagination are left to the 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.

Conciseness4/5

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

The core 'what you get' is front-loaded, then invocation timing, then failure conditions — a sensible order. Nearly every clause carries distinct information (non-stacking discounts, catalog pricing, gate flag, empty-cart error), but it is a dense run-on paragraph that could be broken into shorter units for scanability.

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

Completeness5/5

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 enumerated, yet the description still highlights the fields that matter for the agent's decision (total currency, ready_to_prepare). Both the happy path and the two blocking conditions plus the error case are covered, so the agent has everything needed to call it correctly.

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

Parameters4/5

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 schema to document. The description goes slightly beyond by explaining that the grand total is expressed in the order currency, which can be destination-local (e.g. UZS for Uzbekistan).

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

Purpose5/5

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

Starts with a specific verb+resource ('Show the full order before checkout') and enumerates exactly what the preview contains: re-priced lines, discount resolution, shipping, address, grand total. It is clearly distinguishable from siblings view_cart (raw cart) and prepare_order (the committing step).

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

Usage Guidelines5/5

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

Explicit sequencing: call once the address is set, show the human, then prepare_order. It also names remedies for the blocked state (update_cart_item, set_shipping_address) rather than leaving the agent to guess. Usage boundaries relative to siblings are fully specified.

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