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

Goes well beyond the annotations: it discloses setup-mode-only (no charge), automatic card saving on completion, a one-time URL that must be opened in a browser, and the 409 bacs_business_only failure mode. These are side effects and constraints an agent could not infer from readOnlyHint/destructiveHint alone.

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?

Front-loaded with the return value and the required agent action, and every sentence carries information. The density of parentheticals in the final sentence is the only minor readability cost.

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?

No output schema exists, and the description still names the return field (checkout_url) and explains the agent's next step. It also covers eligibility and error behavior, so nothing an agent needs to call it 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% and the enum is already documented, but the description adds real meaning: 'card' is the default and 'bacs_debit' sets up a mandate that settles the monthly tab, business accounts only. It doesn't add format or syntax details, but none are needed for a single enum.

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 concrete verb and resource: returns a one-time Stripe Checkout URL so the user can add a card, and also covers the Bacs mandate variant. It is clearly distinguishable from the sibling payment_methods_list and from purchase_* intent tools.

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?

Explicitly instructs the agent to hand the checkout_url to the user and says 'there is nothing else for the agent to do', with clear eligibility rules (buyer principals only; business accounts only for Bacs, and only while Bacs settlement is enabled).

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