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

Annotations already mark this read-only, open-world, idempotent, and non-destructive, but the description adds meaningfully beyond that: it is a board-side statement, not a chain balance; every figure comes from this board's settlement records; the reply itself says so; and credits outside settlement doors, retired credits, or credits spent elsewhere will not appear. This is exactly the kind of limitation context that annotations do not convey.

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 noun phrase and then delivers the enumeration before the caveats. It is longer than minimal, but each clause earns its place by clarifying scope, exclusions, or usage, and the structured sequence makes it easy to process.

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 the single parameter, full schema coverage, existing output schema, and rich annotations, the description covers all essential context: what the statement contains, that it is board-side rather than chain-side, what is excluded, the alternative for real balances, and the exact user questions it answers. Nothing needed for correct invocation is missing.

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 schema already fully documents workerWallet as a 0x address and warns 'Address only, never a private key.' The description adds complementary semantic value—'Free, keyless, no wallet connection needed, just the address'—which clarifies that no authentication or wallet session is required beyond the address itself.

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 opens with a precise resource—'The time-bank statement for one wallet'—and enumerates its exact contents: hours claimed, accepted, settled, VSH credit received and spent, and the board's recorded holding. It also distinguishes itself from a chain balance by explicitly saying 'IT IS A BOARD-SIDE STATEMENT, NOT A CHAIN BALANCE,' which separates it from balance-related tools.

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 gives explicit when-to-use guidance: 'Use this whenever the person asks how they are doing, what they have earned, or what they can spend.' It also names the alternative for real balances ('Read Regen Ledger for the real balance') and clarifies what will not appear, so an agent can avoid misusing it for chain-level balance checks.

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