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

With no annotations, the description carries the burden and discloses meaningful behavior: trackers are applied in branch/sub-branch/component order, and a failure removes the tracker unless keep_partial=true. It does not cover permissions, duplicates, or full side effects, but the mutation and rollback behavior are well surfaced.

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 front-loaded with the action and branch values, then behavior, then arguments. It is dense but appropriately sized; the final Args list is somewhat redundant with the schema but adds examples and helps scanability.

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?

An output schema exists, so return values need not be explained. However, for a 6-parameter mutation tool with no annotations and 0% schema coverage, the description still leaves key parameters unexplained, which could lead to incorrect invocation despite covering the critical pre-solve and partial-failure behavior.

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?

Schema description coverage is 0%, so the description must compensate. It explains branch values, gives a component example, notes ordering, and explains keep_partial, but leaves subbranch, named_selection, and analysis_index largely undefined.

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?

States a specific verb and resource: adding a Binout Tracker via SolutionInformation.AddLSDYNAGeneralTracker. It also enumerates valid binout branches, making the operation concrete and distinguishable from sibling tools like list_binout_tracker_options.

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?

Explicitly says trackers must be added BEFORE solving and points to list_binout_tracker_options for valid names. It lacks explicit when-not guidance or direct comparison to read_binout/get_solution_information, but the timing prerequisite is clear.

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

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

With no annotations provided, the description carries the full behavioral burden and adds substantial context: blank-line stripping, why trailing blanks break the solve, *INCLUDE folder restrictions, and the prohibition on adding *KEYWORD. It still does not describe permissions, idempotency, or what the returned Commands object looks like, though an output schema exists.

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 front-loaded with the main action and purpose, then supplies caveats and parameter guidance. It is somewhat long, but each caveat is actionable and tied to real failure modes. Minor structural awkwardness comes from the inline 'Args:' block, but overall it is efficient.

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 complex deck-mutation tool with no annotations, the description covers the key operational risks and the insertion scope well. An output schema exists, so return-value detail is less necessary. The main gap is the unexplained analysis_index parameter, which leaves one part of invocation ambiguous.

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?

Schema description coverage is 0%, so the description must explain all three parameters. It gives strong semantics for keywords (must start with a '*' card, do not add *KEYWORD) and scope_path (dotted path examples and empty behavior), but analysis_index is only named and not explained. That is useful compensation but not complete.

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 states a specific verb and resource: adding a Keyword Snippet (Commands object) containing raw LS-DYNA keyword text. It clearly scopes the tool to cards Mechanical has no native object for, such as *CONTROL_ENERGY and *DEFINE_CURVE. It does not explicitly distinguish this from sibling tools like build_keyword or create_lsdyna_system_snippet, so it stops short of a 5.

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 gives clear usage context: use this for cards that Mechanical has no native object for, and it explains where the snippet can be inserted via scope_path. It also provides important constraints around *INCLUDE file paths and not adding *KEYWORD. However, it does not explicitly say when to prefer this over alternatives such as build_keyword or describe_keyword.

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

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

With no annotations, the description carries the full load and does well: it discloses atomic rollback on property/scope failure, the keep_partial escape hatch, the unscoped default when named_selection is absent, override semantics, and per-property reporting of unknown names. It omits permission/auth requirements and any duplicate-detection nuance beyond retry safety, keeping it from a 5.

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?

Dense but front-loaded: purpose leads, then the kind list (necessary given no enum in schema), then properties_json mechanics, then failure/override rules. The long inline kind enumeration is verbose but earns its place since the schema lacks an enum; no filler sentences.

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?

Rich failure/scope semantics plus an output schema mean return values need no explanation, and mutation safety is covered despite absent annotations. The undocumented analysis_index and lack of guidance on choosing kind vs. raw keyword commands are the remaining gaps for a fairly complex 5-param mutation tool.

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?

Schema coverage is 0%, so the description must compensate and largely does: it documents the full kind vocabulary (case/spaces ignored), the properties_json format with an example and ordering rule, named_selection's unscoped default, and keep_partial behavior. analysis_index is never explained, leaving one of five params undocumented.

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?

States a specific verb ('Add'), resource ('load / boundary / initial condition'), and target ('LS-DYNA analysis') and enumerates the exact condition kinds. An agent can distinguish this from add_keyword_commands or add_result without opening a schema.

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?

Provides clear operational guidance: it points to inspect_object for discovering available property names, tells the agent to put DefineBy first, and notes the Velocity/Displacement-overrides-Fixed-Support rule. It does not explicitly contrast this with sibling tools like add_keyword_commands, so it stops short of full when/when-not routing.

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

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

With no annotations, the description still discloses important behavior: properties are applied in order, and failure of a property or scope removes the new object unless keep_partial=true. It does not mention connection prerequisites or broader model side effects, but the rollback semantics are valuable and non-obvious.

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 front-loaded with the core action and keeps the kind enumeration where it adds necessary value. The trailing 'Args:' list is somewhat redundant with the schema and could be trimmed, but overall it is dense rather than bloated.

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?

The output schema exists, so return values need not be explained. However, for a five-parameter mutation tool with no annotations and 0% schema description coverage, the description omits prerequisites and the meaning/format of properties_json and analysis_index, leaving gaps an agent may need to resolve.

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?

Schema description coverage is 0%, so the description must carry parameter meaning. It usefully enumerates kind values and explains keep_partial behavior, but leaves named_selection, properties_json, and analysis_index largely undefined beyond listing their names.

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 states a specific verb and resource: 'Add a result object under Solution.' It enumerates the supported result kinds and explicitly differentiates the d3max/d3part case by pointing to set_analysis_settings.

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 gives clear context for adding a result object and explicitly routes d3max/d3part usage to set_analysis_settings. It does not broadly compare against siblings such as list_addable_objects or explain when adding a result is inappropriate beyond that special case.

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

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: it declares read-only/non-executing behavior, explains that parsing is plain text, discloses the *INCLUDE traversal restriction ('only inside the allowed folders'), and states the return shape (findings with severity/card/field/message plus a compact summary). These are exactly the behavioral traits an agent cannot get from the schema.

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?

Front-loaded with the one-line identity and read-only guarantee, then a dense but information-bearing checklist of checks. It is a long run-on paragraph where bullets or a sentence break before 'Args:' and 'Returns' would aid scanning, but no sentence is filler.

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?

An output schema exists, so the brief description of findings/summary is a bonus rather than a requirement. The pre-solve audit scope, the include-folder restriction, and the unverified-citation caveat together make it complete enough to call correctly; only the 'allowed folders' configuration source and deck_path expectations remain unspecified.

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?

Schema coverage is 0%, so the description must compensate; it partly does by glossing include_children as 'follow *INCLUDE files', which matches the schema default of true and adds real meaning. deck_path is left entirely unexplained (accepted formats, relative vs. absolute, whether it must be a directory or .k file), so the semantic gap is only half closed.

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?

Names a specific verb and resource ('read-only audit of an LS-DYNA keyword deck') and enumerates exactly what it checks (card families, duplicate ids, dangling references, format problems, unit guess, end time vs. output intervals, Workbench defaults). An agent knows precisely what the tool produces; however it never names the closest sibling (presolve_check, scan_keyword_file, compare_decks), so differentiation is by inference only.

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?

The phrase 'before it is solved' plus '(plain text parsing, nothing is executed)' gives clear timing/context for when to reach for it. There is no explicit when-not guidance or pointer to the alternative tools for post-solve or comparative checks, so a routing decision against presolve_check is left to the agent.

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

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries the full behavioral burden and does well: it discloses the validation rules, required restart files by type (d3dump vs d3full), and that time values of 0 are treated as unknown. It never explicitly says the tool is read-only or has no side effects, but the 'validate/check' framing strongly implies that.

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 definition is front-loaded and dense, with most sentences contributing concrete rules or parameter meaning. The trailing 'Args:' list partly repeats content already implied earlier, but it usefully enumerates all parameters given the bare schema titles.

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 7-parameter validation tool with no annotations but an output schema, the description covers the essential validation logic, file checks, and parameter meanings. It could add an explicit side-effect profile, but nothing critical for correct invocation is missing.

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?

Despite 0% schema description coverage, the description names all seven parameters and adds meaningful semantics: 'directory' is the earlier run's folder, solver_precision is single|double, processing_type is SMP|MPP, restart_type values are Simple/Small/Full, and 0 times are unknown. It leaves number_of_cores and the exact previous/new end-time distinction relatively bare, so not a 5.

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 states a specific verb (validate) and resource (restart setup), and details the concrete rules and file checks involved for Simple/Small/Full restarts. It does not explicitly distinguish itself from related siblings such as presolve_check or list_restart_files, which keeps it from a 5.

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?

