Reads nodal vector time histories from LS-DYNA d3plot files for specified node IDs and state frames in desired units, enabling scripted CAE result checks.
Extract vectors through LASSO. Public states are 1-based, IDs are user IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| units | Yes | ||
| states | Yes | ||
| node_ids | Yes | ||
| quantity | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses nothing: not whether the operation is read-only, what file/path assumptions apply, whether extraction is expensive, or what errors to expect. "Through LASSO" is opaque jargon rather than behavioral context.
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 text is short and front-loaded, but this is under-specification rather than conciseness: two sentences cannot cover a 5-parameter required-input tool with zero schema documentation, and the first sentence spends its words on an unexplained acronym.
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 5-required-parameter extraction tool with no annotations, no output schema, and no parameter descriptions anywhere in the schema, the description is grossly insufficient. An agent cannot determine valid units, quantity names, or state-index bounds from any source.
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% across 5 required parameters. The description partially compensates on two of them (states are 1-based; IDs are user IDs, not internal indices), which is genuinely useful, but path, units, and quantity — including accepted unit or quantity vocabulary — remain entirely undocumented.
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?
"Extract vectors through LASSO" names a vague verb-object pair and never states the resource (d3plot nodal data) that the tool name implies. It gives no basis for choosing it over closely related siblings such as extract_nodal_results or extract_lsreader_nodal. The second sentence is purely parameter guidance, not purpose.
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?
There is no statement of when to use this tool, when not to, or which sibling extraction tool is the alternative. An agent must guess between this, extract_nodal_results, extract_lsreader_nodal, and extract_node_history entirely from their names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.