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

With no annotations present, the description carries the full burden and addresses it thoroughly: it states that the tool fetches the rent-roll record, recomputes every hash locally, checks the link against the ledger's /api/commitments, and opens winner_env with the salt. It also explicitly discloses trust boundaries ('Nothing is taken on the door's say-so') and what remains trusted, which is exactly the behavioral context an agent needs.

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 purpose, and the following sentences each add substantive detail about the verification steps and trust model. It is longer than strictly necessary and the hash checks are packed into one dense sentence, but there is little wasted wording.

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?

The description thoroughly explains the verification algorithm and trust boundary, which is important given there is no output schema or annotations. However, it does not state the return value or success/failure behavior (e.g., does it return a boolean, throw on mismatch, or produce a report?), and it gives no usage context relative to siblings. These are meaningful gaps for an agent invoking the tool.

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 description coverage is 0%, so the description must add meaning to the three parameters. It does: lease_json is implicitly the named rent-roll record, salt is used in the winner-envelope hash, and amount_degrees is used only when the bid differed from clearing price. It does not explicitly map each parameter or describe formats, but it provides significantly more context than the bare schema.

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 specific verb and resource: 'Verify a lease LOCALLY against the public chain', which is clear and not a tautology. It goes on to detail the exact verification checks, but it does not explicitly distinguish this tool from sibling tools such as rent_roll or tell_the_house, so it stops short of full differentiation.

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 explicit guidance on when to use verify_lease versus the sibling tools, nor any mention of prerequisites or exclusions. The reader can infer that this is for local lease verification, but the description never states the conditions that should trigger this tool or when another tool would be more appropriate.

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