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

Annotations already declare readOnly=false and openWorld=true, so the write/external nature is covered; the description adds real value by naming the payment provider (Stripe), the human approval gate, and the session_id handoff. It does not say what happens on repeated calls (annotations say non-idempotent, but the description never clarifies that each call creates a new checkout session) or how failures/expired sessions behave.

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 tight sentences: purpose first, then return values and the follow-up call, then the safety instruction. Every sentence carries actionable information and nothing is repeated from the schema or title.

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?

Although there is no output schema, the description covers return values (checkout URL, session_id), the required input provenance, the next tool call, and the human-approval constraint. For a one-parameter tool this leaves no significant gap an agent would need to call it 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?

There is a single parameter at 100% schema description coverage, which itself points to list_decisions as the source with an example format. The description adds nothing about decision_id beyond that, so the schema baseline of 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?

States a specific verb and resource: 'Starts a Stripe checkout for the full evidence behind one decision', and enumerates what the purchase includes (sourced/dated figures, what would flip the answer, stated limits). It is clearly distinguished from the sibling get_decision_evidence, which is framed as the post-payment 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?

Gives explicit sequencing: call this to pay, then 'After the user pays, call get_decision_evidence with both ids.' It also states a hard prerequisite — 'Always show the price and get the user's go-ahead before sending them to pay' — so the agent knows both when to call it and what must precede it.

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