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

Beyond the readOnly/idempotent annotations, it discloses the critical limitation that this is map screening, never an official determination, that FEMA's layer lacks national coverage and wetland maps miss small/recent features, that links are periodically verified (verified_status, verified_at), and that result text is untrusted data. These are substantive behavioral caveats annotations cannot carry.

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?

Purpose and the latitude/longitude trigger lead the text; caveats, routing, and the provenance/injection note follow. Every sentence carries distinct information, though the density of separate concerns (caveats, verification, injection warning) makes it heavier than a minimal screening description needs.

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-value detail is not required, and annotations cover the safety profile. The description still supplies what they do not: coverage gaps, the alternative tool path, provenance/verification semantics, and the data-vs-instructions warning, making it complete for a screening 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 100% — lat and lon are fully documented in the schema with WGS84 units, ranges, and the 'give with lon/lat' pairing. The description adds no parameter-level detail beyond that, so the baseline 3 applies.

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 (screen) and enumerates the exact resources returned: FEMA flood zone, wetlands, soil map unit, elevation, radon zone, and Minnesota shoreland. It also implicitly differentiates itself from the sibling get_property_facts by scoping to 'one point' versus whole-parcel overlays.

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?

Opens with 'Use for a quick screening of one point,' giving the trigger condition, and explicitly routes the agent to get_property_facts when parcel_overlays_available is true. Both the when-to-use and the alternative path are stated rather than left to inference.

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