plasticity_import_dcb_mode_i_energy_csv

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

Annotations already declare readOnly=true/destructive=false/openWorld=false, and the description adds substantial context beyond them: it converts only force/displacement units, retains the source SHA-256 and record locators, and computes an exploratory MBT G_I preview. It also enumerates nine specific limitations (no sample filtering, no crack-growth inference, no peak selection, no compliance correction, no test registration, no ASTM/cohesive-law/allowable claims).

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?

It is a dense single paragraph but front-loaded with the read-only preview purpose and every clause carries substantive information. Slightly long, though nothing reads as filler.

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 complex 18-parameter, nested, no-output-schema tool, the description is strong on behavior, scope and workflow. Its main gap is parameter-level meaning for the material/print metadata and evidence fields, which the empty schema coverage does not compensate for.

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% across 18 mostly-required nested parameters, so the description must carry the load. It does meaningfully explain the crack-growth mapping (record number, crack length), column/unit/sign/delimiter/decimal mappings, but leaves the materialProcess object, protocol hash, testedAt, evidence constants, and specimen geometry fields unexplained.

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 and resource: 'Read-only preview of an explicitly mapped local DCB Mode-I raw force/displacement CSV.' It clearly distinguishes itself from the sibling import tools (ENF Mode-II, MMB Mode-I/II) and names the downstream recording tool it feeds into.

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?

Explicitly prescribes the workflow: preview first, 'review the preview against the physical log, then call plasticity_record_dcb_mode_i_energy_test only after the physical test is confirmed.' It also enumerates what the caller must supply and what this tool does not do.

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