Skip to main content
Glama

MIDAS CIVIL NX tools (MIDAS IT Europe)

Model to IFC — export the model to IFC4 / IFC4.3

model_to_ifc
Read-only

Exports the open CIVIL NX model to IFC with the Model to IFC plugin: real section outlines with voids, smooth tapers, tendons, composite deck slabs, materials, structure groups and stages; in IFC4.3 also the bridge structure (deck, piers, abutments, bearings, alignment); optionally the structural analysis model with loads, combinations, support reactions, and — for the series named in resultSeries — node displacements and member/plate forces; optionally a second file of the deformed shape for one load case or combination. Only reads the model. Returns download links (never the file inline) and the exporter's report (sections, volumes, bridge parts, checks). Results are read on demand and can take long on big models (one live model: 40 s for all displacements), which is why this runs as a job.

Input Schema

NameRequiredDescriptionDefault
nameNoFile / model name (default: the model's project name).
loadsNoLoad cases, self-weight, nodal/beam/pressure loads and combinations (with analysis).
georefNo{crs (e.g. EPSG:27700), eastings, northings, height, rotation (deg), scale}: IfcMapConversion. Omitted = none.
groupsNo
schemaNoIFC4: Revit, Navisworks, Tekla, Solibri. IFC4X3: the bridge model (IfcBridge parts, bearings, alignment).IFC4
stagesNoConstruction stages as groups.
coloursNo
tendonsNoTendons drawn at their duct diameter.
analysisNoInclude the structural analysis model (nodes, supports, members, links).
deformedNo{series, scale}: also write the deformed shape for one load case or combination as its own IFC (scale omitted = automatic, the largest movement drawn at about 5% of the bridge's size).
joinDeckNoJoin side-by-side girders' slab strips into one continuous deck.
reactionsNoSupport reactions for every analysed series (with analysis; needs an analysed model).
plateForcesNoWith resultSeries: plate forces.
memberForcesNoWith resultSeries: beam forces.
resultSeriesNoLoad cases / combinations (exact names) whose results to add: node displacements and member and plate forces. None by default — they multiply by elements × points × series.
startStationNoChainage at the start of the deck, m.
displacementsNoWith resultSeries: node displacements.
separateSlabsNoA composite section's deck slab as its own slab.
classificationNo{name, edition, codes: {<role>: {code, title}}} e.g. Uniclass codes per role (girder, deck slab, pier stem, pier cap, abutment wall, pile, bearing, tendon…).
skipWeightlessNoLeave out weightless (dummy) members; cables, piles and members named NoSW are kept.
linearPlacementNoIFC4.3 only: place members along the alignment (IfcLinearPlacement).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description states that it only reads the model, returns download links rather than inline files, includes the exporter report, and runs as a job because large models can take a long time. These are operationally important details an agent would otherwise have to infer.

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 front-loaded and dense with relevant information, which suits a complex export tool. The long semicolon-separated sentence is slightly harder to scan but does not waste space on repetition.

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?

For a 21-parameter export with no output schema, the description covers purpose, schema choice, optional analysis content, return format, job behavior, and runtime caveats. An agent has enough information to decide whether and how to call it.

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 coverage is already 90%, so most parameter meaning is carried by structured fields. The description adds useful context around resultSeries, deformed output, and IFC4.3 bridge content, but it does not meaningfully explain many of the 21 parameters beyond what the schema already provides.

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 begins with a specific verb and resource: exports the open CIVIL NX model to IFC via the Model to IFC plugin. It clearly distinguishes this from unrelated siblings by being an IFC export, not a DXF or report export.

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?

The description makes the IFC4 vs IFC4.3 choice explicit and explains what each schema adds, while also clarifying that analysis results and deformed-shape output are optional. It does not name sibling alternatives such as model_to_dxf, but the intended use case is still clear.

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