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

Annotations already declare a non-destructive, closed-world, read-only operation, but the description adds genuinely non-obvious behavior: card data is held by Stripe (no card details pass through this tool) and the credit is deferred until the payment completes, not immediate. That deferred-effect disclosure is exactly what the agent needs to avoid telling the user the balance changed. It still omits link expiry, what happens if the user abandons checkout, and whether the returned URL must be opened in a browser.

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 short, front-loaded sentences that put the action ('Erstellt einen Stripe-Checkout-Link') first and the caveats second. The only waste is the full German/English duplication, which doubles the text length for no additional information, though it appears to be a house convention echoed in the schema.

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?

There is no output schema, so the description carries the burden of explaining the return value; it says a checkout link is created but never states that the URL is what comes back, nor its validity window or reuse behavior under requestNonce. With three parameters and one (reasoning) undocumented in both schema and description, the definition is adequate but leaves real gaps for a payment-flow tool.

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 67%: amountEuros carries its 10–500 range in German and English directly in the schema, and requestNonce's retry-idempotency semantics are fully spelled out there, so the description correctly adds nothing for those. The description does implicitly establish that amountEuros is the top-up value, but gives no hint about the purpose of the undocumented 'reasoning' parameter. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Creates a Stripe checkout link to top up your wallet balance'), which is unambiguous about the outcome. It is trivially distinguishable from the only other wallet sibling, wallet_balance, since one generates a funding link and the other reads a balance. No tautology, no restating of the title.

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?

The scenario where this applies (user wants to add funds) is strongly implied by the name and description, but there is no explicit when-to-use guidance, no mention of prerequisites (e.g. must the wallet be empty, is there a KYC/verification requirement), and no contrast with wallet_balance or any alternative funding path. Nothing is misleading, but the agent must infer the trigger conditions.

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