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 meaningful traits: elements are appended after the last element (ordering), the call returns element numbers, and omitting stiffness produces unstiffened elements that break the analysis. Remaining gaps are the role of the 'model' parameter (active model vs named) and 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 purpose sentence, then per-parameter notes — every sentence carries information, no filler. Slightly fragmented formatting, but nothing 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?

An output schema exists, so return-value explanation isn't needed, and the description still flags that element numbers come back. For a 4-parameter mutation tool it covers the risky parts well; the unaddressed 'model' parameter is the only substantive omission.

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: 'nodes' shape is shown by example ([[1,2],[2,3]] for bars), 'fe_type' codes are enumerated with a pointer to lira://reference/tables, and 'stiffness' gets both provenance and a failure warning. Only 'model' is left 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 and resource — add elements of one FE type after the last element — and notes the return value (element numbers). That clearly separates it from lira_add_nodes (nodes, not elements), though it never names that sibling 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 context is implied by the prerequisite note that stiffness must come from lira_model_summary or the analysis will fail, which is real guidance. But there is no explicit statement of when to call this versus lira_set_stiffness, lira_copy_stiffness, or lira_add_nodes, and no exclusions.

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 does disclose mutation semantics (append after the last node), the geometry unit convention, and that node numbers are returned, but says nothing about which model is affected, whether the operation is reversible, or what happens on invalid coordinates.

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 tight sentence with the core action and return value front-loaded. No filler or redundancy.

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 covers the return value, so the description needn't explain results in detail. But for a mutation tool with zero annotation coverage and an undocumented 'model' parameter, the definition is only minimally sufficient 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 coverage is 0%, so the description must compensate. It does clarify that coordinates are XYZ triples in LIRA's geometry unit, which adds real meaning beyond the untyped 'array of array of number' schema. However, the 'model' parameter is not mentioned at all, leaving a significant 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 and resource ('Add nodes') with scope ('after the last node') and return information ('returns their numbers'). It is distinguishable from lira_add_elements by resource name alone, though the description never explicitly contrasts the two.

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 use this versus siblings like lira_add_elements or lira_import_text_model, and no prerequisites or preconditions. Only implied usage via 'after the last node', which is ordering behavior, 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?

The readOnlyHint already establishes that this is a safe read operation, and the description adds useful behavior: it returns only the last tail_lines lines and defaults to the active or most recently analysed model. It does not cover failure cases, such as no prior analysis, but it meaningfully extends the annotation.

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 a single compact sentence with no obvious waste and front-loads the resource being retrieved. The phrasing is slightly awkward ('last tail_lines lines') but remains 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?

An output schema exists, so return values do not need to be described, and the read-only annotation covers safety. However, the description does not clarify what 'protocol' contains or what happens when no analysis exists, leaving moderate gaps for an otherwise simple retrieval 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 carry parameter meaning. It clarifies the model default and indicates that tail_lines limits the output to the last lines, but it does not explain the model identifier format or the tail_lines default/range, leaving some 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?

It names a specific resource, the solver protocol from the last analysis, and describes the default model selection and tail-line truncation. The purpose is clear, but 'protocol' is somewhat ambiguous and the description does not explicitly distinguish this from nearby siblings such as lira_analysis_status.

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 default behavior ('active model, or the model analysed last') implies when the tool is useful, but it does not state when to choose it over alternatives or when not to use it. Usage is inferable rather than explicit.

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 readOnlyHint already declaring the safety profile, the description adds real behavioral detail: the exact status vocabulary (including the non-obvious 'needs_user'), that a protocol summary is included only once the analysis has ended, and that wait_s blocks for up to N seconds. It does not say whether repeated polling is cheap or what 'needs_user' implies for follow-up action.

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 tight sentences that front-load the resource and status set, then the wait parameter. No filler, though the mid-sentence shift to the optional parameter is slightly abrupt.

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 and readOnlyHint covers safety, so the description only needs to explain the wait and the state model — which it does for a one-optional-parameter polling tool. Minor omission: no guidance on what an agent should do on 'needs_user' or 'failed'.

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 carry the single parameter — and it does, explaining that wait_s > 0 is a bounded blocking wait in seconds for a running analysis to end, with the default of 0 supplied by the schema. The only gap is that the timeout return state is not stated.

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 and scope: 'State of the last analysis started by this server', and enumerates the possible states plus the protocol-summary payload. An agent can tell it apart from data-retrieval siblings, though it never explicitly distinguishes itself from lira_status or lira_analysis_protocol.

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 polling-after-run use case is only implied by the mention of wait_s and 'last analysis started by this server'; it never says to call this after lira_run_analysis or to use lira_analysis_protocol for the full protocol. No exclusions or alternatives are named.

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 refusal condition on unsaved changes and a non-obvious side effect (a server-read model is saved, after a backup, before closing). It omits what state the model is left in afterward, whether the active-model pointer is cleared, and what errors surface.

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?

Three short sentences, front-loaded with the core action and default, followed by the two behavioral caveats. Each sentence carries distinct information, though the backup parenthetical is slightly dense.

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 no explanation, and the description covers both parameters plus the destructive/saving behavior. Remaining gaps are edge cases: behavior when the named model is not open, and the identifier format.

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 explains that model defaults to the active one and that discard_changes gates the unsaved-changes refusal. It still does not say what form the model identifier takes (name, path, handle), leaving one 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 specific verb and resource ("Close a model") plus a scope default ("the active one"), which cleanly separates it from siblings like lira_open_model, lira_save_model and lira_create_model. An agent can identify the operation 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 a concrete conditional rule: it refuses when there are unsaved changes unless discard_changes is true, which tells the agent exactly when it must flip a flag. It does not name alternatives (e.g. save first via lira_save_model), so the guidance is clear but not exhaustive.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the important prerequisite that analysis must have been run and that combinations default to all, but it does not explain behavioral parameters such as envelope, threshold, by_abs, or export_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 description is short, front-loaded with the purpose, and structured with a separate combinations note. Every sentence contributes useful routing or parameter 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?

Given the tool's complexity, the output schema covers return values and annotations cover read-only safety. However, the description leaves many input parameters unexplained, so an agent can understand the main intent but not the full behavior of important options like envelope and threshold.

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% across 10 parameters, so the description must carry parameter meaning. It explains only the combinations parameter and references lira_node_displacements for the rest, leaving parameters like envelope, threshold, by_abs, components, and export_path 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 resource and action: node displacements in load combinations, including the DCL/РСН terminology. It also distinguishes itself from lira_node_displacements by explaining the combination-vs-case substitution.

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?

