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

Annotations already mark the operation as read-only, idempotent, and non-destructive, and the description adds valuable behavioral detail without contradiction: it never holds a key, never signs, never pays; it reads live chain state and refuses with a plain reason when the step would fail; it eth_calls the exact transaction from the wallet before returning. It also discloses meaningful side effects such as 'location is written on chain PUBLICLY and PERMANENTLY'.

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 long but densely packed with information relevant to a 14-parameter, complex lifecycle tool. It front-loads the core purpose and safety model before enumerating per-step fields. A few rhetorical phrases ('with no house involved and no house money') could be trimmed, but they do not undermine clarity.

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 tool of this complexity, the description is remarkably complete: it covers chains, wallet ownership, gas payment, failure preflight checks, per-step required fields, public/permanent data risks, how to get workId, and when to consult other tools. Since an output schema exists, the lack of return-format detail is not a gap.

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 input schema already covers 100% of the 14 parameters, so the baseline is 3. The description adds real semantic value beyond the schema: price is stored as cents, proofHash must be 64 lowercase hex characters with no 0x prefix, tokenContractAddress can be 'native', standard defaults to workType, and settle is a receipt that moves no money. This goes beyond simple restatement.

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 states a specific verb ('Build'), a precise resource ('exact unsigned transaction for one step of a real ecological-work job's lifecycle'), and enumerates all supported step types (post, claim, unclaim, prove, approve, reject, cancel, settle). It also distinguishes itself via 'on Base or Robinhood Chain' and 'non-custodial', so it is clearly differentiated from the many prepare_* siblings.

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 agents when to use this tool versus related ones: 'Call chain_work_status first if you are unsure of a job's current state' and 'use the free anchor_proof tool' to hash evidence. It also clarifies when not to use it for settle ('this call is a receipt, not a payment, and moves no money by itself'), giving clear decision context.

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