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

Annotations cover the safety profile (not read-only, not idempotent, open-world), and the description adds substantial context beyond them: no money moves, nothing is reserved, nothing is charged until the person signs, unpaid sessions simply expire, and each call opens a NEW session so the token must be reused rather than the tool re-called.

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?

Purpose is front-loaded and the sentences are dense with actionable detail. There is mild redundancy between "moves no money and reserves nothing" and "nothing is charged until the person signs", but overall the length is justified by the workflow and return-value guidance.

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?

With no output schema, the description compensates by naming the returned fields (page_url, exact amount, expires_at, and a token for get_checkout_status), and it covers prerequisites, side effects, expiry behavior, and the sibling alternative. Nothing needed to call or follow up correctly 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?

Schema coverage is 100%, so the baseline is 3. The description still adds ordering semantics (price with get_quote first, then pass service_id/quantity/link) and explains that ttl_seconds holds the price with a 30-minute default, which reinforces the parameter's effect rather than merely restating it.

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 ("Create a checkout session") and immediately characterizes it as a payment link a person opens and pays in their own wallet on Base or Solana. It explicitly distinguishes itself from create_paid_order, so an agent can route correctly without opening either schema.

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 an explicit when-to-use condition ("when you cannot sign a payment yourself or the user wants to pay with their own wallet"), names the alternative with the opposite condition ("Prefer create_paid_order when you hold a wallet and should pay yourself"), and prescribes the upstream workflow (search_catalog / recommend_service then get_quote).

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