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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds the failure modes an agent actually needs: amount_paid is overwritten on renewal so latest_payments is a run-rate, lifetime_net counts only charges whose Stripe webhook reached this app and silently under-counts on missed renewals, and lifetime_net is null when no accrual record exists. This is exactly the beyond-annotation context the dimension rewards.

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?

It is one dense paragraph that front-loads the returned fields and pushes caveats after, with no filler sentences. The heavy parenthetical nesting makes it longer and harder to scan than necessary, but nearly every clause carries operational meaning.

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 full burden of explaining return fields — and it does, including null semantics and why figures may be understated. Only the include_samples parameter is unaddressed, and that gap is already scored under parameter semantics.

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 0%, so the description must carry both parameters. It clarifies app_id ('optionally scope by app_id; omit for platform-wide totals') well, but include_samples is never mentioned anywhere, leaving the second of two parameters undocumented.

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+resource (revenue and subscriber summary) and enumerates exactly what is returned: latest_payments, refunds, approximate MRR, active/trialing/paid counts, and lifetime_net. The two non-obvious metrics are distinguished from each other in-line (run-rate vs. cumulative per-owner net), so an agent understands the scope without opening anything else.

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 an explicit exclusion with an alternative: 'For turnover, accounts or tax, read Stripe directly: it is authoritative,' and it tells the agent when a 0 is an absence-of-record rather than an absence of sales. It does not name a sibling tool (e.g., revenue_by_app) as the scoped alternative, which keeps it just short of a 5.

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