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

With no annotations, the description carries the full burden and does substantial work: it discloses the 30-day watch window, HMAC-signed webhook delivery with retries, the $4.00/30-day USDC price, and that UNKNOWN results are never charged. It omits how to stop the watch (cancel_watch), whether re-registering the same parcel duplicates a watch, and any auth/credit-balance requirement, which keeps it below a 5.

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 first sentence is excellent and front-loaded with scope, delivery, and price. The second sentence is largely promotional telemetry ('100% golden accuracy (78/78), 100% page-cited, 100% uptime (24h)') that consumes attention without helping an agent decide or invoke, and a data-as-of date adds only marginal freshness value.

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?

There is no output schema and no annotations, so the description must cover the full contract; it handles cost, cadence, and webhook delivery but leaves the required jurisdiction and parcel/address semantics undefined, and does not point at sibling tools for coverage checks or cancellation.

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 five parameters (including required jurisdiction and webhook_url) are undocumented anywhere. The description only glancingly implies a parcel identifier and an HTTPS webhook URL; it says nothing about label, address, or the expected format of jurisdiction, and never clarifies whether parcel is an APN versus a free-form string.

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 (watch), a specific resource (a parcel), the duration (30 days), the trigger (new permits or decisions touching it), and the delivery channel (HTTPS webhook). The parcel scope implicitly distinguishes it from the sibling watch_town, and an agent can tell what the tool does before opening the 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?

Recurring monitoring is clearly implied, so the agent can infer when to call it, but there is no explicit guidance on parcel-level vs town-level watching (watch_town exists), no pointer to list_watches/cancel_watch for lifecycle management, and no stated precondition such as a supported jurisdiction (check_coverage exists).

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