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

Annotations already declare readOnlyHint=false and openWorldHint=true; the description reinforces this by stating the product is created on the member's external Stripe account, and it discloses a concrete failure mode and error code (payments_not_set_up). It stops short of covering idempotency or duplicate-product behavior, which matters for a create call with no output schema.

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?

Two compact clauses separated by a semicolon, front-loading what is created and then the blocking precondition. The redundant restatement of the monthly flag is minor waste but nothing is padded.

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 9 parameters fully covered by the schema, annotations carrying the safety profile, and no output schema to explain, the description only needs to cover non-obvious behavior — and it does, via the Stripe account context and the setup prerequisite. Duplicate-handling and whether repeated calls create multiple products remain unstated, which is the main residual gap.

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 every parameter including priceCents, currency, monthly, person, and dry_run is already documented in the schema. The description's only parameter-relevant remark ('monthly true bills monthly') merely restates the schema's 'Bill every month' and adds no format, default, or interaction detail, 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 names a specific verb and resource ('Create something to sell with its price') and adds the destination ('on the member's Stripe account'), so the agent knows this provisions a billable product in Stripe rather than mutating local data. The phrasing 'something to sell' is looser than 'product with a price' would be, and it does not explicitly contrast with other pay-related siblings, keeping it short of a 5.

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 supplies one genuinely useful precondition: calls are refused with payments_not_set_up until start_payments_setup is finished, which effectively routes the agent to that sibling first. However, there is no guidance on when to use this versus other payment tools (e.g., checking status with connections_pay_payments_setup_status) or what to do if a product already exists.

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