Skip to main content
Glama
Sign In
ls-dyna-mcp

ls-dyna-mcp

by codersag
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

run_mechanical_script

Execute custom IronPython scripts inside Ansys Mechanical to automate ACT API tasks and extend LS-DYNA analysis workflows.

Instructions

DISABLED unless the server is started with LSDYNA_MCP_ENABLE_SCRIPT=1. Run a custom IronPython script inside Mechanical (full ACT API) with stock IronPython semantics. Args: script

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": {
      "script": "<script>"
    },
    "name": "run_mechanical_script"
  }
}

Input Schema

NameRequiredDescriptionDefault
scriptYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.9.2

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the server-flag gate and the execution environment, but for an arbitrary-script execution tool it does not describe side effects, safety implications, or whether a Mechanical connection is required.

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

Conciseness5/5

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

The description is short and front-loads the critical DISABLED condition. Every sentence adds useful information with no wasted wording.

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

Completeness3/5

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

The output schema can cover return values, and the description covers the critical enablement gate. Still, for a high-risk script execution tool with no annotations and an undocumented parameter, it lacks enough usage and safety context to be fully complete.

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?

The single script parameter has 0% schema description coverage, so the description must compensate. It identifies the parameter as a custom IronPython script and clarifies the runtime semantics, but it does not give format expectations or constraints beyond that.

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

Purpose5/5

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

The description gives a specific verb and resource: run a custom IronPython script inside Mechanical. It also states the execution context, full ACT API with stock IronPython semantics, which clearly distinguishes it from the many domain-specific sibling tools.

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?

The description provides an important gating condition, that the tool is disabled unless LSDYNA_MCP_ENABLE_SCRIPT=1. However, it does not explain when to prefer this generic script runner over the many specialized sibling tools, nor does it warn about when not to use arbitrary scripting.

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

Deploy Server

Other Tools