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

With no annotations provided, the description carries the full disclosure burden and does so exceptionally. It reveals the cost per property, authentication requirement, the fact that it delegates to assess_property_hazard, and the exact JSON return structure. It also explicitly states 'no invented portfolio-level risk score', setting honest expectations about limitations.

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?

Although dense, the description is efficiently structured: cost and limits first, then purpose, then behavior, then prerequisite, then auth, then return format. Every sentence delivers critical information without padding. It's long but every element earns its place.

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 fully equips an agent to decide when to use the tool and how to call it correctly. It covers cost, limits, authentication, the underlying mechanism, the output schema, and the prerequisite invocation of estimate_cost. Nothing essential is missing.

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?

The schema only provides an array of number arrays with no descriptions (0% coverage). The description compensates by explaining that each property is a [lon, lat] pair, clarifying the meaning of the single 'properties' parameter. It also ties the parameter to the cost calculation via estimate_cost.

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 clearly states the tool's purpose: bulk physical climate-risk disclosure input for a real-estate/asset portfolio (SEC/CSRD). It explicitly says it runs assess_property_hazard for each [lon, lat] property, distinguishing it from sibling single-property assessment tools. The wording is specific and includes the exact use case.

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?

It provides explicit usage guidance: use estimate_cost first to quote, and it implies this is the batch/portfolio version of assess_property_hazard. It also notes limits (max 25 properties/call) and discloses that the tool is paid. This gives clear context for when to use this tool vs alternatives.

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