Get the billing portal link

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

Annotations already mark the operation non-destructive and idempotent; the description adds specific behavioral detail about cancellation (data remains stored/readable and the account reverts to free quota at period end). It does not address things like link expiration or auth requirements, but for this simple tool the added context is valuable.

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 short sentences, each earning its place: the core function, the intended user, and the cancellation behavior. The main action is front-loaded and there is no filler.

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 zero-parameter billing-portal-link tool, the description tells the agent what the tool does, who should receive the link, and what happens on cancellation. No output schema exists, but 'link' plus 'for the human to open' sufficiently communicates the returned artifact.

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?

The tool has zero parameters and the schema coverage is essentially complete, so there is no parameter meaning left for the description to add. Baseline for no parameters is 4, and the description contains nothing that muddies parameter behavior.

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 ('Get') and resource ('Stripe Customer Portal link for a paid plan') and lists the supported actions (cancel, change card, download invoices). It does not explicitly contrast itself with sibling tools, so it stops short of the clearest possible sibling differentiation.

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 gives clear context: the link is intended for a paid-plan human user and is meant to be opened by the human, not used programmatically. It does not explicitly name alternatives or state when not to use the tool, which keeps it from a 5.

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