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

The annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds value by disclosing the returned content, including pending orders and the withdrawal-availability timing, but it says nothing about volume, ordering, time window, or pagination — an agent cannot tell whether this returns every historical deal or a recent slice.

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 sentence, front-loaded with the core resource and then the returned fields, with no filler. The colon-and-semicolon structure is dense but readable; minor grammar roughness ('you brought') costs a point.

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 no input parameters and no output schema, the description carries the full burden of explaining returns, and it does list the key fields. However, it omits the scope of the result set (all-time vs recent), any ordering or pagination behavior, and how 'your share' is computed — gaps that matter for a reporting-style 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?

The tool takes zero parameters, so there is nothing for the description to clarify beyond the schema. Baseline 4 applies; the field list is a small bonus but not required here.

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 the resource (paid service orders the caller brought) and enumerates the returned fields (service, amount paid, your share, withdrawal availability) plus a second bucket of unpaid orders. This is specific enough to distinguish it from siblings like request_payout or account_status, though it never uses an explicit verb such as 'list' and the phrase 'orders you brought' is slightly awkward.

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?

There is no when-to-use guidance and no mention of alternatives, even though request_payout and account_status are obvious neighbours an agent could confuse this with. The only scoping signal is implicit: the tool covers paid and awaiting-payment orders, so an agent must infer that payout execution belongs elsewhere.

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