Skip to main content
Glama

MIDAS CIVIL NX tools (MIDAS IT Europe)

Beam to Plate — convert beams into a plate/solid mesh

b2p_convert
Destructive

Converts beam elements into a plate (or solid) mesh of their cross-section with the Beam to Plate plugin's own engine (1.0.6): every section CIVIL NX gives geometry for (rolled/fabricated steel, PSC, boxes, composite, tapered groups, VALUE, catalogue), solid concrete sections as a grid of plates or as solids, exact beam loads / nodal loads / temperatures moved onto the mesh, haunches, diaphragms, deck slabs joined, rigid links to whatever else meets the beam's nodes (staged per construction stage), virtual beams per row of plates, groups and composite casting stages carried across. Previews by default (totals, volume check, per-section verdict, notes, what is left behind such as tendons or lanes, problems, planHash) and writes nothing. With apply: true and confirmPlanHash it re-reads the model, refuses if the plan changed, and writes the plugin's way: nodes, thicknesses and elements written and read back, then links, loads, groups, stages, virtual beams, and only then the source beams deleted (deleteSourceBeams); a write that fails part way is rolled back by the plugin. The run is recorded for b2p_undo. Lengths are in the model's unit. Use b2p_survey first. Runs as a background job on the website (poll job_status).

Input Schema

NameRequiredDescriptionDefault
applyNoWrite to CIVIL NX. Only after the user approved the preview.
modelNoconvert = plates/solids along the member; slice = a transverse slice of each section meshed in its own plane (beams kept, nothing linked or loaded).convert
facetsNoFacets per circle for round sections.
groupsNoEvery beam in these structure groups.
loadAtNoWhere a converted load lands: exactly where it acts; on the section centreline; spread over the section; spread over the deck top.exact
meshAsNoPer-section override of the suggestion, {sectionId: 'plate'|'solid'}.
linkAllNoRigid-link every member end, not only where something else attaches.
longSizeNoMesh size along the member (default 0.5 m), in the model's length unit (b2p_survey reports it).
sectionsNoEvery beam of these section ids.
calibrateNoAdjust plate thicknesses so the mesh has the section's own A, centroid, Iyy, Izz: where the shape is idealised (generic), every section, or never.generic
groupNameNoStructure group for the whole mesh ('' for none).B2P mesh
joinDecksNoJoin neighbouring girders' deck slabs.
loadFloorNoIgnore nodal loads under this, in the model's force unit (default 0.01 kN); totals are kept.
materialsNoMaterial per composite part, {sectionId: {part: materialId}} (b2p_survey lists each section's materialSlots); default: from the CS data or the beam's own.
solidModeNoauto = each section as the plugin suggests (solid for compact concrete, plates for thin walls); plate; solid.auto
transSizeNoMesh size across the section (default 0.25 m), in the model's length unit (b2p_survey reports it).
deckPlatesNoDeck plates (plugin 1.0.6): follow = along the slab's mid-thickness, as before; straight = every top-slab node on one line under the top surface, each thicker plate (tapering cantilever, haunches) offset to its own concrete through the plate offset, so area, centroid and second moments are kept; webs run on to the deck line.follow
diaphragmsNoFill compact diaphragm segments of a box run with plates (plate mode).
elementIdsNoBeam element ids: "101-118, 205" or [101, 102].
sliceAtPctNomodel 'slice': where along each member, %.
sliceWidthNomodel 'slice': the slice width = plate thickness (default 1 m), in the model's length unit (b2p_survey reports it).
solidPlatesNoHow a solid (concrete) section meshed as PLATES is idealised: grid of plates over the real section; thin plates round the outline; one plate per wall.grid
convertLoadsNoMove beam loads, nodal loads on the beams' nodes and element temperatures onto the plates.
virtualBeamsNoOne virtual beam per row of plates, so results read as beam forces.
boundaryGroupNoBoundary group for the rigid links (one per stage in a staged model).B2P links
acceptSectionsNoSection ids to convert although their check failed (the window's 'Convert anyway'). Only with the user's agreement.
mergeToleranceNoNode merge tolerance (default 0.0001 m), in the model's length unit (b2p_survey reports it).
confirmPlanHashNoplanHash from the approved preview; the write is refused if the plan differs.
deleteOrphanNodesNoRemove the beams' own nodes that nothing else uses once they are deleted.
deleteSourceBeamsNoDESTRUCTIVE: delete the converted beams after the mesh is written and read back (b2p_undo puts them back). Never deleted for a slice.
useCivilSelectionNoThe elements selected in CIVIL NX right now.
reuseExistingNodesNoUse a model node already at a mesh point instead of a new one.
thicknessGroupingPctNoPlates within this % share one thickness record.
transverseStiffenersNoAdd transverse web stiffeners (CIVIL NX holds none): h outstand, b thickness, spacing along the girder, side, one at each end.
includeUncountedStiffenersNoAlso mesh stiffeners CIVIL NX leaves out of the section (the 'C' box unticked).

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?

Goes far beyond the annotations: discloses that preview writes nothing, that a write re-reads the model and refuses if the planHash changed, the exact write order, rollback on partial failure, the destructive deleteSourceBeams behaviour (with undo path), and that it runs as a background job requiring job_status polling. This is exactly the extra context annotations can't carry.

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

Conciseness3/5

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

Front-loaded with the core action, but the body is a dense run-on paragraph listing many behaviours with little structural separation, making it harder to scan than it needs to be. The content largely earns its place, but the presentation hurts readability.

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?

For a 35-parameter, destructive, job-based tool with no output schema, the description covers the write lifecycle, safety, rollback, background-job polling, and the contents of the preview. Return-value detail is partially covered via the preview contents; a little more on the write result shape would complete it.

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 the baseline is 3; the description still adds value by tying apply and confirmPlanHash together (write refused if plan differs) and flagging deleteSourceBeams as destructive and skipped for slices. It doesn't explain every parameter, but the schema already does that work.

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 specific verb, resource, and engine ('Converts beam elements into a plate (or solid) mesh of their cross-section with the Beam to Plate plugin's own engine'), enumerates the section types handled, and is clearly distinct from b2p_survey (survey) and b2p_undo (undo). An agent can identify exactly what this tool does 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 Guidelines4/5

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

Explicitly states the workflow: previews by default and writes nothing, write only with apply + confirmPlanHash, 'Use b2p_survey first', and the run is recorded for b2p_undo. The sequencing is clear, though it never states when NOT to use it or names a competing alternative beyond the prerequisite tools.

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