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

Annotations already declare a non-read-only, open-world, non-destructive write, and the description goes well beyond them: live stock check, the `unavailable` error path with no order or link produced, the requirement to hand the checkout URL to the user as-is, the fact that no card is held or charged, and an idempotency-key scheme where a reused key returns the same link with `repeated: true`. The only gap is that `idempotentHint: false` sits in mild tension with the described key behavior and is not reconciled, though it is not a real contradiction since idempotency only applies when the optional key is supplied.

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 consent warning is correctly front-loaded, but the text is dense and partially repetitive — explicit user agreement is stated three times (opening warning, "Get the user's explicit yes", and the closing server-instructions paragraph), and the status enumeration is inline prose rather than a compact list. Substantively every sentence is useful, but the repetition and length cost it.

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 multi-platform mutation tool with no output schema, the description supplies what an agent needs to act safely: per-platform side effects, the returned fields (`order_id`, `status`, `checkout_url`), the full status vocabulary including `unknown`/`pending_owner`, failure modes, and retry semantics. Nothing material about calling or interpreting the result is missing.

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?

With schema coverage at 60%, the description carries real weight: it explains that lines reference offerings by card id and need `variant_id` only when the card lists several variants, that `customer` is required only for WhatsApp and should be omitted for Shopify/Square, and that `note` is not forwarded on a Shopify cart link. That meaningfully extends what the schema says, though quantity bounds and line limits are left entirely to the 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 title and description state a concrete verb and resource (place an order in the business's own system, buyer pays on the platform's checkout page) and immediately enumerate what changes per platform: Shopify returns a cart link, Square returns a payment link, WhatsApp messages the owner. It is clearly distinguishable from siblings like quote_order or book_slot because it repeatedly frames itself as the ordering step.

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?

It gives an explicit precondition ("for a business whose card shows an `order` action with method `connected`") and an explicit gate ("call it only after the user has explicitly agreed to this exact action... never on your own judgement", repeated as "Get the user's explicit yes before calling this"). It also states the separation rule from adjacent steps in the same flow — keep reading, quoting, requesting and ordering separate — which tells the agent what not to fold into this call.

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