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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the heavy lifting is done. The description adds genuinely useful non-annotation context by disclosing the $0.25 USD cost, but it does not explain what 'reconcile' means operationally (merging multiple sources? conflict resolution?) or any auth/quota constraints.

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?

Two short sentences with zero filler, and the paid-cost caveat is front-loaded so an agent sees the pricing implication before invoking. It is arguably too terse, but nothing in it is wasted.

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?

An output schema exists so return values need not be documented, but the description still leaves the core operation vague: what a 'reconciliation' of code-enforcement and complaint records actually yields, and how coverage differs from sibling checks, is unstated. For a paid, open-world lookup in a dense sibling set, this is under-specified.

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% across 4 parameters, so the description must compensate and it largely does not. The phrase 'for a property' only gestures at the required address parameter; city, unit, and state are left entirely to the (undescribed) schema, offering no format, normalization, or optionality guidance.

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 ('Reconcile') and resource ('code-enforcement and complaint records for a property'), which distinguishes it from siblings like check_permits, check_zoning_context, and check_planning_activity by domain. It stops short of explicitly naming those siblings or describing what 'reconcile' produces, but the resource boundary is clear.

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 statement of when to use this tool versus check_permits, check_property_changes, or any of the other localproof check_* siblings. The only implied usage is 'for a property,' which nearly every sibling shares, so an agent gets no routing guidance.

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