Clearly says this should be used after lira_run_analysis and that combination numbers come from lira_load_combinations, defaulting to all. It implies the alternative lira_node_displacements for case-based results but does not state explicit exclusions.

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?

Annotations already declare readOnlyHint=true, so safety is covered; the description still adds real behavioral content beyond that: the row granularity (one row per element, combination, limit state and design section) and the meaning of the DCL/РСН terminology. It does not discuss result volume, pagination, or performance at scale, so it stops short of 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?

Front-loaded with the tool's subject, followed by the one parameter worth explaining and then a row-shape note; no filler sentences. The final clause 'otherwise as lira_element_forces' is efficient but leans on an external reference rather than standing alone.

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 shape is partly covered by the output schema and the description's granularity note, and the delegation to lira_element_forces is a genuine mitigation for shared parameters. For a 12-parameter tool with zero schema descriptions, though, the description leaves too many filters (envelope, threshold, by_abs, export_path) unexplained for an agent to call it with confidence.

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 12 parameters, and the description documents only one of them (limit_states, including the meaning of values 1-4 and the null=all default). The remaining eleven (top, by_abs, sort_by, elements, envelope, families, threshold, components, export_path, combinations, model) get no meaning at all; the phrase 'otherwise as lira_element_forces' delegates but does not document them.

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 resource (internal forces and stresses) constrained to load combinations, and explicitly contrasts with the sibling lira_element_forces ("otherwise as lira_element_forces"). An agent can distinguish it from the plain element-forces and displacement siblings without opening schemas, though the retrieval verb is only 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?

Usage is implied by the domain framing: use this when results are wanted per load combination rather than per raw analysis case. However, there is no explicit when-to-use/when-not statement and no routing guidance versus lira_combination_displacements or lira_design_forces, so selection among the results tools still requires 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 load and does disclose a genuinely non-obvious behavior: 'LIRA derives areas and inertias again.' It also states the source is left as-is by the copy semantics and that a new number is returned. However, it never clarifies whether a persistent stiffness row is created, whether the source must be unattached, or what permissions/model state are required — meaningful gaps for an unannotated write.

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?

Three tight sentences: purpose, parameter naming convention with units, then the return/next-step note. Front-loaded and free of padding. Embedding a quoted JSON literal makes the sentence slightly harder to parse but conveys required syntax.

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 value explanation is a bonus rather than a requirement. Still, for a 3-parameter mutating tool with zero annotations, leaving `model` undefined and leaving the side-effect/persistence model ambiguous is a real gap an agent could trip over.

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: it explains that only changed parameters go in `changes`, gives the allowed key names with units (B/H in cm, E in t/m2, Ro in t/m3) and an inline example, and frames `source` as the stiffness being copied. The `model` parameter is never mentioned, so it falls one step short of full 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?

States a specific verb and resource: 'Create a stiffness as a copy of stiffness source with some parameters changed.' That is precise and distinguishes it from a plain setter. It references lira_set_stiffness only as a follow-up assignment step rather than as the alternative it must be chosen over, so it stops short of full sibling differentiation.

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 workflow is made explicit: copy an existing stiffness, override named parameters, then 'assign it with lira_set_stiffness.' An agent knows the call sequence. No exclusion is stated (e.g. when to define a stiffness from scratch rather than copy), which keeps it below 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 does disclose title constraints, model_type semantics, and optional save-as behavior. However, it does not say whether creating a model replaces the active model, what state or permissions are required, or what other side effects occur.

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 then organized into parameter-specific notes with no filler. The model_type enumeration is necessary because the schema provides no enum or parameter descriptions.

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 covers return values, so omitting return-format details is acceptable. Still, for a create/mutation tool with no annotations and zero schema parameter descriptions, the undocumented 'description' parameter and unspecified active-model side effects leave material 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 description coverage is 0%, so the description must compensate. It explains model_type values 1-5 in detail, title length and forbidden characters, and save_as as an optional .lir path, but it never documents the 'description' parameter.

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 'Create an empty model' gives a specific verb and resource, and 'empty' distinguishes it from sibling open/import tools such as lira_open_model and lira_import_text_model. The scope 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 says when to choose this tool over lira_import_text_model, lira_open_model, or other model-setup siblings, nor does it state prerequisites. The parameter notes are specification details, not usage 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?

