Skip to main content
Glama

MIDAS CIVIL NX tools (MIDAS IT Europe)

CS454 - Moving Load Wizard

cs454_moving_loads
Idempotent

CS 454 assessment live loading with the CS454 - Moving Load Wizard plugin's own engine: notional lanes laid out on the carriageway (line lanes on a grillage, surface lanes on a plate deck), the ALL model 1/2 vehicles up to the chosen level, SV/HB where picked, and the moving load cases with remaining areas — each written and read back. It reads the deck from the model the way the plugin does (reference girder, width, kerb, cross-beam group, skew) unless reference/surface/section.width are given. Without apply it only previews (lanes, vehicles, cases, blockers, planHash). With apply: true it writes, records the run for cs454_moving_loads_undo, and never overwrites lanes, vehicles or cases it did not write.

Input Schema

NameRequiredDescriptionDefault
applyNo
lanesNoLane options. Main one: picked — the loading models to lay out: M1S (ALL model 1 single), M1C (convoy), M2 (ALL model 2), SV, HB, SVM1S, SVM1C, SVM2, FW (footway), ACC (accidental). Also level, packing, svVehicle…
scopeNoALL = lanes + vehicles + cases; LANES = lanes only; LOADS = vehicles and cases on the model's existing lanes.ALL
configNoAdvanced: any other plugin configuration field, deep-merged over the defaults.
sectionNoCarriageway cross-section, m: width, kerbOffset, markedLanes, hardShoulder, verges, footways, central reserve. width/kerbOffset are read from the deck if omitted.
surfaceNoSurface lanes: the alignment. mode GROUP (group), NODES (nodes) or RANGE (range).
laneKindNoDefault: what the model suggests (beams -> LINE, plates -> SURFACE).
readDeckNoRead reference line, width, kerb offset, cross beams and skew from the deck.
vehiclesNoVehicle options. levels: assessment levels NORMAL, T26, T18, T7_5, T3, FE1, FE2 (lower levels are stacked in automatically); allModel1, allModel2, limitStates, svType…
referenceNoLine lanes: the reference line. mode RANGE (range: element ids e.g. '1-10'), GROUP (group: structure group name) or NODES (nodes: [ids]).
codeChangeNoAllow setting the moving load code to BS. Changing it from another code DELETES every lane in the model — only with the user's agreement.
laneSourceNoNEW
unitSwitchNoAllow switching CIVIL NX to kN, m for the write and back afterwards (needed for non-SI models).
writeOptionsNoLane write options: loadDist LANE|CROSS, groupName (cross-beam group), moving BOTH|FORWARD|BACKWARD, skewStart, skewEnd.
confirmPlanHashNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior1/5

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

The description explicitly says codeChange can 'DELETE every lane in the model', which is a destructive behavior, while annotations declare destructiveHint: false. This is a direct annotation contradiction, so behavioral transparency must be scored 1 under the rules despite otherwise rich behavioral detail.

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

Conciseness4/5

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

The description is dense but appropriately sized for a 15-parameter wizard and front-loads the core workflow before preview/apply details. The first sentence is quite packed, but no sentence is obviously wasted.

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

Completeness4/5

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

For a complex tool with no output schema, the description explains the main preview output fields, the apply behavior, deck-reading fallbacks, undo recording, and overwrite safeguards. It is nearly complete, though it omits guidance for confirmPlanHash and laneSource.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is high at 80%, and the description adds meaningful semantics beyond the schema: apply controls preview versus write, readDeck has fallback behavior unless reference/surface/section.width are given, and codeChange has a destructive side effect. It still leaves some parameters such as laneSource and confirmPlanHash unexplained in prose.

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

Purpose4/5

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

The description clearly states a specific purpose: CS454 assessment live loading using the plugin's own engine to lay out lanes, vehicles, moving load cases, and remaining areas. It is much clearer than a generic name restatement, though it does not explicitly distinguish this tool from the sibling cs454_lane_layout.

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

Usage Guidelines4/5

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

It gives useful usage context: without apply it previews, with apply: true it writes, and the run can be undone via cs454_moving_loads_undo. It also says codeChange should only be used with the user's agreement, but it does not explicitly route the agent between this tool and sibling lane-layout tools.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources