ls-dyna-mcp

Overview Schema Source Related Servers Discussions Admin

tail_solver_file

Reads the last lines of an LS-DYNA solver text file and returns its termination status, selecting the newest d3hsp or messag file by default and reporting which file was read.

Instructions

Last lines of a solver text file plus termination status. The default name (empty, or the bare d3hsp / messag) picks the NEWEST d3hsp[nn] / messag[nn], i.e. the file the latest run or restart is writing; the reply's file says which one was read. Any other name (d3hsp01, mes0000, lsrun.stdout.txt...) is read as given. Text is redacted (see README, Privacy). Args: directory, name, lines

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "directory": "<directory>"
    },
    "name": "tail_solver_file"
  }
}

Input Schema

Name	Required	Description	Default
`name`	No
`lines`	No
`directory`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.9.2Oct 24, 2026

TDQS

A3.7/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses default newest-file search behavior, the reply's `file` indicator, and text redaction, which are useful operational traits beyond the schema. It does not discuss missing-file/error behavior or permissions, so it is not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded, followed by important filename semantics and examples. The description is dense but mostly earns its space; the final args list slightly repeats the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be fully explained, and the description still usefully mentions the `file` field. For a three-parameter read tool with no annotations, it covers the critical default-name ambiguity and redaction, though error cases are omitted.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It lists the args and gives detailed semantics for `name`, and `lines` is inferable from 'Last lines', but `directory` and the `lines` default/behavior are left mostly to schema defaults without explanation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: last lines of a solver text file plus termination status. It explains the default filename selection clearly, but does not explicitly differentiate itself from siblings such as scan_solver_messages or list_solver_files.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains default name semantics and that other names are read as given, which gives useful filename-selection context. However, it never says when to use this tail tool instead of scan_solver_messages/list_solver_files, nor when not to use it.

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

Deploy Server