env_noise_aircraft_at

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context: results are based on isolines (not interpolation), output is a bracket with upper bound, and the result is an orientation basis, not a building permit. No contradiction with annotations.

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 clear sections (purpose, use case, important notes). It is slightly verbose but each sentence adds value. The important notes are appropriately emphasized with <important_notes> tags.

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?

Given the tool's complexity (coordinate system, isolines, multiple periods), the description is thorough. It covers input requirements, output structure (dB value, bracket, provenance, PDF link), and limitations. The use case is concrete. No obvious gaps remain.

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?

Despite schema descriptions for parameters, the tool description adds significant value: it warns about coordinate system confusion (LV95 vs WGS84), gives concrete examples (Zürich HB), explains each period value in detail, and warns that a large radius_m overestimates noise. These details are not in the schema alone.

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 evaluates aircraft noise at a point using official BAZL noise cadastre data. It specifies the exact question answered ('Liegt dieser Standort in einer Fluglärmzone — und in welcher dB-Stufe?') and distinguishes itself from sibling tools like env_noise_aircraft_registers or env_noise_limits_check by focusing on point-based noise level lookup.

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 description provides explicit usage context: site assessment for construction projects. Important notes clarify coordinate system requirements (LV95, not WGS84), the nature of results (isolines producing a dB bracket), and that output is for orientation only. While it doesn't explicitly list when not to use, the constraints are clearly stated.

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