environmental_site_audit

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It explains that the tool computes a composite scorecard, returns a JSON string, and references specific indices and DEM data. However, it does not disclose potential execution cost/time, data availability limitations, whether any resources are created, or what happens when a location cannot be resolved.

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 description is well-structured with a numbered indicator list and clear Args/Returns sections, making it easy to parse. The academic references and the 'Create with Compute' phrasing add some noise but do not prevent efficient use.

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?

For a three-parameter tool with an output schema, the description covers the input semantics, default behavior, return type, and the four analytical layers. It is slightly incomplete in not distinguishing use cases from sibling tools and not explaining the 'Create with Compute' pattern, but overall it provides enough for an agent to invoke it correctly.

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 coverage is 0%, but the description fully compensates by explaining all three parameters: location includes named examples and bbox syntax, datetime_range is described as an observation window with a default, and format lists the allowed output values. This goes well beyond the bare schema.

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 states a specific verb and resource: 'Produces a holistic environmental and climate scorecard for any city or region' and enumerates four concrete indicator groups (NDVI, NDWI, DEM, thermal/flood hazard). This clearly distinguishes it from specialized sibling tools like detect_water_sar or calculate_spectral_index.

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?

The phrase 'holistic environmental and climate scorecard' implies this is for broad multi-layer audits rather than single-metric analysis, which gives some context. However, the description never explicitly states when to use this tool versus siblings such as assess_location_hazard, analyze_urban_heat_island, or detect_water_sar, and it offers no exclusion criteria.

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