Skip to main content
Glama

MIDAS CIVIL NX tools (MIDAS IT Europe)

Read the model for CS 454 moving loads

cs454_moving_loads_read
Read-only

Read-only: changes nothing in the model. Call it before cs454_moving_loads to see what the CS454 - Moving Load Wizard would do. Returns: existing (the lanes, vehicles, cases and groups already in the model, each marked if an earlier cs454_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 and cases the given settings would produce; config (the plugin's own settings file — pass it back as configFile); options (valid loadings, vehicles and Irish Rail trains). Takes the same inputs as cs454_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": "cs454_moving_loads_read"
  }
}

Input Schema

NameRequiredDescriptionDefault
lanesNoLane options. picked — Loadings to lay out: M1S (ALL model 1 single), M1C (convoy), M2 (ALL model 2), FW (footway), ACC (accidental), SV / HB (routes alone), SVM1S / SVM1C / SVM2 (SV with ALL), HBM1S / HBM1C / HBM2 (HB with ALL). Also level, packing, svVehicle, svPlacement, svStraddle, actualLanes, prefix…
configNoAdvanced: any other plugin configuration field, deep-merged over the settings.
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).
vehiclesNoVehicle options: levels (NORMAL, T26, T18, FE1, T7_5, FE2, T3; lower levels stacked in), allModel1, allModel2, svTypes (e.g. ["SV 80", "SV 100"]) and hbUnitsList (e.g. [30, 45]) — every one crossed with every ALL vehicle — svSpeeds, limitStates, envelopes ({ family: true|false }: envelope load combinations, one per family; combinations on by default), fireEngines, customVehicles…
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.
irishRailTrainsNoAdd Irish Rail CCE-STR-PSD-008 trains as user-defined vehicles: true for all, or a list of train ids / names (cs454_moving_loads_read options).
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 BS. 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.9/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description states it changes nothing, never writes, marks lanes created by earlier runs, explains deck-reading behavior, and clarifies how configFile and permissions affect results. This is rich behavioral context that an agent cannot infer from annotations alone.

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

Conciseness5/5

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

The description is dense but front-loaded: the read-only guarantee and sibling relationship come first, followed by the return fields. Despite its length, every part addresses either behavior, return shape, or parameter usage for a complex 16-parameter preview tool.

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

Completeness5/5

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

There is no output schema, so the description must explain returns. It does so comprehensively: existing model items, laneKindSuggestion, deckRead, lanes/cases that would be produced, config, and options. Combined with its usage and permission notes, it gives an agent enough to call and interpret the tool correctly.

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 100%, so most parameter meaning is already documented. The description still adds cross-parameter semantics: it says the inputs mirror cs454_moving_loads, that codeChange and unitSwitch only change which blockers are listed, and that config can be passed back as configFile.

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 opens with a specific read-only purpose and distinguishes the tool from the write sibling by saying to call it before cs454_moving_loads to preview what the Moving Load Wizard would do. It also enumerates concrete return content, making the tool's scope clear 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 Guidelines5/5

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

It explicitly says when to use the tool: before cs454_moving_loads. It also explains that it takes the same inputs as the write tool and that codeChange/unitSwitch only affect listed blockers here, which removes ambiguity about why a read tool accepts write-related permissions.

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