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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description goes further by explicitly saying 'Read-only' and adding the non-custodial settlement detail: 'earnings settle non-custodially to your withdrawal address on release.' This discloses behavior beyond what annotations provide, such as the mechanism and timing of earnings settlement, which helps the agent set user expectations correctly.

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?

The description is two sentences with no filler. The first sentence immediately states the goal and scope, and the second compactly lists all return categories plus the key settlement behavior. Every phrase earns its place, and the structure is easy to parse.

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 read-only tool with no output schema, the description is remarkably complete. It enumerates every category of returned data, confirms the operation is non-destructive, explains how earnings flow to the user, and relies on the schema for owner derivation. No critical information is missing for calling this tool correctly.

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?

With zero parameters, the baseline is 4. The schema already states 'No arguments — the owner is derived from the authenticated principal,' and the description doesn't need to explain parameters. Nothing is missing; no extra parameter semantics are required.

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 uses a specific verb ('Check') and a specific resource ('how much I have earned and what is pending'), then enumerates exactly what is returned: lifetime USDC, in-flight pending amounts, unclaimed claim-later rewards, payout-address balance, buyer spend summary, and first-agent reputation. This clearly distinguishes it from sibling tools like get_agent_contract or find_paid_work, which target different resources.

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 tool's purpose is stated clearly at the front, making the intended use obvious: check seller earnings and pending amounts. It doesn't explicitly name alternatives or give when-not-to-use conditions, but given the distinct resource (earnings/rewards/payouts) and the fact that all parameters are absent, the usage context is unambiguous. A 4 is appropriate for clear context without explicit exclusions.

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