No user-submitted related servers found.
Scored across 53 tools
Tool descriptions are unusually detailed and draw real boundaries, but several clusters overlap heavily: get_solve_status / get_run_progress / check_run_health / read_implicit_progress all answer 'how is my run doing', and read_glstat / read_binout / read_history_file / read_d3plot all read results. Likewise deck tools (scan_keyword_file, audit_deck, compare_decks, write_solver_input, write_and_audit_deck) require careful reading to pick correctly. An agent can usually choose well, but only by parsing long descriptions rather than from names alone.
The dominant pattern is verb_noun in snake_case (list_lsdyna_analyses, get_analysis_settings, add_result, delete_object, submit_lsdyna_job), applied consistently to prefixes like list_/get_/set_/add_/read_. A handful deviate into noun-ish or adjective forms (audit_deck, presolve_check, build_keyword, describe_keyword, tail_solver_file), but these remain readable and unambiguous in style.
53 tools is well above the 'heavy' threshold, even for a broad domain spanning mechanical connection, settings, loads, results, keyword authoring, deck auditing, solving, job control and post-processing. Several tools could be merged (multiple run-status/progress readers, two deck-writing entry points, four separate result-file readers), so the surface feels accumulated rather than scoped.
The lifecycle is covered end to end: connect/disconnect, create analyses and systems, inspect and set analysis settings, add loads/results/trackers, author and audit keyword decks, write and submit decks, watch and steer running jobs, restart, and read back every major result format. Even edge paths (restart validation, dynain conversion, sense switches, version discovery) have dedicated tools, with disabled features documented rather than silently absent.