The annotations already declare destructiveHint=true and idempotentHint=true, and the description adds substantial context beyond them: only work-folder results are deleted, the model file is unchanged, results can be recreated with lira_run_analysis, and deletion is keyed by model name so same-named models in other folders are also affected.

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 three tight sentences, front-loaded with the core action and scope. Each subsequent sentence adds a distinct and useful behavioral caveat: model file unchanged, recreate path, and same-name cross-folder deletion.

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 describe return values. Given the destructive annotation and single optional parameter, the description is complete: it explains what is deleted, where, what is not changed, how to recreate results, and the same-name side effect.

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 the parameter meaning. It does so by explaining that the optional model parameter can be a .lir path for a closed model, an open model, or omitted to target the active model. The exact string format for open models could be clearer, but the semantic coverage is good.

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: delete analysis results of a model. It also clarifies the target location (LIRA's work folder) and distinguishes the effect from the model file itself, which is altered by neither the deletion nor the related recreate action.

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 applies: delete results for a specified, closed, or active model, with the active model as the default. It also notes that lira_run_analysis recreates the results and that same-named models in other folders are affected, but it does not explicitly state when not to use this tool or name an alternative deletion method.

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?

readOnlyHint=true already tells the agent this is a safe read. The description adds real context beyond that: it must be called after analysis, it yields one row per element/section/limit state/dcf, and it explains LIRA's load-case sign notation and the crane/seismic 'with' flag. It says nothing about ~11 behavioral knobs (top=20 truncation, by_abs, envelope, threshold, families, components, export_path writing a file), which is a notable gap for a read-only tool with a file-export parameter.

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 prerequisite are front-loaded in the first sentence, which is good. The second sentence is a long nested clause inventorying the returned row shape, which is partly redundant with the existing output schema and displaces more valuable parameter guidance.

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 core purpose and result-row semantics are covered, and the output schema handles return values. But with 11 undocumented parameters at 0% coverage and a complex, filter/envelope/export-heavy interface, the definition leaves an agent unable to invoke the tool correctly beyond defaults.

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 11 parameters, so the description carries the full burden. It names no parameter at all; 'load_cases' and 'with' are output fields, not inputs. An agent reading this cannot tell what top, by_abs, envelope, threshold, families, components, sort_by, limit_states, or export_path do.

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 operation on a specific resource: computing design combination of forces (DCF/РСУ) and returning it per element/section/limit state. It anchors itself against siblings by saying the row shape matches lira_combination_forces and otherwise lira_element_forces, which lets an agent place it in the results family. It stops short of a crisp one-line 'returns X for Y' statement, since 'Design combinations of forces' is a noun-like phrase.

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 prerequisite 'after lira_run_analysis' is explicit and genuinely useful sequencing information. The implicit contrast with lira_combination_forces and lira_element_forces implies when this variant is chosen, but the description never says it outright or states exclusions, leaving the agent to infer the choice.

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?

The readOnlyHint annotation already establishes safety. The description adds useful behavioral context by explaining that these dialogs are current transient UI state and when they typically appear, though it does not elaborate further on interaction flow.

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 short sentences with no waste: the first defines the return content, and the second provides immediate usage context. The purpose is front-loaded.

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 parameters, an output schema, and a readOnly annotation, the description is nearly complete. It could more explicitly connect the returned buttons to lira_press_dialog_button, but the essential context 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?

The tool has zero parameters, so parameter semantics are inherently complete. Baseline score of 4 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?

The description states that the tool returns currently shown modal dialogs and enumerates their fields: title, text, and buttons. This is clearly distinguishable from sibling tools like lira_press_dialog_button, though the description does not explicitly name that acting tool.

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 concrete usage context: dialogs are usually waiting after a timed-out call or when an analysis status is needs_user. It does not explicitly state exclusions or name lira_press_dialog_button as the follow-up action, but the 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?

Annotations already declare readOnlyHint=true, so safety is covered. The description adds substantial context beyond that: the row granularity (one row per element, load case, shape, and design section), that shape applies only to dynamic load cases as a mode number, that units come from the LIRA model and vary per component, and that design-section count is controlled elsewhere.

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 prerequisite are front-loaded, and the long component enumeration is dense but genuinely informative given the total absence of schema descriptions. It is somewhat run-on, but every clause carries data an agent cannot get elsewhere.

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 row-granularity note plus prerequisite make the core call pattern clear. Yet for an 11-parameter tool with zero schema coverage, the semantics of key filtering and shaping parameters (envelope, threshold, by_abs, sort_by, top) remain opaque, which is a real 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?

Schema description coverage is 0% across 11 parameters, so the description must compensate and largely does not. It explains families (example value, default all) and partially explains components via the per-family component lists, but top, model, by_abs, sort_by, elements, envelope, threshold, load_cases, and export_path are left entirely 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?

The description states a specific verb and resource: returns internal forces and stresses of elements after analysis, answered per element family. It is clearly distinct from siblings like lira_node_displacements or lira_combination_forces, though it does not explicitly name how it differs from lira_design_forces.

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 states the prerequisite clearly ('after lira_run_analysis') and notes that query arguments apply within each family and that families defaults to all. However, it gives no guidance on when to prefer this over sibling tools such as lira_combination_forces or lira_design_forces, leaving the choice implicit.

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?

readOnlyHint already covers the safety profile and an output schema exists, so the bar is lower, but the description adds little beyond naming the export format. It doesn't say whether it exports the currently open model or a specified one, whether output is large, or what 'documents 0-8' means for scope.

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?

One short sentence with no waste, but it is terse to the point of under-specification; the parenthetical is the only detail and it is opaque.

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 covers return values, but the undefined 'model' parameter and absent usage context leave real gaps for a simple export tool that an agent needs to call 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?

There is one optional parameter 'model' with 0% schema description coverage, and the description never mentions it. An agent cannot tell whether it takes a model name, a path, or is simply ignored in favor of the open model.

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 name implies export, and the description identifies the resource (the whole model) and the output format (LIRA's text input format). But it never states an explicit verb ('Export...') and the parenthetical '(documents 0-8 and more)' is cryptic rather than clarifying. It's understandable at a glance but not precisely stated.

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 guidance on when to use this versus lira_model_summary, lira_save_model, or the inverse lira_import_text_model. The import counterpart is the obvious alternative/round-trip partner and is never 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description usefully adds that results are broken out per node and per load case, but it says nothing about the behavior of top/envelope/threshold/export_path, which materially change the output; with annotations present the bar is lower, so 3 fits.

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 front-loaded sentence with no filler, but the dense engineering abbreviations (RBW, bimoment) and the odd 'Loads on fragment' opening make it slightly harder to parse than necessary.

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, but a 10-parameter tool with filtering, envelope, threshold and export options is badly under-described. An agent cannot tell how the optional parameters interact or what happens by default.

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 10 parameters, so the description carries the full burden and fails to explain nodes, load_cases, components, sort_by, envelope, threshold, top, or export_path. Only an oblique hint ('per node and load case') maps to two of the ten params.

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 the resource (fragment loads) and the specific quantities returned (RX, RY, RZ, RUX, RUY, RUZ, RBW), which is a precise verb-plus-detail statement. It falls short of 5 because it does not distinguish this from the related sibling lira_read_loads, so an agent has no signal about which reader to pick.

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 guidance on when to use this rather than lira_read_loads or lira_punching_loads, and no prerequisites (e.g., that the model must be open or an analysis run). Usage must be inferred entirely from the resource 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?

No annotations are provided, so the description carries the full burden. It discloses the input format structure (numbered documents) and the output file type (.lir), which is useful. But it says nothing about overwrite behavior on save_as, prerequisites such as an open model, or how malformed text is handled, leaving significant behavioral gaps 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?

The core verb and resource are front-loaded, followed by supporting format details. The numbered-document examples earn their place by illustrating the input format. Slightly verbose in the document list, but 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?

An output schema exists, so return values need not be explained. The description covers the input format and output file well. Gaps remain around prerequisites, overwrite behavior, and error handling, but for a two-parameter import tool the coverage is largely adequate.

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 add meaning for both parameters: it explains the text format's document structure and clarifies that save_as is a .lir file. However, it does not specify path semantics for save_as or constraints on text beyond the format sketch, so compensation is 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 uses a specific verb and resource: 'Create a model from LIRA's text input format and save it as save_as (.lir).' This clearly distinguishes it from lira_create_model (which presumably creates a model without text import) and from lira_export_text (the inverse operation). However, it does not explicitly name the sibling it is not, so an agent still has to infer the boundary with lira_create_model.

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 implies usage through the phrase 'The best way to learn it is to export a similar model with lira_export_text,' which routes the agent to a learning path but not a when-to-use-this-instead rule. There is no explicit statement of when to choose this over lira_create_model or lira_write_table, so usage guidance 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?

Annotations already declare readOnlyHint=true, so safety is covered; the description adds real value on top by disclosing where backups live (lira-mcp-backups next to the model), their ordering (newest first), and the retention guarantee that the server never deletes them. Only missing element is failure behavior when no backups exist.

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 short sentences with the resource and default target front-loaded, followed by the storage location and retention note. No filler, and every clause carries information an agent would otherwise have to guess.

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 structure needn't be described, and the parameter and storage behavior are covered. The remaining gap is error/empty-state behavior and how a listed backup connects to lira_restore_backup, which a slightly longer description could have closed.

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 single parameter is an undescribed anyOf string/null, so the description must compensate — and it does, explaining that the argument accepts a .lir path or an open model and that the active model is the default. It doesn't clarify what a null explicitly means versus omission, but the essential semantics are given.

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 exact resource (backups the server made of a model file) and the scope (a .lir path or an open model, defaulting to the active one), with ordering stated. The listing verb is only implied by the name and the 'newest first' phrasing rather than stated outright, and no sibling is named, so it falls just 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 conveys the default target (the active model) when no argument is passed, which is genuinely useful context for invocation. However, it never says when to call this versus alternatives such as lira_list_models or lira_restore_backup, nor any precondition like having a model open or a backup existing.

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?

The readOnlyHint annotation already covers safety, but the description adds a genuinely non-obvious side effect: calling it may launch the LIRA application ('starts LIRA if needed'). It also discloses the table inventory and column shapes, plus a resource URI for deeper detail, which is useful context beyond the annotation.

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 in the first clause, followed by the inventory and a reference pointer. The parenthetical column formats are dense but earn their place as domain detail; only the line wrapping makes it slightly harder to scan.

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 values need not be explained, and the resource URI covers column formats and FE type codes. The one unresolved question is whether listing tables requires an open model, which the description does not clarify.

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 the baseline is 4 and there is nothing the description could add on that axis. The inline enumeration of typical tables (Nodes_Coordinates, Elements_TypeAndNodes, etc.) compensates by describing the shape of the result instead.

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 the specific resource (the set of input tables supported by this LIRA release) and implicitly the list verb. The trailing pointer 'Read a table first to see its value format' distinguishes it from lira_read_table, though the sibling is not 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?

The workflow hint ('Read a table first to see its value format') implies this is a discovery step preceding table reads, and '(starts LIRA if needed)' signals it can be called cold. However, it never explicitly states when to use this versus lira_read_table or lira_list_models, leaving the agent to infer the sequencing.

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?

readOnlyHint=true already establishes the safety profile, so the bar is lower. The word 'now' usefully signals a point-in-time snapshot and the mention of 'unsaved changes' and 'active' flags are genuinely informative state fields, but neither is explained and no refresh/pagination semantics are given.

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 compact sentence with no filler. The colon-list format of returned fields is dense and slightly terse, but every word earns its 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?

An output schema exists and there are no inputs, so the description carries little burden. Still, terms like 'active' and 'unsaved changes' are left undefined, and there is no signal about where in the workflow this listing fits.

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 to disambiguate; baseline 4 applies. The description correctly implies no filtering or scoping arguments are needed.

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 the resource and scope precisely ('Models open in LIRA now') and enumerates the fields returned, which distinguishes it from siblings like lira_list_backups or lira_list_input_tables. It lacks an explicit verb, but the intent 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?

No guidance on when to call this versus alternatives such as lira_status, lira_model_summary, or lira_open_model. The agent must infer that this is a discovery step before operating on an open model.

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?

Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds that the model must be analysed and lists the combination attributes returned; however, it does not discuss authentication, model-selection behavior, or error conditions.

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 front-loaded sentence with no wasted text. It is efficient, though domain abbreviations like 'DCL, РСН' reduce accessibility slightly.

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 annotations cover read-only safety. Still, the undocumented 'model' parameter and lack of usage guidance leave meaningful gaps 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?

The sole parameter 'model' has 0% schema description coverage and is not explained in the description. The mention of 'an analysed model' hints at its role, but no format, identifier expectations, or default behavior are given.

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 clearly: load combinations of an analysed model, including number, name, formula, special/seismic flags, and building code. It is clear what the tool retrieves, though it does not explicitly contrast itself with siblings such as lira_combination_forces or lira_read_loads.

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 'of an analysed model' implies a prerequisite, but there is no explicit guidance on when to use this tool versus related siblings. No exclusions, alternatives, or invocation context are 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?

Beyond the annotations it discloses real side effects: the 'current' view switches LIRA's view and fits it to the window, save_path writes a file to disk, and LIRA's window must not be minimized — all of which explain why readOnlyHint is false despite this being a picture tool. It does not say what happens on failure (e.g. minimized window error) or whether the view switch persists.

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 output is front-loaded, roughly 60 words, and every clause adds information — what is returned, then view, then save_path, then the window constraint. Nothing is repeated from the schema or 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?

For a three-optional-parameter tool with no output schema, the description covers the return value (a PNG), the file-write option, and an environment prerequisite. It leaves open whether image dimensions/quality are fixed and how errors surface, but an agent has enough to call it 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 description coverage is 0%, so the description carries the full burden and does so: it enumerates the view values (isometric, xoz, xoy, current) that the schema lacks as an enum, explains the model default, and specifies that save_path must be an absolute .png path. The only minor gap is that the model parameter's identifier format (name vs. id) is not stated.

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 exactly what the tool produces: a PNG rendering of a model with its loads, numbers and colours as LIRA draws them. That is a specific output plus resource, and no sibling tool (model_summary, export_text, etc.) produces a visual render, so the agent can distinguish it 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 gives the default target ('the active one') and lets the caller pick a view, which is clear operating context. It does not explicitly say when to prefer this over textual siblings like lira_model_summary or lira_export_text, so it stops short of full alternative 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?

The readOnlyHint already establishes safety, and the description adds useful behavioral context: the default is the active model, whether analysis results are retained, when they were written, and warnings when results belong to another version or same-named model. This is meaningful beyond the annotations.

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 and every clause contributes useful content about the summary's scope and caveats. The phrasing is slightly run-on, especially around the quoted 'results' section, but it remains readable and 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?

Given an output schema exists and the tool is read-only, the description is nearly complete for correct selection and invocation. The main remaining gap is how to specify the optional model argument, but the default behavior and result-provenance caveats are well covered.

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 optional model parameter has 0% schema description coverage, so the description must compensate. It clarifies that the default is the active model, but does not explain how the model should be identified, such as by name, path, or index.

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-like resource overview and enumerates exactly what the summary contains: model type, units, node/element counts, FE types, stiffnesses, load cases, and results status. It also distinguishes this as an orientation tool with 'Start here before reading or changing a model.'

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 says to start here before reading or changing a model, which gives a strong usage context. It does not explicitly name alternatives or exclusions, but the prerequisite-like guidance 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?

Annotations only declare readOnlyHint, so the description carries the rest and does add real behavior: the model argument accepts a closed file, a path, or falls back to 'the model analysed last' (important stateful default). It also discloses that dynamic load cases emit one row per mode. Gaps remain around what envelope/threshold do to the result set.

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 in the first sentence, then a compact per-argument block with no filler. The telegraphic style is efficient, though the parameter lines read closer to notes than prose and the omission of six params is not an omission of words but of coverage.

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 explaining return shapes is rightly skipped, and the component/unit note covers what columns mean. Still, for a 10-parameter post-processing tool with zero schema descriptions, an agent cannot know how envelope or threshold alter the output, whether export_path writes a file, or what top/sort_by do — gaps that would cause misinvocation.

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 well for model, nodes (both the [1,5] array form and the "1-10 15" range string), load_cases defaults and component naming with units. But top, by_abs, sort_by, envelope, threshold and export_path get no mention at all, leaving six of ten parameters — several of which materially change results — 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?

Names a specific resource ('node displacements of load cases') and ties it to a lifecycle point ('after lira_run_analysis'), which separates it from sibling result tools like lira_element_forces and lira_combination_displacements. It does not explicitly contrast itself with the combination variant, so sibling differentiation is only 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?

'After lira_run_analysis' gives a clear prerequisite ordering, and the note that the model 'may be closed' tells the agent it need not open one first. However it never states when to prefer lira_combination_displacements or lira_element_forces over this tool, nor what happens if analysis has not been run.

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 two real behavioral traits: LIRA is launched if not running, and the opened model becomes the active one. It does not say what happens to a currently open/active model, how the path is resolved, or what error surfaces if the file is missing.

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?

One sentence, front-loaded with the action and resource, with the side effects in a parenthetical. Nothing wasted and nothing buried.

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 no explanation, and the tool is a simple one-parameter operation. Still, for a state-mutating open call with zero annotations, the description should say whether an already-open model is replaced and how failure is reported.

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% for the single `path` parameter, so the description must compensate. It adds meaningful constraints — the path points to a .lir model file rather than a model name or directory — but says nothing about relative vs absolute paths or quoting.

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 (open) and resource (.lir model file), plus the two side effects: launching LIRA if needed and making the model active. It is distinguishable from lira_import_text_model and lira_create_model by name alone, though the description never explicitly contrasts them.

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 guidance on when to choose this over lira_import_text_model, lira_create_model, or lira_list_models, and no prerequisites or exclusions. The only hint is the implicit 'you have a .lir file' condition baked into the purpose statement.

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?

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful context about the returned modal quantities and the default-all behavior, but does not cover prerequisites, permissions, or output format beyond what the output schema likely provides.

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 front-loaded sentence, but much of it enumerates return fields that are already covered by the output schema, reducing focus on invocation semantics.

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?

Because an output schema exists and readOnlyHint is present, the description does not need to explain return values in depth. However, it leaves gaps around the model parameter and the practical context for invoking the tool, so it is only adequate rather than 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 for both parameters. It only hints that load cases default to all and fails to explain the model parameter or accepted load case values.

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 identifies the resource as modes/periods of dynamic load cases and states the default scope is all load cases. It lacks an explicit action verb and does not differentiate itself from sibling result-extraction tools, but the purpose is still understandable.

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 only usage guidance is that load cases default to all. There is no indication of when to use this tool versus related result tools, nor any prerequisite such as running a dynamic analysis first.

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 text-matching rules (case and '&' ignored), the disambiguation behavior for multiple dialogs, the return value ('the dialogs still shown'), and a concurrency caveat about other user-driven dialogs. It does not say what happens when no dialog or no matching button exists (error vs. no-op) or whether the call blocks waiting for a dialog.

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 tight sentences with the action front-loaded and no filler; each sentence carries distinct information (matching, disambiguation, safety constraint, return value). The inline 'title:' label is slightly telegraphic but 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 and the description still usefully summarizes the return value as the dialogs still shown, so the agent knows the result is a dialog snapshot rather than a pressed-button confirmation. Combined with the matching and disambiguation rules, this is nearly complete; only failure/no-match behavior and blocking semantics are 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 largely does: 'button' is defined as button text with normalization rules ('case and & ignored'), and 'title' is defined as a partial dialog title used for disambiguation. Minor gap: it never says 'title' is a substring match versus an exact match, though 'part of the dialog's title' implies substring.

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 (press a button of LIRA's dialog) and immediately qualifies it with the matching key ('by its text'), so the agent knows exactly what operation is performed and on what. Includes concrete literal examples ("OK", "Да", "Отмена") that make the resource tangible and distinguish it from the dialog-listing 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?

Gives an explicit when-not rule: 'Press only dialogs your own calls caused; the user may be answering others,' which prevents a real class of race conditions. Also explains when the optional title argument is needed ('needed when LIRA shows several'). It does not point to the sibling lira_dialogs as the way to discover what is on screen, so the alternative routing 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?

The readOnlyHint annotation already establishes that this is a safe read operation, so the description's main added value is that the result contains N, QX, QY forces and MX, MY, MZ moments per node and load case for defined punching shear contours. However, with ten parameters the description does not disclose important behavior such as what 'top', 'envelope', 'threshold', 'by_abs', 'components', 'sort_by', or 'export_path' do, nor does it describe filtering or export side effects.

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 front-loaded sentence with no filler. The parenthetical component list is compact and useful, and every clause contributes to defining the tool's scope.

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 ten-parameter tool with 0% schema description coverage, the description is far too sparse to support correct invocation. The output schema and readOnlyHint reduce the need to explain return values and safety, but the description still fails to cover parameter behavior and filtering/export semantics.

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 ten parameters, so the description must carry the burden of explaining parameter meaning. It only broadly gestures at nodes, load cases, and force/moment components, while leaving top, model, by_abs, sort_by, envelope, threshold, components, and export_path entirely 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?

The description identifies a specific resource and scope: loads on punching shear contours around nodes, with the force and moment components named (N, QX, QY; MX, MY, MZ) and the per-node/per-load-case granularity stated. It distinguishes the tool from general load-reading siblings by focusing on punching shear contours, though it relies on the name and readOnlyHint to make the retrieval verb explicit.

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 explicit guidance on when to use this tool instead of alternatives such as lira_read_loads, lira_fragment_loads, or lira_element_forces. The phrase 'for contours defined in LIRA' gives some context, but it does not tell an agent when this tool is appropriate or when another tool should be preferred.

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 readOnlyHint already declaring it safe, the description adds meaningful behavioral context by explaining the load record structure, LIRA type codes, direction codes, and units reference. It does not describe filtering behavior or how load_cases affects the result, but it substantially improves transparency beyond the annotation.

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: the first sentence states the purpose, then it efficiently lists the load fields and code meanings. It contains no filler and is appropriately sized for explaining a coded text export.

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?

Although an output schema exists and the description explains load record fields, it leaves the two input parameters completely unexplained. For a tool whose filtering behavior depends on load_cases, this is a significant completeness 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?

Schema description coverage is 0%, and the description does not explain either parameter. It never says what 'model' expects or what 'load_cases' filters, so the two invocation parameters remain undocumented in both structured and natural-language 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?

The description states a specific verb and resource: reading loads of a model from LIRA's text export. It is clear what the tool returns, but it does not explicitly distinguish itself from siblings such as lira_set_loads, lira_fragment_loads, or lira_read_table.

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 implies retrieval but gives no explicit when-to-use guidance, no prerequisites, and no comparison to alternatives. An agent must infer from the name and context when this tool is appropriate versus lira_read_table or lira_fragment_loads.

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?

Beyond the readOnlyHint annotation, the description discloses genuinely useful behavior: empty cells are returned as null, values follow LIRA's current units, large tables are paged via offset/limit, and the response reports the total row count. That pagination and null-handling context is exactly what an agent needs 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?

Every sentence carries information and the purpose is front-loaded, but the layout is choppy: a bare fragment opens the description and the 'numbers:' label reads like an unpolished bullet, with the filter syntax explained before the units convention it depends on.

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 values needn't be explained, and the read-only annotation covers safety. However, for a five-parameter tool with zero schema coverage, the description leaves the 'table' parameter undefined and omits the limit default, so it is adequate but not 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 carry the parameter burden and only partially does: it explains the 'numbers' selector syntax ('1-10 15'), the model default (active model), and the offset/limit paging intent. It never says what 'table' values are valid (presumably names from lira_list_input_tables) and does not mention the limit default of 200.

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 verb 'read' plus the resource 'input table' makes the operation identifiable, and the parenthetical about the default model clarifies scope. It stops short of differentiating itself from siblings like lira_read_loads or lira_list_input_tables, and the opening fragment is not a full sentence.

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 only usage hint is the parenthetical about the default model and a pointer to lira_model_summary for units. There is no guidance on when to choose this over lira_read_loads or lira_list_input_tables, and no prerequisites or exclusions are 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered by structured data. The description adds genuinely useful behavioral context — fixed units (cm2, cm2/m, %, mm) and the presence of an 'errors' list for values LIRA could not select — but says nothing about prerequisites, model scoping, or how filtering/sorting affects the returned set.

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?

Sentences are dense but not padded; the problem is ordering — it leads with a fragmentary purpose clause and then spends most of its length on a column-by-column inventory. The unit conventions, which are the most actionable content, are buried mid-paragraph rather than front-loaded.

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 re-listing every result column is largely duplicative; the description would be better spent on the undocumented input controls. With 9 parameters at 0% schema coverage and no stated prerequisites or filtering semantics, an agent cannot reliably invoke this tool correctly on the first attempt.

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 9 parameters, yet only design_option receives any explanation, and even that is thin ('LIRA's design variant, default 1') without saying what values are valid or what changes. The eight other parameters — elements, components, threshold, sort_by, by_abs, top, model, export_path — are left entirely undefined for an agent to guess at.

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 phrase 'Reinforcement selected by LIRA's reinforced concrete design' identifies the resource but supplies no verb (get/list/read), so it reads as a data-format note rather than a statement of what the tool does. Nothing distinguishes it from siblings like lira_design_forces or lira_element_forces, which could plausibly also return design results.

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 guidance on when to call this versus lira_design_forces or lira_element_forces, and no stated prerequisites (e.g., a model must be open and a design/analysis run first). The only usage-adjacent content is an aside that LIRA produces both asymmetric and symmetric variants when asked.

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 destructiveHint=true already declared, the description adds substantial context: the current file is backed up first, the operation is reversible, an open model is closed and reopened, it must have no unsaved changes unless discard_changes is true, and analysis results become stale against the replaced version. That is exactly the behavioral detail annotations cannot carry.

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 short sentences, front-loaded with the action and its default, then the reversibility, then the preconditions, then the downstream consequence. No filler; every sentence conveys a distinct operational fact.

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 no explanation, and the destructive preconditions are thoroughly covered. The only gap is that the model argument's role and default are left implicit, which matters slightly given zero schema description coverage.

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 carry parameter meaning; it explains backup (path from lira_list_backups, defaults to newest) and discard_changes (permits an unsaved model to be discarded). The model parameter is only implied by 'an open model', so one of three parameters remains loosely specified.

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: puts a backup file back in place of the model file, with the default (newest) named. It also names the sibling lira_list_backups as the source of the path, so an agent can distinguish this from lira_open_model, lira_save_model or lira_list_backups 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?

Gives clear context: obtain the path from lira_list_backups, default to the newest backup, and even explains the undo case (restoring the newest backup again reverses the restore). It doesn't explicitly state when not to use it versus lira_open_model or lira_import_text_model, so it stops short of full alternative 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 delivers real operational context: LIRA closes the model after the analysis so the agent must reopen it, a 'needs_user' status means a LIRA dialog blocks progress, and a geometrically unstable structure may 'finish' while still emitting warnings. It stops short of describing wait=false return behaviour or concurrency/error states.

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 scope statement is front-loaded in the first line, followed by clearly separated operational facts (precondition, wait/timeout, result contents, side effect). Every sentence adds information an agent needs; nothing is padding.

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, yet the description still usefully flags protocol verdict and warning-line content. The remaining gap is asynchrony after timeout and the wait=false path, which are the main things an agent could get wrong given three optional, undocumented parameters.

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 explains wait=true semantics, that timeout_s bounds the wait, and that the model defaults to the active one. It leaves the default timeout_s value and what wait=false returns or hands back unstated.

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 ('Analyse a saved model') plus the default target ('the active one'), which distinguishes it from siblings like lira_analysis_status and lira_analysis_protocol that only report on an analysis. An agent can identify the action 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 clear preconditions ('save changes first (lira_save_model)') and routes the agent to lira_analysis_status when the timeout fires while the analysis keeps running. It does not explicitly state when not to use this tool (e.g., while another analysis is already running) or how it differs from lira_analysis_protocol, so it stops short of full when/when-not coverage.

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?

Goes well beyond openWorldHint/destructiveHint by disclosing that the model file is backed up first (mitigating the destructive hint), that Python stops at timeout_s but a hanging COM call (e.g. an LIRA dialog) is NOT interrupted, and that print() output returns as 'output'. Those are exactly the operational gotchas an agent needs before executing arbitrary code against a live model.

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 and the routing rule, then the bound names, then behavior — good ordering with little filler. Minor friction: the guidance sentence is broken mid-clause by the line wrap and the trailing 'LIRA's API description: ...' line dangles as a pointer rather than actionable 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?

For an arbitrary-code tool this is unusually complete: it lists every pre-bound name with signatures (lira, doc, adapter methods, constants), defines the result/output return convention, and covers backup and timeout risk. With an output schema present it correctly does not spend words on return-value structure.

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 carries the load and mostly does: it explains the `model` scoping (doc is the document of `model`, defaults to the active one, None if nothing open) and the `timeout_s` semantics including the non-interruptible COM caveat. It stops short of saying what form a model reference takes (file path vs. name vs. open handle) or what happens on a timeout or exception in `code`.

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 Python code inside the server with full access to LIRA' — and immediately scopes it as the fallback ('for anything the other tools do not cover'). It explicitly contrasts itself against the 38 sibling tools by saying to prefer the dedicated ones when one fits, so an agent can place it 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 an explicit selection rule: use this only when no dedicated tool covers the task, otherwise prefer the dedicated tool. That is a when-to-use plus a named alternative class, which is the strongest form of routing guidance available for an escape-hatch 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 disclose a genuinely non-obvious side effect: the first overwrite in a session triggers a backup copy into a sibling folder, and the result names the copy. It does not discuss permissions, write failures, or whether subsequent overwrites in the same session also back up.

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?

Three short sentences, front-loaded with the core action before the argument semantics and the backup caveat. Inline quoting and stray line breaks make it slightly ragged but nothing 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?

An output schema exists so return values need not be described, and the description still usefully notes the result names the backup copy. What remains missing is the format of the 'model' parameter, path resolution rules, and overwrite behavior past the first save in a 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% — the schema only has titles and defaults — so the description must compensate, and it does: 'model' is explained as defaulting to the active model and 'save_as' as a new .lir path. The word 'model' itself is ambiguous (name, id, or path), which is the main remaining 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 and resource — save a model, defaulting to the active one — and separates the plain save from the save-as behavior via the save_as argument. It is clear enough to distinguish from lira_create_model and lira_open_model, though those siblings are not named.

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 default-to-active-model behavior and the save_as override are spelled out, which implies when to pass each argument, but there is no explicit guidance on prerequisites (e.g., must a model be open) or on when to use this versus lira_export_text or lira_create_model.

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 real weight: it discloses the side effect that LIRA creates the load case if it doesn't exist, that delete_all wipes all self-weight loads regardless of load_case, and that only elements whose sections have a density are affected. It doesn't say whether repeated calls duplicate loads (idempotency) or whether existing loads are preserved.

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 core action, then the deletion alternative, then verification. The nested parenthetical and clause stacking make it dense but nothing 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?

An output schema exists so return values need no explanation, and the description covers the operation, its side effects, the alternate destructive mode, and how to verify results. The only gap is the `model` selector, which is minor for a five-param 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 it does for four of five params: load_case (auto-created if missing), elements (optional subset filter), delete_all (mode switch that nullifies load_case), and safety_factor (multiplier). Only `model` is left 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?

The description gives a precise verb+resource: adding self-weight loads derived from element section densities, scaled by safety_factor, into a named load case. This is clearly separable from siblings like lira_set_loads or lira_fragment_loads, which deal with different load categories.

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 states the two operating modes clearly: the default additive mode, and delete_all=true which instead removes all self-weight loads and ignores load_case. It also directs the agent to verify with lira_read_loads (type 16). It stops short of explicitly contrasting against lira_set_loads for non-self-weight loads.

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 discloses the text-format rebuild, table copying, verification, backup-then-overwrite ordering, all-or-nothing failure, refusal for models with differing combination norms, and the residual unverifiable-data risk requiring manual LIRA check. That is unusually rich behavioral disclosure 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?

Content is front-loaded with the purpose and then the payload contract before the long behavioral caveats, and nearly every clause adds information. The prose is somewhat dense and the final warning sentence is a bit sprawling, but there is no 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 return values need not be described, and the safety/atomicity story is fully covered. What remains thin is the 'model' parameter (default-null resolution) and whether the model must be open or saved beforehand — minor gaps for an otherwise complete definition.

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 the 'loads' item shape ({case, target, type, direction, values}) and the semantics of 'load_cases' (omit to replace all loads). The 'model' parameter is left entirely unexplained, which is the one remaining 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?

The first clause states a specific verb and resource ('Replace loads of a saved model') plus scope ('of load_cases only, or all loads when omitted'), which lets an agent distinguish it from lira_read_loads and lira_fragment_loads without opening a schema. The second line additionally pins down the data shape expected.

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 when to use the tool via the load_cases selection semantics and references lira_read_loads as the source of the 'loads' payload, which is a useful workflow cue. But it never names an alternative (e.g. lira_fragment_loads) or states explicit when-not-to-use conditions beyond the refusal case, so guidance is implied rather than spelled out.

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 listed directions become fixed while the others become free and that [] frees the nodes, which is important mutation behavior. It still omits whether existing restraints are overwritten, required model state, permissions, and other side effects.

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: 'Restrain nodes' establishes the action immediately, followed by the fixed/free semantics and a concise example. There is no repetition or wasted text.

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 do not need to be explained. However, with no annotations and 0% schema description coverage, the definition should more fully cover mutation side effects and parameter formats. It partially compensates by explaining direction semantics and the [] clearing behavior, but gaps remain around nodes/model and operational prerequisites.

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. It clarifies the 'directions' vocabulary (X, Y, Z, UX, UY, UZ) and the special [] value, but it says nothing about the required 'nodes' parameter format (integer node IDs versus a string) or the optional 'model' parameter.

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: 'Restrain nodes'. It also explains the effect precisely, including that listed directions become fixed while others become free and that [] frees the nodes. It does not explicitly contrast this operation with sibling tools such as lira_set_loads or lira_add_nodes, 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?

The description implies usage by explaining that listed directions are fixed, other directions are freed, and [] clears restraints. However, it does not state when to use this tool versus alternatives, what prerequisites are required (such as an open model or existing nodes), or any conditions under which it should not be used.

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 of behavioral disclosure for a mutation tool. It does not say whether assigning a stiffness overwrites existing values, whether the operation is reversible, what permissions are required, or what side effects occur.

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 only two sentences, front-loads the core action, and uses the second sentence for the key workflow relationship with lira_copy_stiffness. There is no wasted text.

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 mutation tool with no annotations, the description should at least clarify overwrite behavior or the role of the unexplained 'model' parameter; it remains adequate but incomplete.

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 usefully explains the elements syntax ('[1, 5]' or '1-10 15') and that stiffness should be a number from lira_model_summary, but it does not explain the optional 'model' parameter at all, leaving one of three parameters 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?

The description states a specific verb and resource: 'Assign a stiffness ... to elements'. It distinguishes itself from the sibling lira_copy_stiffness by explaining that copy creates a stiffness whereas this tool assigns it.

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 to use this tool versus lira_copy_stiffness: to make a group stiffer or softer, first create a stiffness with copy_stiffness and then assign it here. It also tells the agent where to source stiffness values (lira_model_summary), though it does not state explicit exclusions.

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?

Annotations already declare readOnlyHint=true, so the safety profile is known; the description adds real context beyond that: output varies by connection state, and the tool will not launch LIRA. It stops short of stating failure behavior when LIRA is absent or disconnected.

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?

Three short sentences, with the primary answer (versions in use, connection state) front-loaded and the conditional extra content placed after it. Slight redundancy in phrasing ('that LIRA release') but 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?

An output schema exists, so return values need not be described; the description still usefully flags that the payload changes depending on connection state and mentions the tools-availability list. For a zero-parameter status tool with annotations, nothing needed 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?

Zero parameters, so per the baseline this scores 4. Nothing in the description is needed to explain inputs and nothing misleading is said about them.

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 resource (LIRA installation status) and enumerates exactly what is reported: installed versions, the active version, and connection state. The conditional clause ('when connected, also lists...') plus 'Does not start LIRA' separates it from action siblings like lira_open_model and lira_run_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?

Usage is only implied — an agent infers it should call this to check whether LIRA is present/connected. The one explicit boundary, 'Does not start LIRA', is useful but there is no statement of when to prefer this over siblings such as lira_list_models or lira_list_input_tables, nor any prerequisite 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?

No annotations are provided, so the description carries the full behavioral burden. It does not say whether the stop is immediate or graceful, whether partial results are retained or discarded, whether the call blocks until termination, or what error occurs if no analysis is running.

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 short sentence that is front-loaded and free of filler. It could carry one more clause of behavioral detail without becoming 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 means return values need not be explained, and the zero-parameter surface keeps things simple. However, for a control operation on a long-running process, the absence of any note about state after stopping or interaction with lira_analysis_status leaves a real 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 tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate.

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 ('stop') and resource ('the running analysis'), which is enough to distinguish it from lira_run_analysis and lira_analysis_status. It doesn't explicitly name those siblings, but the semantics are 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 phrase 'the running analysis' implies it applies only while an analysis is in progress, but the description never states when to call it versus checking lira_analysis_status first, nor what to do if nothing is running.

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 well: it discloses that validation is all-or-nothing ('on any error nothing changes'), that errors come back with 0-based row/column positions, and that the model file is backed up before its first change. Notable gaps remain around permissions and what exactly changes in the model beyond 'add objects (e.g. nodes)'.

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 write action and the numbers semantics lead, followed by failure behavior and backup. Four tight sentences with no filler, though the awkward mid-sentence line breaks slightly hamper 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 no explanation, and the description covers the mutation risks an agent most needs (atomicity, backups, error indexing). Missing only the role of the 'model' parameter and the expected row/column shape.

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 4 parameters, so the description must compensate. It does explain the rows/numbers interaction well, but the optional 'model' parameter is never mentioned, and the column layout expected in each row array is left unstated, so compensation 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?

States a specific verb and resource: 'Write rows into an input table and apply them to the model.' This clearly distinguishes it from lira_read_table and from the object-specific setters (lira_add_nodes, lira_set_loads), though it never names those siblings 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 two modes (replace whole table vs replace only numbered objects) effectively describe when each form of the call is appropriate. However, there is no explicit routing guidance against alternatives like lira_add_nodes or lira_set_loads, so the agent must infer which tool applies.

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