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

Goes well beyond the annotations: it discloses that the call is free with no gas, that it records photo hashes and on-site GPS against the packet's 350 m place, that a far GPS is flagged for human review rather than auto-rejected, and that nobody is paid and nothing is accepted. It also names the key custodian (own wallet or passkey, house never holds a key), all of which annotations only crudely signal via readOnlyHint=false / destructiveHint=false.

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 action and endpoint, then supporting constraints; every clause carries information. There is mild redundancy, since freedom-with-no-gas is stated twice ("FREE with a valid signature" and "free, no gas"), and the all-caps clarifications add density.

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?

Covers what an agent needs for a two-step signing flow: prerequisite, exact inputs to reuse verbatim, signing requirement, cost, side effects on GPS/hashes, and the fact that no payout or acceptance happens here. Return values are covered by the output schema, so nothing material 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?

Schema coverage is 100%, so the baseline is 3; the description adds a constraint the schema does not state, namely that the signature must come from the claiming wallet. Otherwise it largely restates the three parameters (workId, unchanged bodyJson, signature over MESSAGE_TO_SIGN), so it sits just above baseline.

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 ("Relay the signed physical proof") and pins it to the exact endpoint POST /labor/work/:workId/physical-proof. It explicitly positions itself as step 2 of 2 relative to prepare_physical_proof, so an agent can distinguish it from that sibling without opening either schema.

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?

Clear usage context: call after prepare_physical_proof, passing that call's BODY_JSON unchanged plus the signature over MESSAGE_TO_SIGN, and only with a signature from the claiming wallet. It names the prerequisite sibling explicitly but gives no negative conditions (e.g., what to do if the packet is already submitted or the signature is invalid), which keeps it short of a 5.

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