Skip to main content
Glama
midas-nx-mcp

midas-nx-mcp

by Dennis5882

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
MIDAS_TIMEOUTNoSeconds per call. Short on purpose: a dialog in NX blocks the API.20
MIDAS_MAX_ROWSNoMost rows one call returns; the rest are counted, not sent.200
MIDAS_OUTPUT_DIRNoWhere NX writes captures. Must exist.C:/temp
MIDAS_MAPI_KEY_GENNoGen NX API key. Needed for product="gen".
MIDAS_MAPI_KEY_CIVILNoCivil NX API key. Needed for product="civil".
MIDAS_ANALYSIS_TIMEOUTNoSeconds for run_analysis only.300

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

Access to the model open in MIDAS Gen NX (product='gen') or Civil NX (product='civil'). Start with check_connection. Use list_tables and describe_table before read_table; list_result_tables before result_table (it says what each category of table needs in NX first). capture_view shows the NX model window as an image; show_result first sets a result graphic (reactions, displacement, deformed shape, beam diagram, plate forces) and then captures it. run_analysis, save_copy, write_records, delete_records and generate_load_combinations change the model or its file: call them first without confirm_token, show the preview to the user, and apply with the returned confirm_token only after the user agrees. If a call times out, ask the user to look at the NX window for an open dialog instead of retrying.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
check_connectionA

Check whether the given MIDAS NX product is reachable through the Open API.

Returns the connection status and the program name. A blocked NX session (an open dialog) can still report "connected"; a later read then times out.

list_tablesA

List the tables this server can read: /db model data (e.g. "NODE") and /DESIGN design parameters (e.g. "DESIGN/STEEL/DSTL", the steel design code).

product: keep only tables that product supports. search: case-insensitive text matched against the table name and title, e.g. "load", "section", "design". No NX call is made.

describe_tableA

The NX server's own field schema for one /db table (GET /info/db/).

Call this before read_table to learn what each field means.

read_tableA

Records of one table in the open model, e.g. table="NODE" or "DESIGN/STEEL/DSTL".

