Skip to main content
Glama
codersag

ls-dyna-mcp

by codersag

build_keyword

Writes a single LS-DYNA keyword card as validated text using PyDYNA definitions, rejecting unknown fields and wrong value types, with optional insertion into an analysis.

Instructions

Write one keyword card as LS-DYNA text, laid out by PyDYNA's own definition of the keyword (nothing here is typed from memory). Unknown field names and wrong value types are refused. Fields you leave out are written with the manual default (PyDYNA writes it explicitly, for example SPALL 2.0): the reply's defaults_written lists them. After writing, the text is read back and every value you gave must come out unchanged, else ok is false and the field is named (value too wide for its column, a float that would lose digits, a field of an inactive conditional card). A field name that occurs in several cards must be addressed as "card3.name" (card numbers as in describe_keyword). title adds the _TITLE option (printable ASCII only, no control characters). Cannot do: keywords with repeating-row (table or point) cards such as DEFINE_CURVE or *PART with a table, and keywords with file or path fields; use add_keyword_commands with explicit text for those. The same safety checks as add_keyword_commands apply. With add_to_analysis=true the card is added as a Keyword Snippet (scope_path as in add_keyword_commands); otherwise the text is only returned. Args: name (e.g. MAT_JOHNSON_COOK), values (field name -> value, see describe_keyword), add_to_analysis, analysis_index, scope_path, title

Input Schema

NameRequiredDescriptionDefault
nameYes
titleNo
valuesYes
scope_pathNo
analysis_indexNo
add_to_analysisNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.9.2

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: it explains that values are written from PyDYNA's definitions, unknown fields and wrong types are refused, omitted fields are written with manual defaults and listed in defaults_written, and every supplied value is read back and validated. It also discloses failure causes, title ASCII restrictions, unsupported keyword classes, and the snippet-vs-return-only behavior.

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 description is front-loaded with purpose and behavior before limitations and parameter notes, and most sentences add real information. It is somewhat dense and the closing Args list partly repeats parameter names already covered in prose, but it remains appropriately sized for a complex six-parameter tool.

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?

For a complex tool with no annotations, 0% schema coverage, and an output schema, it covers purpose, validation behavior, failure modes, unsupported cases, and the key add_to_analysis branch. The main gaps are that analysis_index is not described and scope_path depends on sibling documentation rather than being self-contained.

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

Parameters4/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 explains name, values (field name to value, see describe_keyword), title, add_to_analysis, and scope_path, but analysis_index is left unexplained and scope_path is defined only by reference to add_keyword_commands.

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?

States a specific verb and resource: 'Write one keyword card as LS-DYNA text, laid out by PyDYNA's own definition of the keyword.' It distinguishes itself from add_keyword_commands by naming the cases it cannot handle and routing them to that sibling, and it points to describe_keyword for field-name discovery.

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

Usage Guidelines5/5

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

It explicitly states when not to use it: keywords with repeating-row cards or file/path fields must use add_keyword_commands with explicit text. It also directs the agent to describe_keyword for field names and explains that add_to_analysis controls whether the card is added as a Keyword Snippet or only returned.

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