Skip to main content
Glama

MIDAS CIVIL NX tools (MIDAS IT Europe)

Eurocode - Moving Load Wizard

ec_moving_loads
Idempotent

EN 1991-2 traffic loading with the Eurocode - Moving Load Wizard plugin's own engine: lanes laid out on the carriageway (line lanes on a grillage, surface lanes on a plate deck) for the chosen load groups gr1a / gr1b / gr3 / gr4 / gr5, fatigue models and rail (LM71, SW/0, SW/2, HSLM, Irish Rail trains), the MIDAS vehicles with the EN or UK alpha factors, and the moving load cases (characteristic / frequent) — each written and read back. It reads the deck from the model the way the plugin does unless reference/surface/section.width are given, and accepts the plugin's exported settings file. Without apply it only previews (lanes, vehicles, cases, stages, blockers, planHash). With apply: true it writes, records the run for ec_moving_loads_undo, and never overwrites lanes, vehicles or cases it did not write.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "ec_moving_loads"
  }
}

Input Schema

NameRequiredDescriptionDefault
applyNo
lanesNoLane options: prefix (default EC), packing, wheelSpace, optimiseNotional, lm2Manual / lm2Centre, sv / svCentre / svWidth (LM3 route), tracks { tracks, firstTrack, spacing, gauge }, userLanes.
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 settings.
loadingNoLoading (the plugin's Loading step): disciplines (ROAD, FATIGUE, RAIL), groups (gr1a, gr1b, gr3, gr4, gr5 — the road models follow), roadModels / excludedModels, fatigueModels, railModels, lm3Vehicles, psiValues (CHARACTERISTIC, FREQUENT), factors (alphaPreset EN|UK, alphaQ, alphaq…, footwayCombination), laneLoading, minLoadedLanes / maxLoadedLanes, straddle (MANUAL|ADJACENT), loadRemainingArea, userCases, ieRail…
sectionNoCarriageway cross-section, m: width, kerbOffset, 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 the reference line / alignment, width, kerb offset, cross beams and skew from the deck (default on, off over a loaded settings file).
referenceNoLine lanes: the reference line. mode RANGE (range: element ids e.g. '1-10'), GROUP (group), or NODES (nodes: [ids], shape).
codeChangeNoAllow setting the moving load code to EUROCODE. Changing it from another code DELETES every lane in the model — only with the user's agreement.
configFileNoThe plugin's own Export JSON settings file (or its "config"), as text or object: starts from those settings instead of the defaults. The deck is then not re-read unless readDeck: true.
deckFilterNoRead the deck only from these members, as the plugin's Show only: group (structure group name), section ("S:<id>" beam section or "T:<id>" plate thickness), zMin / zMax (level band, m).
laneSourceNoNEW lays out and writes lanes; EXISTING loads the lanes already in the model.NEW
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 (°; read from the deck when omitted).
confirmPlanHashNo
irishRailTrainsNoIrish Rail CCE-STR-PSD-008 Appendix C trains on the tracks: true for all, or train ids / names (ec_moving_loads_read options). Dynamic factor settings in loading.ieRail.
trafficOtherWayNoRead the deck the other way round (the plugin's "Traffic runs the other way").

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.5/5.0
Behavior1/5

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

The description is otherwise unusually transparent: it names the preview return fields, says runs are recorded for ec_moving_loads_undo, and states it never overwrites lanes it did not write. But it also says codeChange 'DELETES every lane in the model', which contradicts the destructiveHint=false annotation declaring only additive updates.

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 purpose is front-loaded and the dense prose mostly earns its place for a 19-parameter wizard with preview/apply modes. The single-paragraph run-on structure makes it harder to scan than it could be, but it is not padded with irrelevant material.

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 mutating tool with no output schema, the description covers preview output fields, write behavior, undo recording, deck-reading defaults, and non-overwrite guarantees. It still omits what apply returns and does not explain confirmPlanHash or permission/analysis prerequisites, so it is strong but not complete.

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

Parameters4/5

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

Schema description coverage is already high at 89%, so the baseline is 3. The description adds genuine cross-parameter meaning: deck reading is overridden by reference/surface/section.width, configFile starts from exported settings and suppresses re-reading unless readDeck is true, and apply controls preview versus write. confirmPlanHash remains unexplained.

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

Purpose5/5

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

The description states a specific verb and resource: it lays out EN 1991-2 traffic lanes and writes the associated vehicles and moving load cases via the Eurocode Moving Load Wizard engine. It clearly distinguishes preview from write behavior and references the related undo/read operations, so an agent can identify the tool's scope 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.

Usage Guidelines3/5

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

It explains that without apply the tool only previews and with apply it writes, and it documents scope options such as ALL/LANES/LOADS. However, it does not explicitly say when to choose this over close alternatives such as ec_lane_layout or cs454_moving_loads, leaving the routing to inference.

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