plasticity_calculate_enf_mode_ii_energy

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

Annotations supply readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is already declared. The description adds substantial non-obvious context: the exact fit form C = A + m*a^3, the G_IIc formula, that fit R-squared and sources are retained, that only layer-interface failures are eligible, and the explicit scope carve-out for ASTM D7905 and R-curves. This goes well beyond the 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 one long sentence followed by another dense sentence of disqualifiers and a third sentence of scope caveats. It is front-loaded with the core action, which is good, but the run-on sentence style and repeated hedging ('exploratory', 'not a design allowable or Creality material property') reduce readability without adding new operational detail.

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 a 9-parameter nested schema, no output schema, and no annotation detail beyond read-only, the description is largely complete: it explains inputs, the computation, what is retained, what is out of scope, and what the result is not. No output schema exists, so it does not need to describe returns, but it could more explicitly state the output is a scalar energy estimate. The current text implies it but doesn't state it plainly.

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 carry all parameter meaning. It does: it explains which specimen fields are required, what the compliance values represent (inverse initial-linear slope), the required numeric vectors (interface normal and perpendicular global shear), the protocol hash/date, and per-input source hash/locator. It stops short of mapping every schema field (e.g., orientationDeg, wallLoops), but the critical inputs are covered.

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 opens with a precise verb+resource+scope: 'Calculate an exploratory ENF Mode-II initiation energy from caller-supplied compliance-calibration results.' This clearly distinguishes it from siblings such as calculate_mmb_mode_i_ii_energy, calculate_dcb_mode_i_energy, and record/read/import ENF variants, which handle different test modes or different stages in the workflow.

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 lays out the prerequisites for calling the tool (at least three crack lengths/compliances, same fixture, measured crack and peak force, global normal/shear vectors, protocol hash/date, source hashes and locators, attestations). It also gives exclusions ('does not interpret raw machine traces, correct compliance, determine ASTM validity'). It doesn't point to a sibling for the preceding steps (e.g., import_enf_mode_ii_energy_csv), but the when/when-not is otherwise clear.

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