Skip to main content
Glama
Sign In

MIDAS CIVIL NX tools (MIDAS IT Europe)

by com.midasiteurope
OverviewDiscussionsAdmin

EN 1991-2 notional lanes for a carriageway

ec_lane_layout
Read-only

Lays out EN 1991-2 lanes on a carriageway cross-section with the Eurocode - Moving Load Wizard's own layout engine: Table 4.1 notional lanes and the remaining area, footways, the LM2 axle lane, the LM4 crowd lane, an LM3 special vehicle route and rail tracks, as the chosen loading needs, with each lane's role. Needs no model.

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

Input Schema

NameRequiredDescriptionDefault
lanesNoLane options: prefix (default EC), packing, wheelSpace, optimiseNotional, lm2Manual / lm2Centre, sv / svCentre / svWidth (LM3 route), tracks { tracks, firstTrack, spacing, gauge }, userLanes.
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…
sectionNoCross-section, m: width (carriageway), kerbOffset, footways, verges, central reserve.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations only give readOnlyHint=true and openWorldHint=false; the description adds that the layout comes from the plugin's own layout engine (so results may differ from other layout tools) and that it operates without an open model, which is real prerequisite context. It also signals the response carries 'each lane's role', though it does not say where the layout is returned or stored.

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?

One dense sentence that front-loads the action and resource, then enumerates outputs, closing with the key constraint 'Needs no model'. No filler, though the long comma-separated list makes it slightly run-on.

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 three loosely-typed nested objects, zero required parameters, and no output schema, the description does the important work: it names the lane categories the call can generate and states that no model is needed. What remains unstated is whether the layout is returned as data, previewed, or persisted for later tools.

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

Parameters3/5

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

Schema description coverage is 100% and the nested object descriptions already document prefix, packing, wheelSpace, lm2*, sv*, tracks, and the loading model options. The description mainly restates those concepts (LM2 axle lane, LM4 crowd lane, LM3 route, rail tracks) rather than adding syntax, defaults, or interaction rules beyond the schema — baseline 3 is appropriate.

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?

Specific verb and resource: 'Lays out EN 1991-2 lanes on a carriageway cross-section', followed by an enumeration of the lane types produced (Table 4.1 notional lanes, remaining area, footways, LM2 axle lane, LM4 crowd lane, LM3 route, rail tracks). It distinguishes itself implicitly from cs454_lane_layout by naming the Eurocode/Moving Load Wizard engine, though it never names the sibling explicitly.

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?

Usage is only implied: the lanes are produced 'as the chosen loading needs', and 'Needs no model' is a useful prerequisite note. There is no explicit statement of when to choose this over cs454_lane_layout or how it relates to ec_moving_loads / ec_combinations_apply, so the agent must infer routing.

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

All MIDAS CIVIL NX tools (MIDAS IT Europe) toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources