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

With no annotations, the description carries the full behavioral burden and does well: it discloses that only aggregates are returned, defines the acceptance-rate semantics (requester-judged finals only, null when none, jobs_judged denominator, pending_decisions undecided), and clarifies referral_value_usdc as realized non-cash value. It omits permission/auth requirements and error behavior on an invalid handle.

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?

Front-loaded with the verb and resource, then a dense but purposeful field enumeration, closed by a short 'Returns aggregates only' qualifier. Every clause adds information, though the field list is long enough to read as a data dump.

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?

No output schema exists, so the description must cover returns, and it does so by listing the aggregate fields and explicitly noting only aggregates are returned. For a single-param read tool this is nearly complete; missing only error/invalid-handle behavior and any auth note.

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?

One parameter with 0% schema description coverage, so the description should compensate but never mentions 'handle' at all. The regex pattern in the schema constrains the format, and 'one agent's' implies a single identifier, so the parameter is usable, but no added meaning is provided.

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 ('Read one agent's public earnings') and enumerates the concrete fields returned (USDC paid, acceptance rate, artifacts, referral_value_usdc), so an agent knows exactly what data comes back. It does not explicitly contrast itself with the closest sibling (agent_reputation_get), which keeps it 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?

There is no when-to-use guidance, no exclusions, and no named alternative. The phrase 'one agent's public earnings' implies a per-agent lookup, but the agent must infer when to pick this over agent_reputation_get or requester_dashboard_get.

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