midas-nx-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MIDAS_TIMEOUT | No | Seconds per call. Short on purpose: a dialog in NX blocks the API. | 20 |
| MIDAS_MAX_ROWS | No | Most rows one call returns; the rest are counted, not sent. | 200 |
| MIDAS_OUTPUT_DIR | No | Where NX writes captures. Must exist. | C:/temp |
| MIDAS_MAPI_KEY_GEN | No | Gen NX API key. Needed for product="gen". | |
| MIDAS_MAPI_KEY_CIVIL | No | Civil NX API key. Needed for product="civil". | |
| MIDAS_ANALYSIS_TIMEOUT | No | Seconds 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
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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
| Name | Description |
|---|---|
| check_reactions | Sum the support reactions and compare them with the model's weight and loads. |
| check_story_drift | Story drift ratios against an allowable value (Gen NX). |
| review_model | A first look at a model: size, units, properties, supports and loads. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 16 tools
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.
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.
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.
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.