drop_impact

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

With no annotations, the description carries the full burden and mostly succeeds: it declares the tool is analytic-only, that no impact-dynamics solve is shipped, and that escalate_to=None marks a horizon-scope limit. Physics assumptions are stated (mass cancels, mass_g only affects peak_force_n and energy_j), though the meaning of the returned warnings/band_pct flags is left unexplained.

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?

Dense but front-loaded: purpose first, then the input disjunction, then the physics, then the return keys. The symbolic notation and enumerated return list are information-dense rather than padded, though the combined physics+return block makes it heavier to parse than a two-sentence definition.

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 and no annotations, the description compensates fully: it enumerates every returned field, explains the underlying model and its fidelity, and flags the absence of an escalation path. Nothing needed to invoke it or interpret its result 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?

Schema description coverage is 0%, so the description must do all the work and does: it defines pulse's three shapes with their exact multipliers (1×, 2×, π/2×), explains that mass_g feeds only peak_force_n and energy_j, and enforces the mutual exclusivity of crush_distance_mm and deceleration_limit_g. An agent can call this correctly without opening the 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?

States a specific verb+resource (drop/impact screen) and pins down the method precisely: 'exact energy balance (NO solver)', which separates it from solver-based siblings like fem_run or contact_setup. It does not name those siblings explicitly, so differentiation is by implication rather than routing, keeping it just short of a 5.

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 'exactly one' rule for crush_distance_mm vs deceleration_limit_g is an explicit, actionable usage constraint that prevents a common invocation error. It stops short of a 5 because it never says when to prefer this analytic screen over a full impact/FEM study, even though solver-oriented siblings exist.

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