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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the added value comes from the description's detail. It discloses the derivation methodology (ILOSTAT earnings weighted by employee count), provenance behavior (publisher, URL, date returned), null handling ('nothing is ever guessed'), and REGEN payout constraints from governance proposal 77. This is rich behavioral transparency beyond the structured annotations, with no contradiction.

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 front-loaded with the core concept and each subsequent sentence adds useful context: derivation, provenance, use cases, REGEN conversion, null behavior, and safety. It is somewhat long for a zero-parameter lookup tool, but the density is justified because labor_unit is a central pricing concept and the extra detail prevents misinterpretation.

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?

Given zero parameters, a rich output schema, and strong annotations, the description is complete. It explains the return value's meaning, how it is derived, where the data comes from, how missing values behave, how REGEN conversion works, and when to use the tool. There are no significant gaps an agent would need to guess about.

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 has zero parameters, so there is no parameter semantics for the description to clarify. The rubric baseline for zero-parameter tools is 4, and the description appropriately focuses on output semantics and units instead. It adds meaningful context about what the returned number represents and how it is computed.

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 resource: one number representing the dollar-per-hour value of ordinary human work, and explains that it is the pricing yardstick for the board. It clearly distinguishes itself from sibling transaction/quote tools by framing labor_unit as a reference value for judging fairness and pricing work, not moving money.

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 description explicitly tells the agent when to use it: 'Use it to judge whether a packet's pay is fair before claiming it, or to price work you are about to post.' It also clarifies a key boundary—dollars are the measure, REGEN is only the settlement asset—so the agent will not misuse the value as a REGEN price quote. This is strong usage guidance even without naming an alternative sibling.

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