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 billed cost ($4.00 per call in USDC), the no-charge failure mode (422 on UNKNOWN zoning/flood zone), citation behavior, and data freshness date. It stops short of describing authentication, rate limits, or the exact failure/retry semantics for other error classes.

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 report scope, then cost and failure semantics, which is the right ordering for an agent. The trailing 'Verified: 100% golden accuracy… 100% uptime' cluster is mildly promotional but does deliver trust-relevant information compactly.

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 compensates for the missing output schema by enumerating the returned report sections, and it covers pricing and the UNKNOWN failure path. However, with seven parameters at zero schema coverage and no annotations, an agent still lacks guidance on supplying jurisdiction/district/coordinates or on what happens for other error conditions.

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?

Seven parameters, two of them required, with 0% schema description coverage, yet the description only vaguely gestures at 'address/parcel' and implies proposed_use via 'allowed-use verdict'. It says nothing about jurisdiction (required), district, or latitude/longitude, so most parameters are undocumented in both the schema and the description.

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?

Names a specific verb and resource ('Site feasibility report for an address/parcel') and enumerates exactly what the report contains: zoning, allowed-use verdict, permits, recent decisions, FEMA NFHL flood zone and soil. This clearly distinguishes it as a composite report versus the granular siblings get_zoning, check_use_allowed, get_soil and get_recent_decisions.

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?

Usage is only implied by the composite nature of the tool; the description never says 'use this instead of calling get_zoning + check_use_allowed separately' or when a lighter single-purpose call is preferable. It does add one useful decision rule (a 422 with no charge when zoning or flood zone is UNKNOWN), but there is no explicit sibling routing.

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