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

Annotations only declare this is a non-readonly, non-destructive, non-idempotent write with no output schema, so the description carries real weight and delivers: the card is saved with Stripe once via setup_url, funds are only captured after delivery, budgets and per-order caps bound spending, and it is revocable. What is missing is whether calling this returns the setup_url or a mandate id, and who must confirm with Stripe.

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?

Three dense sentences with no filler, and the audience tag plus core mechanism are front-loaded. The setup_url reference is slightly ambiguous, but overall the text earns its length.

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 mutation tool with no output schema, the description explains the mechanism, charge timing and revocation well, but leaves out the return value (setup_url / mandate id) and the consent flow with the principal, which an agent needs to sequence the call correctly.

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 description coverage is 100%, so the parameters (budget, cap, currency, purpose) are already documented. The description reinforces the budget/cap concept but adds no syntax, units or defaults beyond the schema, so baseline 3 applies.

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 conveys a specific action on a specific resource: the buyer's principal grants a spending mandate (a saved Stripe card plus budget/cap) so purchases need no payment link. It distinguishes itself from revoke_mandate and buy, though it never says plainly "creates a mandate object" and instead describes the mechanism, which costs a bit of directness.

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?

Usage is implied through related tools: the mandate is what buy uses to authorise, and revoke_mandate is named as the undo. However, there is no explicit statement of when to call this versus siblings like set_budget, mandate_status or buy, and no stated prerequisites.

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