Correct customer details (name, email, phone, address) or switch payment_method (yoco | ozow) on an unpaid checkout before calling complete_checkout. Returns the updated checkout state. Raises an error if the checkout is already paid or cancelled.
| Name | Required | Description | Default |
|---|---|---|---|
| customer | No | ||
| checkout_id | Yes | ||
| payment_method | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return value (updated checkout state) and error behavior for paid/cancelled checkouts, giving the agent a good sense of side effects and preconditions. It does not mention idempotency or whether customer fields are replaced wholesale, but the key behavioral traits are covered.
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 two sentences, front-loaded with the action, then providing return and error details. Every word adds value, and the structure is highly scannable.
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 tool with no output schema and moderate complexity, the description covers purpose, usage timing, return value, and error conditions. It could be more complete by describing the exact shape of the updated checkout state or noting any partial-update semantics, but the essential context is present.
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 schema description coverage is 0%, but the description explicitly explains the 'customer' nested object contains name/email/phone/address and enumerates the 'payment_method' options (yoco | ozow). It additionally clarifies that checkout_id refers to an unpaid checkout, providing meaning beyond the raw schema.
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 action ('Correct customer details or switch payment method') and the target resource ('unpaid checkout'). It distinguishes itself from the sibling complete_checkout by explicitly mentioning it as the subsequent step, and the error condition clarifies the scope.
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 provides clear context: it should be used on unpaid checkouts before calling complete_checkout. It also implies exclusions by stating an error occurs if already paid or cancelled, though it does not explicitly name alternative tools (e.g., update_cart) or list when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes, but search_products and lookup_catalog overlap significantly in filtering by category and dimensions, which could confuse an agent. The three search/filter tools have subtle differences described, but the overlap lowers the score from perfect.
All tools use consistent snake_case with verb-noun structure (e.g., cancel_cart, get_product, update_checkout). There is no mixing of conventions, and the verbs clearly indicate the action, making the set predictable and easy to parse.
26 tools is slightly above the typical well-scoped range of 3-15, but the domain of an e-commerce blinds shop with additional services like AR, swatches, and price matches justifies the count. A couple of legacy tools (create_order, submit_enquiry) add minor bloat.
The core purchase flow (search, configure, cart, checkout, payment, order tracking) is fully covered. Additional services like AR visualization, swatches, price match, and WhatsApp handoff are present. Missing features like order listing or coupon application are minor gaps.