Skip to main content
Glama

MIDAS CIVIL NX tools (MIDAS IT Europe)

Read the model for Eurocode moving loads

ec_moving_loads_read
Read-only

Read-only: changes nothing in the model. Call it before ec_moving_loads to see what the Eurocode - Moving Load Wizard would do. Returns: existing (the lanes, vehicles, cases and groups already in the model, each marked if an earlier ec_moving_loads run created it); laneKindSuggestion (LINE for beams, SURFACE for plates); deckRead (reference girder or plate edge, width, kerb offset, cross-beam group, skew — narrowed by deckFilter, reversed by trafficOtherWay); the lanes, lane roles and cases the given settings would produce; config (the plugin's own settings file — pass it back as configFile); options (valid load groups, vehicles and Irish Rail trains). Takes the same inputs as ec_moving_loads; the write permissions (codeChange, unitSwitch) only change which blockers are listed.

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_read"
  }
}

Input Schema

NameRequiredDescriptionDefault
lanesNoLane options: prefix (default EC), packing, wheelSpace, optimiseNotional, lm2Manual / lm2Centre, sv / svCentre / svWidth (LM3 route), tracks { tracks, firstTrack, spacing, gauge }, userLanes.
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).
codeChangeNoA permission for the write tool. Here it only changes which blockers are listed — this tool never writes. Accepted so the same inputs serve both tools.
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 shows the lanes the settings would lay out; EXISTING shows the lanes already in the model.NEW
unitSwitchNoA permission for the write tool. Here it only changes which blockers are listed — this tool never writes. Accepted so the same inputs serve both tools.
writeOptionsNoLane write options the write tool would use (loadDist, groupName, moving, skewStart/skewEnd); here they only shape the lanes shown.
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. Changed4 schema fields changed
    • changedInput schema / properties / codeChange / description
      Previous value: -"Allow setting the moving load code to EUROCODE. Changing it from another code DELETES every lane in the model — only with the user's agreement."New value: +"A permission for the write tool. Here it only changes which blockers are listed — this tool never writes. Accepted so the same inputs serve both tools."
    • changedInput schema / properties / laneSource / description
      Previous value: -"NEW lays out and writes lanes; EXISTING loads the lanes already in the model."New value: +"NEW shows the lanes the settings would lay out; EXISTING shows the lanes already in the model."
    • changedInput schema / properties / unitSwitch / description
      Previous value: -"Allow switching CIVIL NX to kN, m for the write and back afterwards (needed for non-SI models)."New value: +"A permission for the write tool. Here it only changes which blockers are listed — this tool never writes. Accepted so the same inputs serve both tools."
    • changedInput schema / properties / writeOptions / description
      Previous value: -"Lane write options: loadDist LANE|CROSS, groupName (cross-beam group), moving BOTH|FORWARD|BACKWARD, skewStart, skewEnd (°; read from the deck when omitted)."New value: +"Lane write options the write tool would use (loadDist, groupName, moving, skewStart/skewEnd); here they only shape the lanes shown."
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

Consistent with readOnlyHint=true, it opens with 'Read-only: changes nothing in the model' and reinforces it twice ('this tool never writes'). Beyond the annotations, it discloses what is returned (existing, laneKindSuggestion, deckRead, lanes/cases, config, options), how earlier runs are marked, and non-obvious interactions like 'the deck is then not re-read unless readDeck: true'.

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?

Front-loaded with the safety statement and the sequencing instruction, then a structured 'Returns:' enumeration — every clause carries information. It is dense and long, with heavy semicolon chaining in the returns list, but no sentence is filler. Slight tightening would earn a 5.

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?

With 16 parameters, nested objects and no output schema, the description carries the return-shape burden and does so (existing / laneKindSuggestion / deckRead / lanes / config / options). Remaining gaps are minor: no mention of failure behavior when no deck or no settings exist, and no guidance on how to pass 'config' back verbatim beyond 'pass it back as configFile'.

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 already 100%, so the baseline is 3, but the description escalates meaningfully: deckFilter 'narrows' the deck read, trafficOtherWay 'reads the deck the other way round' (reversing skew), config is the plugin's own settings file passed back as configFile, and writeOptions only shapes lanes shown. The opaque permission flags (codeChange, unitSwitch) are explained as blocker-list modifiers rather than writes.

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 says exactly what the tool does: reads the model and reports what the Eurocode Moving Load Wizard would produce, explicitly contrasting with its write sibling ('Call it before ec_moving_loads to see what the ... Wizard would do'). Combined with the title, an agent can distinguish this from ec_lane_layout or ec_moving_loads 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.

Usage Guidelines4/5

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

'Call it before ec_moving_loads' gives a clear, actionable trigger, and 'Takes the same inputs as ec_moving_loads' plus the note that codeChange/unitSwitch only change which blockers are listed tells the agent exactly how to sequence the pair. It does not name non-Eurocode alternatives such as cs454_moving_loads_read or ec_lane_layout, so the routing is complete for the sibling pair but not the whole toolset.

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