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

With no annotations, the description carries the full burden and does disclose real behavior: the call returns a `url` the customer must be sent to, amounts are decimal strings rather than minor units, and order fulfilment must be driven by the invoice.paid webhook rather than the browser redirect. It omits auth requirements, what happens to expired sessions, and error/idempotency behavior (the latter only appears in the schema).

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?

Four tight sentences with zero filler: identity of the resource, the required redirect action, the two format constraints that most often cause bugs, and the fulfilment rule. The most actionable guidance (redirect to `url`, fulfil from webhook) is front-loaded.

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 17-parameter tool with nested objects, no annotations, and no output schema, the description covers the core contract — what gets created, what comes back (`url`), and how the order lifecycle completes. Remaining gaps are auth/prerequisite context and any note about test-mode sessions, which sibling simulate_test_payment implies exists.

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 coverage is 59% across 17 parameters; the description only reinforces `amount` (decimal string) and `currency` (ISO code or asset id), both of which the schema already documents. Undocumented-in-schema params such as `locale`, `branding`, `customer`, `line_items`, `cancel_url`, and `collect_email` get no compensating explanation in the 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 opens with a specific verb and resource ('Create a CoinVello hosted checkout session') and immediately glosses the artifact ('an invoice plus a payment page at pay.coinvello.com'), which is far more informative than the title alone. It doesn't explicitly contrast with siblings like create_credit_purchase or simulate_test_payment, so routing between creation tools is left to 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?

Gives concrete operational guidance: 'Redirect the customer to the returned `url`' and 'Fulfil orders from the invoice.paid webhook, never from the redirect' — an explicit when/when-not for downstream fulfilment that prevents a common integration error. It stops short of saying when to choose this tool over create_credit_purchase or when to use simulate_test_payment instead.

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