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

Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description usefully adds the computational basis (both OSHA and NIOSH criteria with exchange rates), but says nothing about the 12-exposure ceiling, what happens with total hours over 24, or the units of the returned dose.

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?

One dense, front-loaded sentence covers computation, inputs, units, and standards; the trailing URL is minor filler that does not obstruct comprehension. Nothing essential is buried.

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?

With no output schema, the description at least names the two return values (daily dose and 8-hour TWA), which is the minimum an agent needs. It still leaves output units (percent dose vs. dB), the 12-item cap, and edge-case behavior unstated for a tool whose result depends on those specifics.

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 reported at 0% for the single top-level parameter, so the description must carry meaning: it establishes that levels are in dBA and durations are per-level, which maps to the dba/hours fields. It does not explain the maxItems=12 limit, whether hours must sum to a workday, or how overlapping exposures are handled.

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?

"Daily noise dose and 8-hour TWA from noise levels (dBA) and durations" names a specific computation and its inputs, plus the governing standards (OSHA 90 dBA/5 dB, NIOSH 85 dBA/3 dB). An agent can tell this apart from neighbors like heat_stress, though no sibling is named explicitly.

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 purpose: an agent infers this is the tool for occupational noise dose rather than heat stress. There is no statement of when to use it, when not to, or which standard to prefer for a given jurisdiction.

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