ids: return only these record ids. limit: at most this many records (capped by the server's MIDAS_MAX_ROWS). The reply says how many records the table holds in all, so a truncated answer is never mistaken for the whole table.

model_summaryB

Record counts of the main tables (nodes, elements, materials, sections, thicknesses, static load cases), plus the model's unit system.

A table that fails to read is reported with its error, the rest still count.

read_model_infoA

Model-wide information NX computes, not stored in a table.

what: "project_status" (counts of model and load data), "section_properties" (computed area, inertia, ... per section id), "story_check_parameter" and "story_irregularity_parameter" (Gen only), or "selection" (what the user has selected in the NX window now). Entries keyed by id are capped like read_table.

list_result_tablesA

List the result/report table types result_table accepts, by category.

Categories: "model" (mass, weights, loads, sections, supports; no analysis needed), "analysis" (reactions, displacements, member forces, stresses, modes), "story" (Gen: story drift, displacement, shear, stability, irregularity checks), "design" (design member forces). Each category says what NX needs before its tables have data.

search: case-insensitive text matched against the type and its name, e.g. "reaction", "beam", "drift". No NX call is made.

result_tableA

One result table from the open model (POST /post/TABLE, nothing exported).

table_type: from list_result_tables. Common ones: "REACTIONG" (support reactions), "DISPLACEMENTG" (nodal displacements), "BEAMFORCE" (beam/column member forces), "PLATEFORCEL" (plate forces), "EIGENVALUEMODE" (periods and modes), "STORY_MASS" / "STORYWEIGHT" (story mass and weight, no analysis needed), "STORY_DRIFT_X" / "STORY_DRIFT_Y" and "STORY_SHEAR_FOR_RS" (Gen story checks), "BEAMDESIGNFORCES" / "COLUMNDESIGNFORCES" (design forces). load_cases: names with a type suffix, e.g. ["DL(ST)", "COMB1(CB)"]; the model's load cases are in read_table("STLD"). components: column names to keep. keys: node or element ids to restrict to. Rows beyond limit (capped by MIDAS_MAX_ROWS) are counted, not returned.

capture_viewA

A PNG of the model window as NX shows it now (POST /view/CAPTURE).

Shows the current view: viewpoint, active elements and result display are whatever the user has set in NX; this tool does not change them. width and height are in pixels (each at most 2000); leave them out for the window size.

show_resultA

Show an analysis result in the NX window and return it as a PNG.

Like picking a result under Results in NX (POST /view/RESULTGRAPHIC, then /view/CAPTURE): the window keeps showing it afterwards. The model and its results are not changed. Needs the analysis run in NX.

result and its components (default first): "reactions" FZ, FX, FY, MX, MY, MZ (values are always shown) "displacement" DXYZ, DX, DY, DZ (contour) "deformed_shape" DXYZ, DX, DY, DZ (deformed over undeformed) "beam_diagram" My, Mz, Fx (axial), Fy, Fz (shear), Mx (torsion) "plate_forces" Mxx, Myy, Mxy, Fxx, Fyy, Fxy load_case: a name from read_table("STLD"), e.g. "DL"; a combination with its type suffix as result_table takes it, e.g. "gLCB1(CB)", "cLCB1(CBC)". show_values writes the numbers on the picture; deform_scale scales the deformed shape (NX's own scale when left out). width/height: pixels, at most 2000 each.

run_analysisA

Run the analysis in NX (POST /doc/ANAL). Two steps: preview, then apply.

NX saves the open document over its file before analysing (leaving a .bak), unsaved changes included, even when it then refuses the analysis. So this needs a document that has been saved before, seen in the NX window title on this PC; a new, never-saved document would raise a Save As dialog that blocks NX, and is refused here.

save_copyA

Save the model as a new file in the output folder (POST /doc/SAVEAS). Two steps: preview, then apply.

Like Save As in NX: from then on NX works on the copy, so the window, later saves and run_analysis use it, and the original file stays as it was last saved. The name is generated (mcp-save--, .mgbx for Gen, .mcbz for Civil). Also the way to give a never-saved document a file, which run_analysis needs.

write_recordsA

Create or update records in one /db or /DESIGN table. Two steps: preview, then apply.

records: {id: fields}, e.g. {"13": {"X": 0, "Y": 0, "Z": 6.4}} for NODE; see describe_table for the fields (or read_table, for /DESIGN). "create" refuses ids that exist, "update" ids that do not, except record "1" of the one-record /DESIGN tables DCO, DCTL, LLRF, LMRR and SRDF, which have no create and are made by their first update. At most 50 records. After applying, the table is read back and what actually changed is returned; some tables store a new record under an id of their own choosing, so trust "added", not the ids you sent; the preview says when a table is known to do that. A record naming one that does not exist (an element's material, section, thickness or nodes, a load's load case or group, ...) is refused: NX would refuse it, store it pointing at nothing, or drop the value (midas-nx plan.validate). Any write discards the analysis results.

delete_recordsA

Delete records by id from one /db or /DESIGN table. Two steps: preview, then apply.

Only the listed ids, one DELETE per id; there is no way to empty a table here. Nodes still used by an element are refused (NX would delete the elements with them), and so are materials, sections and thicknesses still used by an element (NX would leave the elements pointing at nothing). The preview names the other records NX deletes or empties along with these: a load case's loads and combination entries, a node's nodal loads, supports and masses, an element's beam loads, end releases and pressure loads (midas-nx plan.validate). At most 50 ids. The table is read back afterwards: on some /DESIGN tables NX resets the record to defaults rather than removing it, or keeps it unchanged, and the result says which; records NX removed from other tables are counted.

apply_operationsA

Create, update and delete records in several tables at once, e.g. the materials, sections, nodes, elements, load cases and loads of a small model. Two steps: preview, then apply.

Each operation is what write_records or delete_records would take: table, action ("create", "update" or "delete"), and records ({id: fields}) or ids. The steps are run in midas-nx's dependency order (deletes first, then what is named before what names it), whatever order they are given in; the preview shows that order. The preview checks the whole batch first, with the records earlier steps create counted as existing: the same rules as write_records and delete_records. A UNIT change is not taken here. At most 20 operations and 200 records in all.

Applying runs the steps one by one and reads each table back. It stops at the first step that fails, changes nothing, or stores new records under other ids while a later step names that table; what was already applied stays (nothing is rolled back) and the result lists the steps done, the failed one, and the ones not run. Any change discards the analysis results.

generate_load_combinationsA

Have NX add its KDS design load combinations. Two steps: preview, then apply.

kind: "concrete" (KDS 41 20 : 2022, into LCOM-CONC), "steel" (KDS 41 30 : 2022, LCOM-STEEL) or "src" (KDS 41 SRC : 2022, LCOM-SRC). NX builds the combinations from the model's static load cases and their load types and appends them (cLCB1, cLCB2, ... for concrete); the existing ones stay. Gen NX only: Civil NX has no such command. After applying, the table is read back and the combinations NX added are returned. Any change discards the analysis results.

Prompts

Interactive templates invoked by user choice

NameDescription
check_reactionsSum the support reactions and compare them with the model's weight and loads.
check_story_driftStory drift ratios against an allowable value (Gen NX).
review_modelA first look at a model: size, units, properties, supports and loads.

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.7/5.0

Scored across 16 tools

Disambiguation4/5

Each tool targets a distinct surface: connection check, view capture, table CRUD, batch writes, model info, results, analysis, and save. The main soft spots are write_records/delete_records versus apply_operations (single-table vs multi-table batch) and model_summary versus read_model_info (counts vs computed data), but the descriptions make these boundaries clear. capture_view and show_result also overlap slightly in returning PNGs, though one shows the current window state and the other drives NX's result display.

Naming Consistency4/5

Nearly all tools use a consistent snake_case verb_noun pattern: list_tables, describe_table, read_table, write_records, delete_records, run_analysis, save_copy, show_result, capture_view. A few names drop the verb (model_summary, result_table), which are minor deviations in an otherwise predictable scheme.

Tool Count4/5

Sixteen tools is at the upper edge of comfortable, but each maps to a distinct step in the NX workflow (connect, inspect, read, write, analyze, visualize, save). Nothing feels redundant enough to remove, though grouping model_summary under read_model_info could trim one.

Completeness4/5

The surface covers connection checks, schema discovery, table listing/reading, single and batch writes, analysis execution, result listing/reading/visualization, and save-as, which is solid lifecycle coverage. Minor gaps remain: no unit-system change tool, no way to empty a table (explicitly noted), and no rollback for partially applied batches.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues