plasticity_match_material_coupon_data

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

Annotations already mark this read-only and non-destructive, but the description adds far more: conflicting isotropic/orthotropic/Tsai-Wu/print-axis data are never silently selected, a single record may be preferred over subset-only records, complementary records stay ambiguous, and the combine path never averages or infers. It also warns coupon strengths are not design allowables.

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?

Front-loads the match criteria, then moves through outcome semantics, disambiguation, and the safety caveat with no filler sentences. It is somewhat dense but each sentence carries distinct behavioral or routing information.

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 a nested, 0%-documented input object, the description still explains what a match returns (measured/derived evidence and dependencies for review) and how ambiguity is resolved. It stops short of describing the identifier format needed for the follow-up combine call, a minor gap.

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%, so the description must carry the load, and it names every field of the nested process object (printer, material, profile SHA-256, orientation, infill percent/pattern, wall loops, top/bottom shells, nozzle temp, layer height). It does not explain formats or units, which the schema partially constrains via min/max and the hash pattern, hence a 4 rather than 5.

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 precise verb ('Match') and resource ('coupon data') and enumerates the exact process fingerprint the match keys on (printer, material, profile SHA-256, orientation, infill, walls, shells, nozzle temp, layer height). It is clearly distinguishable from the sibling plasticity_combine_material_coupon_data, which it names 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?

Gives explicit routing: when complementary partial records stay ambiguous, call plasticity_combine_material_coupon_data with their IDs only after the user confirms the unique physical specimen count. It also frames outcomes (no-match/matched/ambiguous) so the agent knows when the tool has succeeded versus when to escalate.

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