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

With no annotations, the description carries the full burden. 'Ask Stripe whether' usefully signals a read-only, external network query rather than a mutation, which is the key behavioral fact here. It stops short of disclosing edge behavior such as what happens for an unknown or expired session ID, or whether the call is rate-limited.

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?

A single, front-loaded sentence with zero filler. The purpose is delivered in the first clause and nothing is repeated.

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 one-parameter read tool this is close to adequate: the phrase 'whether ... has been paid' implies a boolean-style answer, partially covering the absent output schema. Missing details about error conditions for invalid session IDs and the exact response shape leave a small but real 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 coverage is 0% for the single 'sessionId' parameter; the only type hint (string) comes from the schema itself. The description's mention of a 'checkout session' gives implicit context that sessionId is a Stripe checkout session identifier, which partially compensates but does not supply a format or example.

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 states a specific verb-resource pair: querying Stripe about the payment status of a checkout session. An agent can distinguish this from the sibling 'buy' (which presumably initiates payment) and 'decide'. It does not, however, explicitly contrast itself with either sibling, so it stops 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?

No guidance on when to call this versus 'buy' or 'decide' is provided. The description implies it is a post-checkout verification step, but that inference is left entirely to the agent. No prerequisites, exclusions, or ordering hints are given.

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