Skip to main content
Glama

MIDAS CIVIL NX tools (MIDAS IT Europe)

Advanced DXF Importer — import into CIVIL NX

dxf_import
Destructive

Imports a DXF into the open CIVIL NX model with the Advanced DXF Importer plugin's engine: the same parse, layer mapping, clean-up and write as the plugin. Nodes and elements get new ids above the model's (existing rows are never overwritten); each layer's structure group is created or added to; blank properties become the plugin's DXF default material (C40/50), section (SB 500x300) and thickness (250), created or reused by name. Previews by default (writes nothing): the plan with id ranges, groups, default properties and any unit switch. To write, call again with the same inputs, apply: true and confirmPlanHash; the model is read again and the write refused if the plan changed. The write creates a master group DXF_ # first, then the unit change, properties, nodes, elements and groups, then reads everything back to verify. The import journal is recorded so dxf_import_undo can remove exactly what it created, even after a partial failure. Inputs as for dxf_inspect, plus mergeExisting.

Input Schema

NameRequiredDescriptionDefault
urlNoAn https address the DXF is downloaded from, up to 25 MB (public hosts only on the website).
applyNoWrite to CIVIL NX. Only after the user approved the preview.
planeNoFlat drawings only: XY → plan (global XY), XZ → elevation, YZ → side elevation.XY
originNoMove the drawing: {mode:'none'} (default), {mode:'min'} (drawing minimum to 0,0,0), or {mode:'user', x, y, z} (metres, subtracted). Use it for OS-grid / site coordinates.
dxfTextNoThe DXF file's text (ASCII DXF), up to 4 MB. Use dxfBase64 for a binary DXF or an R12 file with non-ASCII layer names (the bytes then keep their code page).
mappingNoLayer mapping in the plugin's preset format (the file Save mapping writes). rules apply in order, first match wins, * and ? wildcards, case-insensitive; layers are exact names and override the rules. Per class (linear = lines/polylines/arcs/splines, face = 3DFACE/polyface/mesh, point): as BEAM|TRUSS|IGNORE (linear), PLATE|IGNORE (face), NODE|IGNORE (point); material, section (linear) or thickness (face) as an id, a name or {id,name} (omitted = the DXF default property, created on import); beta (deg); group ('{layer}' = the layer name); split (split at intersections); plate THICK|THIN; include false drops a layer. Example: {rules:[{layer:'*GIRDER*', class:'linear', as:'BEAM', material:'C40/50', section:'G1', group:'Girders'}, {layer:'DIM*', include:false}], layers:{SLAB:{face:{as:'PLATE', thickness:'Slab 250'}}}}
arcChordNoInstead of arcSegments: largest chord deviation, mm.
fileNameNoName of the drawing (default: from the URL or path, else drawing.dxf). It names the import's master group DXF_<name> #<token>.
filePathNoLocal server only: a path to the DXF on this machine, up to 50 MB.
dxfBase64NoThe DXF file's bytes, base64, up to 4 MB decoded.
arcSegmentsNoArcs/circles/splines: segments per full circle.
planeOffsetNoFlat drawings only: metres added along the axis the drawing's normal maps to.
drawingUnitsNoThe drawing's units when it does not record them ($INSUNITS; R12 files never do), or to override them.
mergeExistingNoReuse existing model nodes within the merge tolerance instead of creating new ones there (reused nodes join no group).
mergeToleranceNoNode merge tolerance, mm (clean-up).
confirmPlanHashNoplanHash from the approved preview; the write is refused if the plan differs.
matchModelUnitsNoAs in the plugin: switch the CIVIL NX model's length unit to the drawing's (mm/cm/m/in/ft) before writing. DESTRUCTIVE when it changes the unit — the preview says so; undo switches it back. false = keep the model's unit and convert the coordinates.
ignoreAnnotationLayersNoUntick layers that are empty or mostly annotation (TEXT, DIMENSION, HATCH…), as the plugin's bulk action does.

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?

Annotations flag destructive and open-world, and the description backs that with concrete consequences: new ids only, existing rows never overwritten, default material/section/thickness created or reused, a master group DXF_<file> #<token> created, a read-back verification, and a journal enabling exact undo even after partial failure. The write ordering and the destructive unit switch are disclosed, so the agent knows exactly what state is touched.

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 behavior, the preview-by-default contract, and the write sequencing are front-loaded before secondary details, and every sentence carries operational content. It is dense for a several-sentence paragraph but not padded.

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?

No output schema exists, yet the description explains what the preview returns (plan with id ranges, groups, default properties, any unit switch) and what the write does end to end. For an 18-parameter, nested-object mutation tool this covers the safety contract, verification and rollback path an agent needs.

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%, so the parameter documentation burden is already met by the schema (including the detailed mapping example and the destructive matchModelUnits note). The description adds only a pointer that inputs mirror dxf_inspect plus mergeExisting, without new semantics, so baseline 3 applies.

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?

States a concrete verb and resource ('Imports a DXF into the open CIVIL NX model') and names the engine (Advanced DXF Importer plugin). It also draws the boundary against siblings: it references dxf_inspect for inputs and dxf_import_undo for reversal, so the agent can tell what this tool does and does not cover.

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 two-step workflow is explicit: preview by default (writes nothing), then call again with the same inputs plus apply:true and confirmPlanHash, with the write refused if the plan changed. What is not resolved is when to use this tool's preview versus dxf_inspect, which the description only cross-references by 'Inputs as for dxf_inspect' without saying which to reach for first.

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