The phrase 'before solving' gives clear timing context, and it explains the conditional behavior when 'directory' is supplied. It does not name alternatives or state when not to use it, but the usage context is clear enough for an agent.

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

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

With no annotations, the description carries the full behavioral burden and does so: it defines every possible verdict value, warns that `ok: true` only means the files were read, and discloses the staleness heuristic ('staleness is judged by file times: run each job in a clean folder'). These are precisely the non-obvious traits an agent needs before trusting the result.

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 core action is front-loaded in the first sentence and the verdict list is dense but each item earns its place by enabling correct interpretation. The long enumerated verdict parenthetical is the only mildly heavy section, though it is arguably necessary for a multi-outcome tool.

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?

An output schema exists, so return values need not be spelled out, yet the description still supplies verdict semantics and caveats that make the output actionable. Remaining gaps are minor — e.g., which files are mandatory vs optional, or what happens when energy files are missing alongside the d3hsp.

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?

Schema description coverage is 0%, so the description must compensate, and it does: hourglass_limit is defined as 'max hourglass/internal, default 0.10', balance_tol as 'allowed deviation of the energy ratio from 1', and quasi_static gets its rule of thumb (kinetic energy above 5% of total). Only `directory` is left unexplained, though it is self-evident.

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 states a specific verb and resource ('Judge a run from glstat (or binout) and d3hsp') and enumerates the exact checks performed (termination, energy balance, hourglass, negative sliding energy, kinetic energy). Its verdict-aggregation role clearly distinguishes it from siblings like read_glstat, read_binout, or get_run_progress, which only surface raw data.

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 gives clear context for when the tool is intended (judging a run's health, with `quasi_static` and staleness caveats) and explains what each verdict means. It stops short of explicitly naming alternatives (e.g., 'use read_glstat for raw series data') or stating 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.

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

With no annotations at all, the description carries the full burden and does so: it declares read-only semantics, the matching key (keyword + id, not order), the normalisation rules (case, comma vs fixed format, 1.0e3 == 1000, *PARAMETER values), the complete status vocabulary including default-vs-explicit and known_workbench_default, and the 300-row cap with differences-first ordering and a `truncated` flag. These are exactly the non-obvious behaviors that would otherwise cause misinterpretation of results.

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 purpose and matching rules are front-loaded, but the middle is a dense parenthetical wall of card names (MAT_JOHNSON_COOK, CONTROL_TERMINATION/SPH/HOURGLASS/TIMESTEP/CONTACT/ENERGY, SECTION_SOLID/SPH/SHELL...) that conveys coverage but is expensive to read. The argument notes are jammed into a trailing run-on rather than broken out per parameter.

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 complex 4-parameter, no-annotation tool this is close to complete: it covers what is compared, how rows are matched and normalised, what the statuses mean, and how truncation is signalled (return values themselves are covered by the output schema). Minor gaps remain around file-precondition failures and whether units/format differences on the reference side are tolerated.

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?

Schema description coverage is 0%, so the description must compensate and largely does: `cards` is explained as keyword prefixes with "default all", and `candidate_unit_scale` gets a precise, non-obvious definition ("how many candidate units one reference unit is, per base quantity") plus which quantities it converts and that absent means raw comparison. Only `reference_path`/`candidate_path` are left self-explanatory, which is acceptable.

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?

Opens with a specific verb and resource ("Read-only field-by-field comparison of two keyword decks") and immediately contrasts the two sides being compared (standalone reference vs. a Workbench-authored deck). This is clearly distinguishable from siblings like audit_deck or scan_keyword_file, which inspect a single deck.

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?

The "for example a standalone reference against the deck Workbench wrote" clause gives a concrete usage context, and the reference to audit_deck for known_workbench_default gives a hint of the companion tool. However, there is no explicit "use this instead of X when Y" or any exclusion, so an agent must infer that single-deck checks belong to audit_deck.

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

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

No annotations exist, so the description carries the full burden and does: reference values are interpolated at the simulation's output times within [t_min, t_max], scaled by reference_scale for unit conversion with the warning that times must already be in the model's unit, and 'No solver is run' sets cost expectations. It also names the verdict vocabulary (within_tolerance / exceeds) and the first-exceedance time.

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 gate purpose is front-loaded in the first clause and the body is information-dense with little filler. The trailing 'Args: working_dir, reference_csv, ...' line merely restates parameter names already in the schema and earns no place.

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?

With no annotations and an output schema present, the description covers workflow, units, failure handling and cost, which is nearly everything an agent needs. It omits where the simulation-side history is read from inside working_dir, a non-trivial prerequisite for correct invocation.

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?

Schema description coverage is 0% across 7 parameters, and the description compensates strongly: it documents quantity syntax with three concrete examples ('glstat:kinetic_energy', 'matsum:1:kinen', 'nodout:5:x_vel'), the reference_csv column layout (time,value), what t_min/t_max bound, and the purpose of reference_scale and tolerance_pct. Only working_dir is left to inference.

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?

Uses a specific verb ('compare') on a specific pair of resources (a scalar history from a short run vs. a reference CSV), framed as an 'Early-time gate'. The scope ('before committing to the long run') distinguishes it from sibling analysis tools such as compare_decks or read_glstat.

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?

Gives a clear trigger ('before committing to the long run') and explicit routing on failure ('diagnose the model (audit_deck, compare_decks): never tune parameters to match an experiment'). It never states the precondition that a completed short run's results must already exist in working_dir, nor a when-not-to-use case, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the port changes every session, a genuine caveat, but says nothing about connection lifecycle (e.g., what happens if already connected), failure behavior, or required preconditions.

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 two short sentences with the main purpose front-loaded and the parameter note compactly appended. It wastes little space, though the 'Args:' fragment is slightly schema-like.

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?

An output schema exists, so return values need not be explained. However, for a connection-establishing tool with no annotations, key context such as prerequisites, connection persistence, and what constitutes success or failure is missing.

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?

Schema description coverage is 0%, so the description must compensate. It identifies the single parameter as 'the gRPC port of the Mechanical session' and warns it changes every session, which is meaningful, but it never says where the agent should obtain the current port value.

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 states a specific verb ('Connect to') and a specific resource ('the Mechanical session that holds your LS-DYNA system'), which is enough for an agent to understand what the tool does. It does not explicitly differentiate itself from siblings, though the opposite 'disconnect_from_mechanical' is self-evident.

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?

There is no when-to-use guidance, no mention of prerequisites (e.g., that a Mechanical session must already be running), and no routing to alternatives. The only implied usage is that connecting is a prerequisite for other Mechanical tools, which the description never states.

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

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

With no annotations, the description carries the full burden and discloses a genuinely important side effect: the created analysis cannot be deleted through the scripting API due to a null-reference error and must be removed in the GUI. That is non-obvious lifecycle information an agent cannot get elsewhere, though prerequisites (e.g., an active Mechanical connection) and error behavior are not covered.

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 core action and API call are front-loaded, and the cross-reference and deletion caveat both earn their space. The redundant 'Args: restart' tail is the only wasted line.

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 one-parameter mutation tool with an output schema and no annotations, the description covers what is created, which API is invoked, how the restart flag changes the result, and the deletion limitation. Only connection/prerequisite state is missing.

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?

Schema coverage is 0%, so the description must compensate, and it does: restart=True is explicitly mapped to an LS-DYNA Restart analysis with a different underlying API method, which the boolean schema alone would not convey. The trailing 'Args: restart' adds nothing, but the substantive mapping is present.

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 states a specific verb and resource ('Add an LS-DYNA analysis to the Mechanical model') and names the exact API methods used (Model.AddLSDynaAnalysis / AddLSDynaRestartAnalysis). It also explicitly separates itself from create_lsdyna_system_snippet by clarifying that the system templates (LSDYNA / RestartLSDYNA) are a different concept from the analysis.

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 tells the agent how the restart flag selects behavior (restart=True produces a Restart analysis) and cross-references create_lsdyna_system_snippet for the related but distinct system-creation step. There is no explicit 'do not use this when...' framing, but the context for selecting the tool is clear.

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

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

With no annotations, the description carries the full burden. It usefully clarifies that the tool produces journal-line text rather than performing the system creation itself, and notes the ACT extension dependency. It does not describe side effects, error conditions, or how restart mode changes behavior.

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 key information is front-loaded: it states that the tool emits Workbench journal lines for creating LSDYNA systems. The description is short and avoids filler. The trailing 'Args: restart' is abrupt and under-explained, but the overall shape is efficient.

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 one-parameter snippet generator with an output schema, the description provides the essential execution context and dependency. It remains incomplete on parameter meaning and on how the generated snippet should be used with execute_workbench_script beyond the bare mention.

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?

Schema description coverage is 0% for the single `restart` parameter. The description only says 'Args: restart' and does not explain what true/false selects, even though the earlier reference to 'LS-DYNA Restart' hints at it. This falls short of compensating for the missing schema documentation.

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 names a specific output and resource: Workbench journal lines that create an LS-DYNA or LS-DYNA Restart system. It also ties the snippet to execute_workbench_script. It does not explicitly distinguish this snippet-generator from sibling tools such as create_lsdyna_analysis, which prevents a 5.

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?

The mention that the output is 'for execute_workbench_script' gives implied usage context, and the note about template ids coming from the installed ACT extension is a useful prerequisite. However, there is no explicit guidance on when to choose this tool versus create_lsdyna_analysis or other creation routes, and no when-not guidance.

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

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

With no annotations present, the description carries the full load and does well: it discloses the stale-index guard ('the object's current name must equal expected_name, so a stale index ... deletes nothing'), the accepted path grammar, and the refused-target list. It omits whether the deletion is undoable or what permissions are required, which for a destructive operation is a meaningful remaining gap.

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?

Front-loaded with the verb and resource, then the accepted path grammar, then the refusal list, then the discovery hint, with an Args line at the end. Every sentence adds a distinct constraint; nothing restates the tool name or the schema.

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?

An output schema exists, so return-value detail is not required, and the description supplies the path grammar, the name-mismatch safety rule, and the negative scope that the 0%-coverage schema cannot. What's missing for a destructive, unannotated tool is the analysis_index semantics and any statement about reversibility or failure behavior beyond 'deletes nothing'.

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?

Schema description coverage is 0%, so the description must compensate; it does so for two of three params, giving the exact accepted path strings ('Children[n]', 'Solution.Children[n]', 'Solution.SolutionInformation.Children[n]') and a precise contract for expected_name as a stale-index guard. The third parameter, analysis_index, appears only in the trailing Args list with no explanation of what it indexes or how it defaults.

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?

States a specific verb (Delete) and resource (one object added to the analysis) and enumerates exactly which object kinds qualify: loads, supports, results, trackers, keyword snippets. It also names the sibling tools (list_scoping_targets, inspect_object) used for discovery, so an agent can place it precisely among the ~50 siblings.

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?

Explicitly directs the agent to 'Look first with list_scoping_targets or inspect_object' and enumerates the targets that are refused (analyses, analysis settings, Solution, mesh, contacts, named selections), which effectively tells the agent when not to use it. It does not spell out the condition that selects one sibling over the other beyond that one line, so it stops short of a full when/when-not/alternative rubric.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it states the data source, exact-name matching including hyphen sensitivity, the meaning of default, and the builder_supported limitation. It also names the correct fallback tool for unsupported keyword shapes.

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 dense but front-loaded: it first states what is listed, then explains matching semantics, defaults, limitations, and the argument format. Every sentence adds operational value without repetition.

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?

Given one required parameter, an output schema, and no annotations, the description supplies all key context an agent needs: data source, exact matching rules, default semantics, supported/unsupported keyword shapes, and the fallback tool. Return-value details are already covered by the output schema.

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?

Schema description coverage is 0%, but the description fully compensates by explaining that name is matched exactly, hyphens matter, and the leading * is optional. It also gives a concrete example such as MAT_JOHNSON_COOK.

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 gives a specific verb and resource: list the cards and fields of an LS-DYNA keyword, including field name, type, column, width, and default. It clearly distinguishes the tool from build_keyword and add_keyword_commands by explaining that it inspects keyword definitions rather than building or adding commands.

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 explicitly tells the agent to use add_keyword_commands for keywords with repeating-row cards or file/path fields, which is a clear when-not condition and alternative. It also ties the returned default value to build_keyword behavior, giving useful context for when this lookup is relevant.

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

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

No annotations exist, so the description carries the full burden; it does disclose the data source (an installed XML file) and a real constraint (xml_path must live in an allowed folder), which implies a read-only lookup. It omits failure behavior for unmatched queries and does not state permissions or whether a caller could point at an arbitrary path.

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 core purpose is front-loaded and compact, but the trailing "Args: query, xml_path (optional)" line restates the schema's own property names and default without adding meaning, so it does not fully earn its place. The parenthetical source reference is similarly crammed mid-sentence.

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?

An output schema exists, so return values need not be explained, and the description covers what the lookup returns conceptually plus both inputs and the path constraint. For a two-parameter read-only lookup this is close to sufficient, with only unmatched-query and permissions behavior left open.

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?

Schema description coverage is 0%, so the description must carry all parameter meaning, and it mostly does: query is matched against the card name with two concrete example formats, and xml_path is marked optional with a folder-restriction rule. It stops short of stating whether xml_path is an override for the default installed XML.

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?

States a specific verb and resource: it describes which *MAT/*EOS cards Workbench can write and how fields map to Engineering Data, sourced from the installed LSDYNASolverRepresentation.xml. That is far more concrete than its siblings describe_keyword/build_keyword (LS-DYNA deck side) but the description never explicitly contrasts itself with them, leaving the Workbench-vs-deck split implicit.

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 gives a concrete usage hint via query examples ("JOHNSON_COOK" or "*MAT_ELASTIC") and a constraint on xml_path (must be inside an allowed folder). It does not say when to reach for this instead of describe_keyword or search_lsdyna_help, nor what to do if the query returns nothing.

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

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

With no annotations, the description carries the full burden and does well: it discloses that shutdown sends a forced exit request that loses unsaved work, that the session may restart or linger, and that the confirmation argument is a hard refusal gate requiring an exact string. Missing is any statement about what plain disconnect does to the underlying connection or whether it is reversible.

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 key fact (Mechanical keeps running) is front-loaded and every clause carries information. The 'Args:' block is somewhat dense and run-on with nested parentheticals, which slightly slows parsing but does not waste words.

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?

An output schema exists, so return values need not be explained. For a two-parameter, zero-required session teardown tool, the destructive branch is fully covered. The remaining gap is the semantics of the non-shutdown path, which is left to be inferred from the name.

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?

Schema description coverage is 0%, so the description must supply all meaning, and it does: shutdown is explained as a forced exit with data-loss consequences, and confirm is defined with the literal required value 'SHUT DOWN MECHANICAL'. The schema only supplies bare type/title/default; the description supplies the operational contract.

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 opening sentence names a specific verb and object ('Disconnect, leaving Mechanical running') and clarifies the post-state of the server, so the agent knows the session ends but the application persists. It does not explicitly differentiate itself from connect_to_mechanical or other session tools, but the action is unambiguous.

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 provides an explicit when-not for the risky path: if the session is Workbench-owned, 'normally close it from Workbench instead' because it may restart or linger. Guidance for the default behavior (disconnect without shutdown) is only implied, and there is no statement of when to disconnect at all versus staying connected.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the row structure (property name, caption, raw value, type, read-only/visible flags), that enum settings return as integers with -1 meaning Program Controlled, and that values are in solver units. It omits operational context such as connection prerequisites and error behavior for an invalid analysis_index.

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?

Information-dense and front-loaded: what is read, what a row looks like, then value conventions, then args. Nothing is padded, though the Args list is terse-list style rather than integrated prose and some row-structure detail overlaps the output schema.

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?

A read getter with an output schema needs less return-value explanation, and the description arguably over-delivers there. But with no annotations and 0% param coverage, gaps remain: what analysis_index refers to, whether a connection must be established first, and how this relates to set_analysis_settings are all unspecified.

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?

Schema description coverage is 0%, so the description must compensate, and it only partly does: group gets a genuinely useful explanation ("name prefix, e.g. 'Output Controls'"), while analysis_index and visible_only are named but never explained. One of three parameters is meaningfully documented.

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?

Specific verb and resource: "Read the Analysis Settings" immediately tells an agent this is a read-only getter, and the contrast with the sibling set_analysis_settings is inferable from the name. It stops short of explicitly naming that alternative, so it isn't a textbook 5, but the purpose is unambiguous.

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?

The description never states when to call this versus set_analysis_settings or inspect_object, nor any prerequisite (e.g. connect_to_mechanical or first fetching an analysis_index from list_lsdyna_analyses). The 'Args:' hints describe parameters, not usage conditions.

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

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

No annotations are provided, so the description carries the behavioral burden. It discloses the return composition ('one job plus the tail of its lsrun.stdout.txt') but says nothing about read-only behavior, permissions, error handling, or any cap on tail_lines.

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 very short and front-loads the returned output, but the 'Args' fragment merely duplicates schema fields. The overall phrasing is too terse to be fully self-explanatory.

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?

The output schema exists, so return values need not be fully described, but the lack of annotations and 0% schema description coverage leaves gaps in usage and parameter meaning. With many overlapping job and solver-file siblings, the definition is not complete enough to route confidently.

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?

Schema description coverage is 0%, and the description only repeats the parameter names ('job_id, tail_lines') without explaining what job_id identifies or that tail_lines controls how many stdout lines are returned. It does not compensate for the missing schema descriptions.

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 states that the tool returns one LSDyna job plus the tail of that job's lsrun.stdout.txt, which is a specific resource and output. It does not use an explicit verb or distinguish itself from overlapping siblings such as list_lsdyna_jobs or tail_solver_file.

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?

No when-to-use guidance or alternatives are provided, despite siblings like list_lsdyna_jobs, tail_solver_file, and get_solve_status that overlap with this tool. The agent must infer that this is for inspecting a single job and its stdout tail.

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

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

With no annotations, the description carries the full disclosure burden and does: read-only and 'never touches or kills a process', observability side effects (observations written to the per-user state folder, not the run folder), the enumeration of possible `state` outcomes, and an explicit caveat that 'the ETA assumes a constant rate'. That is unusually complete behavioral context for a diagnostic tool.

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 safety note is front-loaded and every clause carries information, but the body is a single sprawling sentence dense with file-name jargon and a dangling 'Args:' line appended at the end. It is appropriately sized for the complexity but poorly structured for scanning.

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?

An output schema exists, so return values need not be spelled out, and the description still covers data sources, returned `state`, ETA caveats, hang detection, and error-block extraction. The remaining gap is the unexplained required `working_dir` argument.

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?

Schema description coverage is 0%, so the description must compensate. It does explain `stale_minutes` operationally ('newest output file older than stale_minutes'), but `working_dir` is only listed in a trailing 'Args:' line with no statement of what directory it is (run folder? analysis folder?), leaving the required parameter semantically thin.

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?

States a specific resource (progress of a running or finished solve) plus which artifacts it reads (messag/mes0nnnn, d3hsp, lsrun.stdout.txt) and the `state` values it returns, so an agent knows exactly what it gets. It does not differentiate itself from near-siblings such as get_solve_status, check_run_health, or read_implicit_progress, which is the only thing keeping it from a 5.

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 gives implied usage for the ETA feature ('call it again a minute or more later') and the hang-hint conditions, which tells the agent how to use it, but there is no explicit when-to-use / when-to-prefer-an-alternative guidance against the many overlapping status tools in the sibling list.

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

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

With no annotations, the description carries the burden. By mentioning 'solver output' and 'energy histories,' it provides necessary context about the nature of the returned data. However, it provides no constraints, limitations, or resource implications beyond this basic context.

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 definition is concise, but the phrasing 'to find what this release exposes' is weak and lacks professional specificity. While not verbose, the language does not make optimal use of its single sentence.

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?

Given the complexity of retrieving 'solver output' and the lack of an output schema, the description is insufficient. An agent needs more guidance on whether the result is a single object, a list of records, or a complex nested structure to use this tool effectively.

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 schema coverage is 0%, meaning the description must carry the entire load for the 'analysis_index' parameter. The description only includes 'Args: analysis_index,' which is merely a name listing and adds zero meaningful semantic value or usage guidance beyond what the schema title implies.

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 identifies the resource—'Solution Information object'—and the data contained within it (solver output, histories). However, the action ('Members... to find') is vague, making the primary verb unclear compared to sibling tools like 'get_analysis_settings'.

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?

There are no instructions regarding when to use this tool versus others. It merely describes what the tool contains without providing any comparative guidance or use-case context for the agent.

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

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

With no annotations, the description carries the behavioral burden and usefully discloses that the tool avoids touching Mechanical while it is busy and returns the solve result only once. It still leaves out error behavior and whether the operation is strictly read-only, but it adds meaningful non-schema behavior.

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 short and front-loads the returned information before the behavioral caveat. The single 'Args:' line is terse but does not clutter the definition.

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?

An output schema exists, so return values need not be explained, and the description covers the key busy-Mechanical behavior. However, for a one-parameter tool with 0% schema coverage and no annotations, the unexplained analysis_index leaves a meaningful gap.

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 only parameter, analysis_index, has 0% schema description coverage and is mentioned only as 'Args: analysis_index'. The description does not explain what the index refers to, how it should be chosen, or what the default 0 means.

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 that the tool returns solution status, Mechanical messages, and the solver working directory. It does not explicitly distinguish itself from nearby siblings such as get_solution_information or get_run_progress, so it misses the top score.

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 gives a clear usage context: while a solve started by solve_analysis is running, the tool answers 'Solving' without touching busy Mechanical, then returns that solve's result once. It does not name when to use alternatives or explicitly say when not to use this tool.

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

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

With no annotations, the description carries the burden. 'List' and 'public properties' imply a read-only inspection, but it never explicitly states that it does not modify the model, nor does it explain truncation via max_items or any permissions/rate-limit behavior.

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 two sentences plus a compact args list, front-loads the purpose, then usage, then parameter hints. No sentence is wasted.

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?

Output schema exists, so return values need not be explained, and the path examples are helpful. However, with no annotations and low schema coverage, the missing semantics for analysis_index/max_items and the lack of an explicit read-only statement leave gaps for navigating multiple analyses or truncated results.

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?

Schema description coverage is 0%, so the description must explain parameters. It does a good job on path with examples like '' and 'Children[0]', but it merely names analysis_index and max_items without explaining indexing or result limiting.

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 opening sentence names a specific verb ('List') and resource ('public properties of an object in the LS-DYNA analysis tree'), so the agent knows exactly what will be returned. The second sentence positions it as a discovery step before set_analysis_settings, distinguishing it from mutation tools.

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 explicitly says to use this tool to discover real property names before calling set_analysis_settings, giving a clear usage context and alternative. It does not state when not to use it or contrast with get_analysis_settings, so it is not a full 5.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose non-obvious behavior: acoustic/frequency-response/PSD/electromagnetic/optimisation items are silently omitted unless all_physics=true, and host='solution' additionally populates solution_information_methods. That default-filtering disclosure is exactly the kind of gotcha an agent needs. It stops short of stating side-effect-free read semantics, connection requirements, or behavior on invalid host values.

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 core purpose and the host semantics are front-loaded, and the Args line cleanly summarizes all four parameters. The opening sentence is grammatically tangled ('The Add* methods the analysis ... offers in this release'), which slows parsing slightly, but no sentence is redundant.

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?

With an output schema present, return-value explanation is unnecessary, and the description covers defaults, host branching, and physics filtering adequately for an exploratory list tool. The remaining gaps are the unexplained analysis_index parameter and the unstated assumption that a Mechanical connection already exists, which a sibling (connect_to_mechanical) implies is required.

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?

Schema description coverage is 0%, so the description must compensate, and it largely does: host is given an explicit three-value enumeration absent from the schema, filter is qualified as case-insensitive text, and all_physics is explained in terms of what it re-includes. Only analysis_index is named without any meaning (presumably which analysis when host='analysis'), leaving one of four parameters uninterpretable.

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?

States a specific verb+resource: it enumerates the Add* methods available for an analysis, its Solution, or Solution Information, with concrete examples (loads, supports, conditions, results, probes, AddLSDYNAGeneralTracker). An agent can tell what it returns. It does not, however, distinguish itself from the closely related sibling list_binout_tracker_options, which overlaps with the solution_information path.

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?

'so a kind can be found without guessing' plus the explicit host-value semantics gives clear context for when to call it (discovering which Add* methods exist before adding one). The default-exclusion rule and the all_physics=true escape hatch are spelled out. Missing: any statement of when to prefer it over list_binout_tracker_options or inspect_object, and no prerequisite (e.g. connection) mentioned.

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

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

With no annotations, the description carries the full burden, and it does disclose a real side effect: 'A throwaway tracker is created and deleted,' plus that results are queried live from the solver extension. It doesn't say whether the throwaway tracker can collide with or affect user-created trackers, how long the query takes, or what happens if the extension is unavailable.

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 purpose and mode behavior are front-loaded and efficient, but the trailing 'Args: branch, analysis_index' recaps names already visible in the schema without adding semantics, making the last sentence waste space.

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?

An output schema exists, so return values needn't be explained, and the mode-dependent output shape is described. The main gap is the opaque analysis_index and any note on query cost or failure behavior when the solver extension is not connected, which would matter before calling this in a live session.

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?

Schema coverage is 0%, so the description must compensate and only partly does. It explains the branch parameter's two modes (empty vs. populated), which is genuinely useful, but it explicitly lists 'analysis_index' as a bare arg name with no meaning — the agent cannot tell which analysis it selects or what the default 0 implies.

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 states a specific resource and result: the binout branches and components a Binout Tracker accepts in this release. It also clarifies the source of truth ('queried from the solver extension, not hard-coded'), which separates it semantically from add_binout_tracker and read_binout. It never names a sibling to route away from, which keeps it at 4 rather than 5.

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 gives explicit calling convention: 'With no branch: the branches... With a branch: that branch's components.' That tells the agent exactly when to pass each mode. It doesn't state when not to use it or point to alternatives such as add_binout_tracker, so it falls short of a 5.

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

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

No annotations exist, so the description must carry the safety profile; 'List' implies a read-only, non-destructive scan, and the solver-target strings (LSDYNA@LSDYNA, RestartLSDYNA@LSDYNA) disclose the exact classification rule used for flagging. It does not say whether the model must be open/connected or what happens on an empty model, leaving gaps for an annotation-free tool.

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?

A single sentence with the action and scope front-loaded; the nested parenthetical adds precise, non-redundant detail about solver targets, though it makes the sentence slightly dense to parse.

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?

With an output schema present and no parameters, the description needs only to convey purpose, scope and the flag semantics — all of which it does. The only real omission is call-context guidance (connection prerequisite, ordering relative to the create/get siblings).

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 takes zero parameters, so there is nothing for the description to disambiguate beyond confirming it is unfiltered over the whole model ('every analysis'); the baseline for a no-param tool applies.

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?

Specific verb (List) plus a precisely scoped resource (every analysis in the Mechanical model), with the added clarification that LS-DYNA ones are flagged rather than filtered. An agent can tell this is an inventory call distinct from get_analysis_settings or list_lsdyna_jobs, though no sibling is named explicitly.

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?

Usage is only implied: the flagging logic suggests it is the discovery step before acting on an LS-DYNA analysis, but the description never states when to call it instead of get_analysis_settings or create_lsdyna_analysis, nor any prerequisite such as an active Mechanical connection.

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

Does 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.

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

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only listing by saying 'with sizes and times', but does not state whether the operation is safe, whether it modifies the filesystem, or what permissions are needed. A bare 'Restart files...' does not explicitly declare read-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.

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

The description is compact and front-loads the key information about what files are listed. The trailing 'Args: directory' is terse but functional; no unnecessary sentences are present.

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 simple one-parameter listing tool with an output schema that covers return values, this is minimally adequate. However, it leaves the directory parameter meaning vague and makes no explicit statement about read-only safety, which an agent would need when calling a filesystem-touching tool.

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?

Schema description coverage is 0%, so the description must compensate. It only says 'Args: directory', which essentially repeats the parameter name without adding format, expected location, or whether it should be an absolute path. The phrase 'a run left in its folder' hints that directory is the run folder, but that is too implicit to count as adequate semantic coverage.

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 gives a precise resource ('restart files a run left in its folder') and enumerates the specific file patterns (d3dump*, d3full*, dynain, dynain.lsda) that will be listed, adding useful domain specificity. It does not explicitly contrast itself with sibling tools like list_solver_files, so it stops short of the 5 criterion.

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?

Usage is implied by the phrase 'restart files a run left in its folder' and the note that dynain is 'initial state for a follow-on analysis', which suggests when the tool is relevant. However, there is no explicit 'use this when' statement or exclusion of alternatives, so guidance is only inferred.

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

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

No annotations are provided, so the description carries the full behavioral burden. It signals a read-only enumeration by describing returned record types and fields, but never states side-effect freedom, what happens when there are more targets than the cap, or pagination behavior.

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 return categories are front-loaded and packed into one dense sentence with no filler. The trailing 'Args:' fragment is the only low-value element, since it names parameters it does not explain.

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?

An output schema exists, so the return shapes need not be restated, and the description does enough to convey the three target categories. With no annotations and zero schema description coverage on both parameters, however, the definition leaves gaps an agent must fill by trial.

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?

Schema description coverage is 0%, so the description must explain the parameters, yet it only appends 'Args: analysis_index, max_items' with no meaning attached. An agent must guess that analysis_index selects which analysis and max_items caps the result list.

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 concretely enumerates what the tool lists: named selections (with name, kind, entity count), geometry parts/bodies (name + geometry id), and existing analysis objects. That is specific enough for an agent to know what comes back, even though the wording leads with 'What loads and results can be scoped to' rather than a direct 'List scoping targets' verb.

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 ties the output to a downstream action ('the geometry id, to use with the location options of add_load_or_condition'), which implies when the tool is useful. It never states when not to use it or how it differs from the nearby list_addable_objects sibling, leaving the choice between the two listing tools to inference.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'List' implies a safe read, but it does not disclose whether the scan is top-level or recursive, what happens with a nonexistent or non-solver directory, or whether hidden/large result files are included. The output schema covers return shape, which lowers the remaining burden.

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?

Two compact lines: the capability first, then the argument sourcing. No filler, no restatement of the tool name, and the file-type examples are packed inline rather than enumerated in a list.

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 single-parameter read tool with an output schema and no annotations, the description plus the cross-reference to get_solve_status covers what an agent needs to invoke it. The only meaningful gap is unspecified behavior on a bad or non-existent directory, which matters less for a listing call.

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?

Schema coverage is 0% and the schema itself only labels the field 'Directory' with no description, so the description must compensate — and it does by tying the value to working_dir from get_solve_status, which is the single most useful piece of information for filling this argument. It still doesn't specify format expectations (absolute vs relative path) or that a solver deck directory is required.

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?

Specific verb (List) plus a well-scoped resource (LS-DYNA output files in a solver directory), with concrete examples (d3plot, d3hsp, glstat, binout) that make the scope unambiguous. It implicitly separates itself from list_restart_files and tail_solver_file by naming the output-file family, but never states the distinction explicitly.

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?

The parenthetical '(the working_dir from get_solve_status)' supplies a real workflow precondition, telling the agent where the directory value comes from. It gives no guidance on when to prefer this over list_restart_files, tail_solver_file, or read_d3plot, and no exclusions or failure conditions.

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

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

No annotations are provided, so the description carries the behavioral burden. It usefully discloses the default XML location, the allowed-folder restriction, and the kind of solver metadata returned, but it does not describe error behavior, permission requirements, or what happens if the file is missing or invalid.

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 compact and front-loaded with the core action and resource. Every sentence adds useful information, and the trailing argument note is brief enough not to be wasteful.

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?

An output schema exists, so the description need not fully explain return values, though it helpfully summarizes what is listed. For a one-parameter read/list tool it is nearly complete, with only minor gaps around failure modes and permission expectations.

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?

Schema description coverage is 0%, so the description must compensate. It does so reasonably well for the single optional xml_path parameter: it identifies the default file location and states that the path must be inside an allowed folder, which adds meaningful semantics beyond the bare string schema.

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 uses a specific verb and resource: it lists LS-DYNA executables known to Workbench, and it names the backing XML file and fields returned. It does not explicitly distinguish this from similarly named sibling tools such as list_solver_files, but the purpose itself is clear.

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?

Usage is implied: use this to discover solver versions/configurations. The description adds a default location and an allowed-folder constraint for xml_path, but it does not state when to use this versus related sibling tools like list_solver_files or list_lsdyna_jobs.

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

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

With no annotations, the description carries the full burden and does well: it discloses overwrite behavior (existing dynain.k kept unless overwrite=True), a size cap via LSDYNA_MCP_MAX_DYNAIN_MB with refusal, that rigid-body displacements are not saved, and the double-springback-card hazard. It does not say whether the copy is atomic or what happens if the source dynain is absent or the destination is read-only.

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?

Front-loaded with the step label, verb, and resource, and every sentence carries information. The long parenthetical about Workbench Output Controls is dense and slows parsing, but the content is not wasteful.

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?

An output schema exists, so return values need not be explained. The description covers the prerequisite step, the destructive/conservation behavior, the size guard, the explicit unsupported data (rigid bodies), and the failure mode to avoid, which is sufficient to call the tool correctly.

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?

Schema coverage is 0%, so the description must compensate and largely does: directory is identified as 'the explicit run's working_dir' and overwrite is tied to the keep-or-replace behavior. It does not state path format expectations (absolute vs. relative) for directory, which is the remaining ambiguity.

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?

States a concrete verb and resource ('copy the solver's ASCII dynain file to dynain.k') plus the downstream purpose (External Model import). It implicitly separates itself from the sibling set_dynain_output, which is named as the producer of the ASCII file, and from multi-system transfers that use .lsda directly.

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?

Gives explicit prerequisites ('Get an ASCII dynain with set_dynain_output(psid, fmt="ascii") in the explicit run'), an explicit exclusion ('leave Workbench's own Output Controls > Stress File for flexible parts OFF'), and a when-not-to-use case (multi-system transfers use .lsda directly, no conversion needed).

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

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

With no annotations, the description carries the full burden and does well: explicitly read-only ('nothing is deleted or started'), discloses the overwriteable-files risk (names only, no deletion), and honestly flags the memory heuristic as uncertain by roughly 3x. It doesn't cover permissions or how verdict thresholds are derived, keeping it from a 5.

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?

Purpose is front-loaded and every clause carries information, but the long parenthetical on the memory heuristic and the trailing args summary make it denser than ideal. Structure is functional rather than crisp.

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?

Given an output schema exists, the description still usefully explains `verdict` (ok/warn/stop) and `reasons`, and covers all preflight checks an agent needs. It is essentially complete, with only minor gaps like exact verdict thresholds.

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?

Schema coverage is 0%, yet the description meaningfully explains all four: ncpu (0 = not given), memory ('words as for the solver, e.g. 200m'), and working_dir ('the newest .k in it is used') with deck_path as the alternative source. deck_path's own resolution semantics are left slightly implicit, so not quite a 5.

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?

States a specific verb and resource ('Check before a solve') and enumerates exactly what it reports: free RAM/disk, memory estimate, overwriteable result files, ncpu vs cores, and audit_deck findings. This is clearly distinguishable from siblings like audit_deck or solve_analysis, which do subsets of this.

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?

'Check before a solve' gives clear timing context, and the description notes it folds in audit_deck results, implying it supersedes a separate audit call in this flow. It does not explicitly name alternatives or exclusions (e.g. vs check_run_health or audit_deck alone), so it falls short of a 5.

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

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

With no annotations, the description carries the full burden and does disclose useful traits: the operation is a read/browse (implying non-destructive), data is thinned to max_points, and an optional dependency must be installed via pip install "ls-dyna-mcp[binout]". It does not describe failure behavior for bad branch names, but the return shape is covered by the output schema.

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?

Front-loaded with the purpose and the drill-down sequence, and the ls-dyna result-name list earns its place by helping recognition. The closing 'Args:' line duplicates the schema without adding value and could be cut.

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?

Five parameters with only one required, an output schema present, and no annotations — the description supplies the calling sequence, thinning behavior, and install prerequisite, which is most of what an agent needs. The unexplained 'directory' parameter is the main remaining hole.

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?

Schema description coverage is 0%, so the description must compensate. It does explain the meaning and ordering of branch, subbranch, and variable through the drill-down narrative, and explains max_points as a thinning control. However, the trailing 'Args: directory, branch, subbranch, variable, max_points' is pure restatement, and 'directory' — the sole required parameter — is never given meaning (binout location? working directory?).

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?

States a specific verb+resource: browse and read binout (LSDA) results, and enumerates the result families it exposes (glstat, matsum, rcforc, spcforc, sleout, nodout), which tells an agent what data class this covers. It is not sharply differentiated from siblings such as read_glstat or read_d3plot, and the overlap with read_glstat is not addressed.

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?

Gives an explicit progressive drill-down protocol: no branch lists branches, branch lists sub-branches/variables, branch+subbranch+variable returns data. That is clear operational guidance on how to sequence calls. It stops short of saying when to prefer this over read_glstat/read_d3plot or when listing is unnecessary.

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

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

With no annotations, the description carries the burden and does well: discloses the lasso-python dependency, the non-finite count as a blow-up signal, vector-magnitude and von Mises handling (worst integration point), and the max_states cap of 20. It omits error behavior when lasso-python is missing and any permission/read-only framing.

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?

Front-loads the core purpose and modes, and the Args line is compact. It is dense to the point of being run-on (parentheticals, ellipsis in the field list), but nearly every clause adds information.

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?

An output schema exists, yet the description still usefully previews the return shape (stats, extremum id, non-finite count). For a 4-param read tool this is nearly complete; only directory format and failure/dependency handling are unstated.

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?

Schema coverage is 0%, so the description must compensate; it documents field (with enum-like examples), state (-1 = spread), and max_states (at most 20). The 'directory' parameter is only listed, not explained (path to the d3plot directory?), leaving one gap.

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?

States a specific verb+resource ('Field results from the d3plot') and precisely describes what is computed: min/max/mean, id of extremum, non-finite count, with vector magnitude and von Mises treatment. It does not explicitly contrast with the sibling summarize_d3plot, so it falls short of a 5.

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?

Gives clear mode selection: 'With no field it lists fields stored' vs 'With a field ... it returns ...', plus state=-1 meaning spread. It never names an alternative tool (e.g. summarize_d3plot) or when-not to use it, so no explicit routing.

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

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

With no annotations, the description carries the full burden, and it does disclose one important behavior: results are thinned to evenly spaced states, so the agent knows it is not getting full fidelity. It does not say how glstat is located from 'directory', what happens if no glstat exists, or whether resolution affects accuracy.

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 first sentence is dense and front-loaded with the useful behavior. The trailing 'Args: directory, max_states' line is pure restatement of the schema and earns no place, slightly diluting an otherwise tight description.

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?

An output schema exists, so return values need not be described. However, for a file-reading tool with zero schema coverage, the description leaves the directory parameter's meaning, missing-file behavior, and selection versus sibling readers unaddressed — adequate but with clear gaps.

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?

Schema coverage is 0%, so the description must compensate. The max_states semantics (maximum number of evenly spaced states retained) are genuinely clarified, but 'directory' is left ambiguous — whether it is a folder searched for glstat or a path to the file itself is unclear. The bare 'Args:' line adds nothing beyond parameter names.

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?

States a specific action and resource: reading energy history from a glstat file, with downsampling to at most max_states states. The operation is identifiable, but it gives no hint how it differs from sibling readers like read_history_file, read_binout, or read_d3plot.

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?

There is no statement of when to prefer this over the other history/result readers in the sibling list, and no preconditions such as the file needing to exist or the analysis having completed. The agent must infer usage entirely from the name.

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

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

With no annotations, the description carries the full disclosure burden and does well: it states the return payload (record count, min/max/last summary computed from ALL records, thinned `records` capped at 500), and explicitly says NaN/Inf become null and are tallied as nonfinite_values. It does not state that the operation is strictly read-only or what happens when the named file is missing, which are the remaining gaps.

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?

Purpose and the binout alternative are front-loaded, and the trailing Args line is a compact index that earns its place given zero schema coverage. No sentence is filler; the density is justified by the amount of behavior being conveyed.

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?

An output schema exists, yet the description still tells the agent the shape of the return (summary plus thinned records), which is the right level of detail. Combined with the kind enumeration and the max_records cap, an agent can call this correctly; only failure-mode behavior (missing file, malformed header) is unaddressed.

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?

Schema description coverage is 0%, so the description must compensate, and it largely does: kind is constrained to the six enumerated types, entity is 'optional id to keep' (a filter), name is 'file name if not the default, e.g. matsum', and max_records is bound to the 500-record thinning cap. Only `directory` is passed over as self-evident rather than explained.

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?

Opens with a specific verb and resource ('Read an ASCII time-history file') and immediately enumerates the six file kinds (matsum, rcforc, sleout, spcforc, rwforc, nodout), so an agent knows exactly what domain this covers. It also distinguishes itself from the binout-reading path, which separates it from the read_binout 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?

The final sentence gives a clear selection rule: use this when the run wrote ASCII files instead of (or besides) a binout. That is an explicit when-to-use condition against an alternative. It stops short of naming the actual sibling tool (read_binout) or covering the read_d3plot/summarize_d3plot boundary, but the routing intent is unmistakable.

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

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

With no annotations, the description carries the full burden and does reasonably well: it discloses the returned contents, the file-resolution fallback order (newest messag[nn] -> mes0000 -> lsrun.stdout.txt), and the meaning of recoverable DIVERGENCE warnings. It omits error behavior when no messag file exists and does not explicitly state read-only semantics.

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?

Front-loaded with purpose, then usage, then an Args block — a sensible order with little waste. It is dense and has a truncated token ('messag'), but every sentence contributes information.

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?

An output schema exists, so return values need not be described; parameters are well covered and the intended use case is stated. The remaining gap is failure/edge behavior (missing or ambiguous messag files) for a tool whose value depends on picking the right input file.

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?

Schema coverage is 0%, so the description must compensate, and it largely does: `name` gets a detailed default-resolution rule plus the lsrun.stdout.txt alternative, and `max_steps` is explained as 'the last N steps are returned in steps'. Only `directory` is left implicit as the location of the solver files.

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?

States a specific verb+resource: read implicit (statics/dynamics) solver progress from the messag file, and enumerates exactly what is extracted (iterations to converge, stiffness reformations, residual norms, convergence flag, totals, divergence warnings). The implicit-solver framing implicitly contrasts with the explicit-oriented siblings (read_glstat, scan_solver_messages), but no sibling is named directly.

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?

'Use it to judge a Workbench Transient/Static LS-DYNA run that is slow or stuck' gives a clear triggering condition. It stops short of stating when not to use it or pointing to the overlapping alternatives like scan_solver_messages or get_run_progress.

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

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

With no annotations, the description carries the full burden and does well: it discloses the env-var gate, the worker-thread execution, a hard timeout capped at 900 s that kills the entire process tree, and that created files are reported. It does not state what happens to partial output when a timeout fires or how failures surface, leaving a meaningful gap for a process-spawning tool.

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?

Front-loads the most consequential fact (the DISABLED gate) and then covers mode and timeout behavior compactly. The trailing 'Args:' line slightly restates parameter names but does add non-obvious semantics such as the character cap and allowed-folder constraint.

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 4-param process-execution tool with an output schema present, the description covers gating, execution model, timeout/kill behavior, headless modes, and that output files are listed. Remaining gaps — error/failure reporting and whether files persist after a kill — are minor given the output schema.

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?

Schema coverage is 0%, so the description must supply all parameter meaning, and it largely does: commands is cfile text capped at 20000 chars, working_dir must be an allowed folder, headless toggles 'runc=' vs 'c= -nographics', and timeout_s is bounded by the 900 s hard cap. The timeout_s default (300) and the exact per-call vs overall nature of the timeout are only implied.

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?

States a specific verb and resource — 'Run an LS-PrePost command file (post-processing automation)' — plus the target directory. The resource is clearly distinct from sibling script/job runners like run_mechanical_script and submit_lsdyna_job, so an agent can route without opening the schema.

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?

Gives concrete preconditions: disabled unless LSDYNA_MCP_ENABLE_LSPREPOST=1, and working_dir must be an allowed folder. It also scopes headless=True to non-graphical commands only. It does not explicitly contrast with sibling automation tools (e.g. run_mechanical_script), so routing between them is left partly to inference.

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

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries the full burden. It does usefully disclose that *INCLUDE directives are followed so a split deck is scanned as a whole, but it does not explicitly state the operation is read-only, how large decks are handled, or error behavior.

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?

Front-loaded with the core purpose, then the important INCLUDE behavior, then a short args list. Efficient with no filler, though the trailing "Args: path, follow_includes" adds little beyond the schema.

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?

An output schema exists, so return values need not be explained. The description covers purpose and the key INCLUDE-following behavior; the main gap is absence of any routing versus overlapping sibling audit tools.

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?

Schema coverage is 0%, so the description must compensate. It explains follow_includes implicitly through the INCLUDE-following sentence, but the false case is not described, and 'path' gets no meaning beyond its name (e.g., relative vs absolute, .k vs .key).

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?

States a specific verb and resource ("Summarise a .k/.key file") plus the scope of the summary (keyword counts, missing essentials such as termination, d3plot output, timestep control). It is clear what the tool produces, but it never distinguishes itself from closely related siblings like audit_deck or presolve_check.

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?

Usage is implied: scan a deck to get a summary and spot missing essentials. However, there is no explicit when-to-use, when-not-to-use, or routing to alternatives such as audit_deck or presolve_check, which overlap heavily with "missing essentials".

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

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

With no annotations, the description carries the behavioral burden well: it states the exact patterns counted, explains default file selection by picking the newest d3hsp[nn]/messag[nn], and notes that the reply's `file` field reports which file was read. It does not explicitly say the operation is read-only or mention limits, but 'Count' strongly implies a non-modifying scan.

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 front-loaded with the core action and stays compact. The pattern list earns its place by defining exactly what is counted, while 'Args: directory, name' is slightly redundant with the schema but not harmful.

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?

Given an output schema exists, the description gives enough detail to call the tool correctly: patterns, default file selection, and the reply's `file` indicator. The main missing piece is routing guidance relative to sibling tools, but for correct invocation the description is largely complete.

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?

Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for `name` by explaining the empty/bare default and newest-file selection, but it only lists `directory` and `name` as 'Args' without describing what `directory` should contain.

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 uses a specific verb, 'Count', and specific resources, d3hsp/messag/mes0* files, plus concrete patterns such as '*** Error nnnnn' and 'FATAL ERROR'. It is clear what the tool does, but it does not explicitly distinguish itself from nearby siblings like tail_solver_file, check_run_health, or read_implicit_progress.

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?

The description gives no explicit when-to-use or when-not-to-use guidance. It never contrasts this scanner with alternatives such as tail_solver_file, check_run_health, read_implicit_progress, or list_solver_files, so the agent must infer when this is the right tool.

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

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: it declares read-only behavior ('nothing is written'), explains the matching rule (all query words, case-insensitive), the ranking heuristic, the fact that hits include file name, title and excerpt, the limitation that integer values are absent, and that the help is an optional install component.

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?

Front-loaded with the core purpose and tightly written for its density, but the trailing 'Args:' block repeats parameter material and the sentence about optional install components could be folded earlier. Minor redundancy rather than bloat.

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?

An output schema exists, yet the description still sketches hit structure, and it covers matching, ranking, path restrictions and the key limitation about integer values. Nothing an agent needs to call this correctly is missing.

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?

Schema description coverage is 0%, so the description must compensate and it does: it defines query semantics (all words must appear, case-insensitive), the max_results range (1-20), and help_dir's meaning, default resolution (installed release or LSDYNA_MCP_HELP_DIR) and the allowed-folder restriction.

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?

States a specific verb and resource ('Search the LS-DYNA user guide (HTML help)') and gives a concrete use case ('find the options of a setting such as Hourglass Type'). It also implicitly separates itself from sibling get_analysis_settings by noting the help holds names, not stored integer values.

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?

Provides clear when-to-use context ('to find the options of a setting') and a follow-up path ('after setting a value, call get_analysis_settings'). It does not explicitly say when to prefer describe_keyword or build_keyword over this search, so the sibling routing is only partially covered.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it explains that LS-DYNA reads and deletes d3kil, that a switch sent to a finished run is refused, and that an 'ok' reply only means the file was written, not that the solver has acted. It also documents the effects of each switch, including termination, restart, dump, and output behaviors.

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 front-loaded with the core action and then organized by switch family, with no wasted sentences. Despite its length, each detail is necessary for correct invocation of a complex, switch-driven tool.

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?

Given the lack of annotations, an output schema that already covers return values, and two undocumented parameters, the description is complete enough to call the tool correctly. It covers the mechanism, side effects, caveats, parameter meanings, and switch-specific behavior.

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?

Schema description coverage is 0%, so the description must compensate. It explains 'directory' as the solver working_dir and enumerates the accepted 'switch' values with their meanings, adding substantial value beyond the bare schema. Minor gaps remain around exact string format and case sensitivity.

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 states a specific verb and resource: steering a running LS-DYNA job by writing a d3kil sense-switch file in its run directory. It clearly distinguishes the operation from general job submission or status tools by naming the mechanism and its effect.

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?

The description gives clear context for using the tool on a running job and explains when individual switches apply, including a troubleshooting-only note for 'conv'. However, it does not explicitly say when to use this tool instead of sibling tools such as stop_lsdyna_job or get_solve_status, leaving some routing ambiguity.

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

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

With no annotations, the description carries the full burden and does: per-key independent attempts and reporting, read-back comparison with NaN/Infinity caveats, 'not applied' outcomes, unit expectations (End Time in seconds), value rejection before send, and a documented interface limitation for selection settings. An agent knows the failure modes and side effects before calling.

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?

Front-loaded with the action and verification model, and nearly every clause adds operational detail that prevents a bad call. There is redundancy (read-back/comparison stated twice) and heavy parenthetical nesting, but no filler or marketing language.

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 high-complexity mutation tool with an output schema, this covers parsing, validation ranges, key resolution ambiguity, failure reporting, and known interface limitations. The only real gap is the unexplained analysis_index argument, which is minor against the breadth of what is disclosed.

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?

Schema coverage is 0%, so the description must compensate for both parameters. settings_json is covered thoroughly — key matching rules (full name, caption, last segment, case/punctuation-insensitive), ambiguity handling, value parsing (

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?

States a specific verb and resource (set analysis settings) and immediately qualifies it with verification semantics ('each value is read back and compared', 'each key attempted independently'). It also distinguishes itself from sibling paths by naming get_analysis_settings for reads and add_keyword_commands/set_dynain_output for selection settings.

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?

Gives explicit when-to-use: read current values with get_analysis_settings first ('-1 is Program Controlled'), and for drop-down settings like Hourglass Type or Output Format use keyword snippets or the GUI instead. That is a concrete exclusion plus named alternatives, not inferred guidance.

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

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

With no annotations, the description carries the load well: it discloses the side effect (a springback keyword card is injected), the FTYPE semantics verified on the real solver, the duplicate-card failure mode, and the psid/part_ids_json precondition. It stops short of saying whether the call is idempotent or what happens if a springback card already exists, which is the remaining gap for a mutation tool.

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?

Front-loaded with the action and the produced artifact, then the format semantics, then the caveat, then args. Dense and mostly earned, though the Workbench-setting sentence is long and the trailing Args list repeats parameter names the schema already declares.

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?

An output schema exists, so return values need not be explained, and the description covers the mutation, format trade-offs, and preconditions. The only meaningful omission is the unexplained analysis_index and any note about which analysis/connection state the call assumes.

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?

Schema description coverage is 0%, so the description must compensate, and it largely does: psid is explained (must exist unless part_ids_json given), fmt is enumerated with real semantics (ascii | binary | both | lsda mapped to FTYPE 0/1/2/3), and part_ids_json is explained as adding a *SET_PART_LIST with that psid. analysis_index is only named, with no meaning or default behavior described, leaving one of four parameters unexplained.

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?

States a concrete verb and mechanism: 'Make the run write a dynain ... by adding a *INTERFACE_SPRINGBACK_LSDYNA keyword snippet', and names the specific artifact produced. It also positions itself relative to siblings by noting the ASCII dynain is what prepare_dynain can convert, so an agent can tell it apart from the keyword-authoring tools.

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?

Gives actionable selection guidance: the FTYPE/format table implies pick ascii if you plan to convert, lsda is 'not convertible here', and it warns to leave the Workbench 'Stress File for flexible parts' setting off or the deck gets two springback cards. It does not explicitly say when to prefer this over add_keyword_commands/create_lsdyna_system_snippet for the same card, but the usage context is clear.

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

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 well: it explains why a background thread is used (the local solve cannot run non-blocking), that the call returns at once with a solver working_dir, that get_solve_status reports 'Solving' meanwhile, and that other Mechanical tools return 'busy' while file and job tools stay responsive.

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 critical default/wait behavior is front-loaded in the first two sentences and the busy-state caveat is useful. The trailing 'Args: analysis_index, wait' line is pure filler since both parameters are already in the schema, and the prose is dense but largely earned.

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?

An output schema exists, so return-value documentation is not needed, and the description still volunteers the working_dir return. Remaining gaps are minor: analysis_index meaning, and whether a solve overwrites prior results or what happens if a solve is already running.

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?

Schema coverage is 0%, so the description must compensate. It does explain `wait` thoroughly (default False, background thread + immediate return; True blocks), but `analysis_index` is only listed by name with no meaning, default 0 semantics, or how to discover valid indices.

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?

States a specific verb + resource ('Solve the LS-DYNA analysis') and scopes it to Mechanical's local solve, which implicitly separates it from the deck-submission sibling submit_lsdyna_job. It never names that sibling outright, so differentiation requires inference rather than being spelled out.

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?

Gives clear operational context: wait=False (default) returns immediately and the run should be watched with check_run_health / tail_solver_file / get_solve_status, while wait=True blocks. It names concrete follow-up tools but offers no explicit rule for choosing wait=True versus the default, nor when to prefer this over submit_lsdyna_job.

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

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

With no annotations, the description carries the full behavioral burden and does well by disclosing that sw1 stops the job and writes d3dump so it can be restarted, while force=True terminates the process. It does not mention permissions, authentication requirements, or the exact consequence of cancelling a pending job beyond cancellation.

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 front-loaded with the primary action and follows immediately with the running-job modes and force guidance. It is compact, though the trailing 'Args: job_id, force' is somewhat redundant with the schema.

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?

An output schema exists, so return values need not be explained. For correct invocation, the description explains the required job_id and the meaning of force clearly enough, including the restartability trade-off. It could be more complete about pending-job behavior and safety implications, but the core invocation guidance is present.

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?

Schema description coverage is 0%, so the description must compensate for both parameters. It explains force=True meaningfully, but job_id is only listed by name and not otherwise characterized beyond its name and integer type. The force semantics are strong, but the parameter coverage is only partial.

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 states a specific verb and resource: cancel/stop a job. It also distinguishes pending jobs from running jobs and explains the two running-job modes. It does not explicitly differentiate this tool from sibling tools such as send_sense_switch, so it falls short of a 5.

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 clearly explains when to cancel a pending job and gives the running-job alternatives: send sw1 for a restartable stop, or force=True to terminate the process. The trade-off between restartable stop and forced termination is useful. It lacks explicit guidance on when to prefer this tool over send_sense_switch or other monitoring siblings.

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

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 exceptionally: it discloses queueing behavior (max concurrent via LSDYNA_MCP_MAX_JOBS, default 1, one job per folder), output file location (lsrun.stdout.txt in the input folder), licensing prerequisites (LSTC_LICENSE=ANSYS, HPC licenses beyond one core), and the counter-intuitive negative-ncpu reproducibility/CPU-time tradeoff.

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?

Purpose is front-loaded, followed by constraints, then a compact arg list — nothing extraneous. The middle block is packed into long run-on sentences (queue/output/solver-path rules in one breath), which costs some readability but every clause carries real information.

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?

An output schema exists, so return values need not be described; the description instead covers the things an agent actually needs before calling — allowed solvers, allowed input folders, concurrency limits, license requirements, SMP vs MPP invocation, dry-run mode, and restart mechanics.

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?

Schema coverage is 0%, so the description must compensate, and it does: every one of the 11 parameters is explained with added meaning beyond the schema — ncpu non-zero and bounded at 512 magnitude, depends_on with -1 = last submitted, memory in words with empty = solver default, extra_args_json restricted to case/memory2/jobid with an example, and restart_file's r=<file> launch form.

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?

States a specific verb and resource ('Run LS-DYNA on a .k file') plus an explicit scope constraint ('outside Workbench, what LS-Run does'), which lets an agent distinguish it from the Workbench-side solve_analysis sibling without opening any schema.

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 clearly frames the context in which this tool applies (standalone solver run, not Workbench) and routes the restart case to check_restart_setup. It stops short of an explicit 'use solve_analysis instead when X' exclusion, so the alternative is implied rather than stated.

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

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

With no annotations the description carries the full burden and does well: it flags experimental/disabled status, the enabling env var, a concrete crash (0xC0000005) on headless d3plot load, and that failures are reported in the reply rather than silently. It does not say what files are written or where lspost.msg lands, nor how the 300s timeout interacts with a hung process.

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?

Four sentences, front-loaded with the disabling condition and env var, which is the most decision-relevant fact. The crash anecdote is long but earns its place as a risk warning; nothing is padded.

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?

An output schema exists, so return-value detail is not needed, and the description covers gating, risk, alternatives, and that errors surface in the reply. The remaining gap is parameter and timeout behavior for a tool with zero schema documentation.

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?

Schema description coverage is 0%, so the description must supply meaning for both parameters. 'Args: d3plot_path, timeout_s' only restates the parameter names; there is no stated path format, whether path is a run directory or file, or what happens on timeout expiry.

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?

States a concrete verb and resource: have LS-PrePost load a d3plot and write its lspost.msg summary, with the s=<d3plot> form. It also points to alternatives (read_binout / check_run_health), though it does not distinguish itself from the closer sibling read_d3plot, which an agent may confuse it with.

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?

Gives an explicit precondition (LSDYNA_MCP_ENABLE_LSPREPOST=1) and explicit steering away with 'Prefer read_binout / check_run_health', which is strong when-not-to-use guidance. It never says positively when this tool is the right choice, leaving the agent to infer that it is the fallback for lspost.msg summaries when the GUI-backed path is enabled.

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

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.

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.

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.

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.

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.

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.