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

Beyond the annotations (destructiveHint=true, openWorldHint=true), the description discloses the cost per stage ($15 each), the separate-invoice billing model, that completed stages remain consumed if a later stage fails, and that there is no atomic bundle charge or automatic transfer. For a destructive, paid, partial-failure-prone workflow these are the exact non-obvious traits an agent needs before invoking it.

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 sentences, front-loaded with what the workflow does, then the fixed sequence, then billing semantics — no filler. Slightly dense with internal engine names and inline pricing, but every clause carries operational meaning.

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?

Given five nested parameters, no output schema, and a destructive billed workflow, the description covers sequence, cost, and partial-failure behavior well. It does not describe what the caller receives at the end (e.g. a classification CSV plus an exceptions report) or flag the mandatory external-processing consent gate, which are the remaining gaps.

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 60%, so the schema already documents most nested fields; the description reinforces the stage grouping (classification inputs vs exceptions inputs) and the notion of one invoice per stage, which implicitly explains paymentInvoiceIds. It adds nothing about maxChargeUsd, idempotencyKey, or consentExternalProcessing beyond what the schema text already says, leaving it at baseline.

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 states a specific multi-stage verb chain (classify → verify row preservation → compare against approved suppliers/contracts/POs) and names the exact underlying paid engines (xspend-taxonomy, xmaverick-detector). It is trivially distinguishable from sibling workflows like renewal_to_negotiation or rfp_to_bid_review because the stages and inputs are enumerated.

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 a fixed execution order ('classification → exceptions') and clarifies that the two paid stages are not bundled, so an agent knows this is the orchestrating entry point rather than two separate calls. What's missing is an explicit exclusion such as 'do not call xspend-taxonomy directly if you intend to run the full compliance pass', so it stops short of full when/when-not guidance.

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