List all LS-DYNA jobs submitted in the current server session with their status (pending, running, done, failed, stopped, cancelled) and termination state from d3hsp.
All jobs submitted in this server session with status (pending, running, done, failed, stopped, cancelled) and termination (normal/error/unknown from d3hsp).
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.9.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses useful behavioral context: the scope is the server session, the possible statuses are enumerated, and termination is derived from d3hsp. It does not mention ordering, pagination, or authorization, but for a zero-parameter listing tool the key disclosure is present.
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 a single sentence, front-loaded with the scope and followed by the status and termination details. Every clause adds useful information without waste.
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 zero-parameter list tool with an output schema, the description provides the essential context: session scope, statuses, and termination source. It is nearly complete, though it could say whether jobs are ordered or limited.
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?
The tool has zero parameters, and the description introduces no parameters, so the baseline of 4 applies. There are no parameter semantics to clarify.
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 clearly states the resource (jobs submitted in this server session) and the information returned (status and termination). It is distinguishable from get_lsdyna_job by emphasizing 'All jobs', but it does not explicitly name the sibling.
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?
It implies use for seeing all jobs in the current session, but gives no explicit when-to-use guidance, exclusions, or alternatives. An agent must infer that get_lsdyna_job is for a single job and list_lsdyna_analyses is for analyses, which is not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.