agentee-mcp

Prepare checkout

prepare_order

Creates a draft order from the cart, address, and promo code and returns a pre-filled checkout URL for the human to review and pay.

Instructions

Turn the cart, address and promo into a draft order and return {checkout_url, draft_id, expires_at}. Send checkout_url to the human: checkout opens pre-filled and they review and pay themselves — the agent never pays. Call it only after showing get_order_preview and getting the human's OK. Each call creates a NEW draft with its own number, so call it once per purchase; the cart itself is not emptied. The draft expires after 48 hours. Prices are re-checked; an empty cart, a missing address or no orderable items return an error (with issues) and create nothing.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description
`note`	No
`error`	No	Empty cart, missing address or no orderable items.
`total`	No
`issues`	No
`currency`	No
`draft_id`	No	Draft order number.
`expires_at`	No	ISO 8601 time when the draft expires (48 h).
`checkout_url`	No	Pre-filled checkout link — send it to the human to review and pay.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the annotations: each call creates a new non-idempotent draft, the cart is not emptied, drafts expire in 48 hours, prices are re-checked, and empty cart / missing address / no orderable items produce an error with issues and create nothing. The new-draft-each-call note reinforces the non-idempotent hint rather than contradicting it.

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

Conciseness5/5

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

Front-loaded with the action and return shape, then the human-handoff, then preconditions, then side effects and failure modes. Every clause carries distinct operational information with no repetition.

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?

Even though an output schema exists, the description still names the key return fields and adds the failure and expiry semantics an agent needs. For a zero-parameter, state-driven checkout step, nothing material is missing.

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 there is nothing for the schema to document; the description compensates by explaining that the inputs come from cart, address and promo state already established by sibling tools. It stops short of naming which setters feed it, but no parameter-level guidance is needed.

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?

Opens with a specific verb and resource ("Turn the cart, address and promo into a draft order") and immediately enumerates the returned fields. It is clearly distinguished from get_order_preview, which it names as the prior step rather than an alternative.

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 it only after showing get_order_preview and getting the human's OK" gives both the prerequisite and the alternative. It also states the correct call frequency ("once per purchase") and that the human, not the agent, completes payment.

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