labview-mcp

An MCP server that lets AI coding agents — Claude Code, Codex, Cursor, and others — read, render, run, create, and edit NI LabVIEW VIs.

LabVIEW source code is a binary, graphical format. Text-based coding agents can't open a .vi file. labview-mcp acts as the agent's eyes and hands: it drives your installed LabVIEW over its ActiveX server and returns what the agent needs as text, images, and values.

Status: v0.31.0. Reading and running work on any VI. Creating VIs supports controls, constants, functions, subVIs, For/While loops, shift registers (also stacked), and case structures, nested to any depth, and user interfaces: front-panel styles (buttons, LEDs, knobs, gauges, charts), event structures (control and VI events, Timeout, event data), and Property and Invoke Nodes. Any existing VI can be read as a graph (vi_dump) and changed in place (vi_edit: remove, replace, and add code, including inside existing loops and case frames). Projects and builds: the agent can put VIs in a project, add application (EXE), packed-library, and source-distribution build specs, build them, and mass compile folders.

What the agent can do

Example prompts:

• "Explain what Main.vi does, case by case."

• "Which subVIs write to the Config global?"

• "Run Scale.vi with gain 2.5 and check out matches my Python reference."

• "Test Stats.vi with an empty array, one value, and 1000 random values."

• "Make a VI that takes an array of readings and returns their sum and mean, then test it."

• "In Scale.vi, also output Gain squared, then run it."

• "Make a panel with a knob, a gauge, a Double button and a STOP button."

• "Put Main.vi in a project, build it as Logger.exe, and check the EXE runs."

vi_dump output (excerpt)

{"nodes": [{"id": "control_2", "kind": "control", "label": "data", "type": "dbl[]", "conpane_index": 11},
           {"id": "divide_7", "kind": "function", "function": "Divide"},
           {"id": "case_structure_4", "kind": "case", "frames": [{"index": 0, "values": ["apple"]},
                                                                  {"index": 2, "values": [], "default": true}]}],
 "wires": [{"from": "add_array_elements_5.sum", "to": ["divide_7.x"], "type": "dbl"},
           {"from": "tunnel_9.outer", "to": ["indicator_3"], "type": "dbl"}]}

vi_dump reads a diagram in one of two ways and reports which one it used in "source":

• "dfir" uses LabVIEW's compiler export. It includes constant values, data types, and case values, but LabVIEW refuses it for some VIs, for example ones with certain front-panel controls.

• "scan" walks every diagram object with VI Scripting. It works on any VI that opens, including broken VIs and VIs with property nodes or event structures.

Both ways report constant values, including arrays and clusters.

On a random sample of 50 NI example VIs, every VI was read. Password-protected VIs are refused, by design.

vi_edit spec

It takes the vi_create spec plus two keys:

• "remove" lists vi_dump node ids to delete, together with their wires.

• "existing" names objects already in the VI: a front-panel label, {"node": id} for any node, {"node": loop_id, "functions": [...]} to add code inside a loop, or {"node": case_id, "cases": {"1": {...}}} to add code inside a case frame.

This spec replaces out = x + 1 with out = x * 3:

{"remove":    ["increment_4"],
 "existing":  {"x": "x", "o": "out"},
 "constants": [{"name": "k", "type": "dbl", "value": 3}],
 "functions": [{"name": "m", "function": "Multiply"}],
 "wires":     [["x", "m.x"], ["k", "m.y"], ["m.x*y", "o"]]}

Small changes need no new code:

Structural edits go in "existing":

• {"node": "for_loop_3", "shift_registers": ["acc"]} adds shift registers to a loop. Wire acc.left and acc.right as in vi_create.

• {"node": "case_structure_5", "remove_cases": [2], "add_cases": [...]} removes and adds case frames. Each new frame has a "value" (a number, a range like "7..9", or a string, as the selector takes), optional "default": true, its contents, and "outputs" that give its value for existing output tunnels by vi_dump tunnel id: {"value": 5, "outputs": {"tunnel_9": "five"}}.

Objects are matched by their LabVIEW UID, which vi_dump reports. Edits therefore hit exactly the node you named, even in a VI with many identical functions.

vi_create spec

{
  "controls":   [{"name": "x", "type": "dbl", "default": 1.5},
                 {"name": "readings", "type": "dbl[]"}],
  "indicators": [{"name": "y", "type": "dbl"}, {"name": "total", "type": "dbl"}],
  "constants":  [{"name": "k", "type": "dbl", "value": 2.5}],
  "functions":  [{"name": "add", "function": "Add"},
                 {"name": "sum", "function": "Add Array Elements"}],
  "subvis":     [],
  "wires":      [["x", "add.x"], ["k", "add.y"], ["add.x+y", "y"],
                 ["readings", "sum.numeric array"], ["sum.sum", "total"]]
}

Loops and case structures go in "structures" and can hold their own constants, functions, subVIs, and structures. This spec sums 0..n-1 with a shift register:

{
  "controls":   [{"name": "n", "type": "i32", "default": 5}],
  "indicators": [{"name": "total", "type": "i32"}],
  "constants":  [{"name": "zero", "type": "i32", "value": 0}],
  "structures": [{"name": "L", "type": "for_loop", "shift_registers": ["acc"],
                  "functions": [{"name": "a", "function": "Add"}]}],
  "wires": [["n", "L.N"], ["zero", "acc.left"], ["acc.left", "a.x"], ["L.i", "a.y"],
            ["a.x+y", "acc.right"], ["acc.right", "total"]]
}

A shift register is stacked by wiring its older values: acc.left[2] is the value from two iterations back, acc.left[3] from three, and so on. Wire an initial value into each one from outside the loop, as for acc.left.

Some palette functions have no name in LabVIEW's scripting, such as Merge Errors, First Call?, To Time Stamp, the TDMS and newer file functions, and Shared Variable functions. vi_create places them by their palette name instead (a stand-in node replaced with GObject.Replace) and wires them by terminal reference, outside event structures. Merge Errors takes "size", the number of inputs (m.error in[1], m.error in[2], ...).

Growable functions take "size". For example, Concatenate Strings with "size": 3 is wired as cat.element[1..3]. function_terminals(name, size) shows the terminals a grown node has. A case wired to an error cluster gets "No Error" and "Error" frames.

Wire straight across structure borders and LabVIEW adds the tunnels. For Loops build arrays from values that leave them, and While Loops pass out the last value. Each frame of a case wires its result to an output tunnel.

Connector pane: every control and indicator is wired to the standard 4x2x2x4 connector pane, so a generated VI works as a subVI right away. Inputs go on the left, outputs on the right, and error clusters on the bottom corners, as in NI's own VIs. To pin a slot, use "connector": "left3"; to leave a terminal unwired, use "connector": false. The tool reports the resulting layout.

Enums and state machines

{"enum": ["Init", "Add", "Done"]} is an enum type. Values, defaults, and vi_run inputs and outputs use the item names. A case on an enum has one frame per item, such as {"value": "Init", ...}.

A state machine is built from parts that already exist in the spec:

• a while loop with a shift register that holds the state;

• a case structure on the state, with one frame per state;

• in each frame, the next state wired to an output tunnel that feeds the shift register.

To pass a value through a frame unchanged, give the frame "pass": [["acc.left", "t"]], where the pair is a source and an output tunnel. tests/live_vi_create.py (state_machine) has a complete example that runs Init → Add ×n → Done.

Queues: producer/consumer and queued message handlers

Queue functions are ordinary palette functions:

Loops placed side by side run in parallel and share the queue wire. tests/live_vi_create.py has two complete examples:

• producer_consumer: a For Loop enqueues numbers and a While Loop sums them.

• qmh: a queued message handler. Button events in a UI loop enqueue enum messages, and a second loop handles each message in a case until Exit.

User interfaces

"style" on a control or indicator replaces it with the Controls-palette object of that name, keeping its label, terminal and wires: "Stop Button", "OK Button", "Round LED", "Vertical Toggle Switch" for booleans, "Knob", "Gauge", "Thermometer", "Waveform Chart" for numbers.

An event structure runs one frame per user event. This spec is a panel whose Double it button sets y = 2x and whose STOP button ends the loop:

{
  "controls":   [{"name": "stop", "type": "bool", "label": "STOP", "style": "Stop Button"},
                 {"name": "go", "type": "bool", "label": "Double it", "style": "OK Button"},
                 {"name": "x", "type": "dbl", "style": "Knob"}],
  "indicators": [{"name": "y", "type": "dbl", "style": "Gauge"}],
  "structures": [{"name": "W", "type": "while_loop", "structures": [
                   {"name": "E", "type": "event", "events": [
                     {"control": "stop"},
                     {"control": "go", "functions": [{"name": "m", "function": "Multiply"}],
                      "constants": [{"name": "k", "type": "dbl", "value": 2}]}]}]}],
  "wires": [["stop", "W.stop"], ["x", "m.x"], ["k", "m.y"], ["m.x*y", "y"]]
}

The result follows NI's event-handler pattern:

• The STOP button is read in its own Value Change frame, which stops the loop.

• x and y are used only by the Double it frame, so their terminals are placed in that frame. The knob is therefore read when the button is pressed, not once before the loop.

To test a UI, give vi_run the steps a user would take:

"actions": [{"set": {"x": 21}}, {"click": "Double it"}, {"read": ["y"]}, {"click": "STOP"}]

• click presses a button, including a latched one such as STOP.

• set changes controls.

• Both fire the controls' Value Change events, as a real click or edit would.

• read records values while the VI runs.

• wait pauses for the given number of seconds.

The result lists each step. Here it reads y = 42 and then the VI stops by itself.

"event" defaults to "Value Change". Other control events include "Mouse Down", "Mouse Up", "Mouse Enter", "Mouse Leave", and "Key Down". Code in a frame can be wired to its own frame and to anything outside the event structure, including shift registers and a surrounding case's output tunnels. One frame can handle several events: "more": [{"control": "b"}, {"event": "Panel Close"}]. A value a frame passes on unchanged, such as a state kept in a shift register, goes in that frame's "wires": {"control": "stop", "wires": [["state.left", "state.right"]]}. A case output tunnel that some frames leave unwired gives its default value there ("Use Default if Unwired"). Event structures are made by vi_create only, for now.

Events of the VI itself have no "control", and frames can use their event data:

{"name": "E", "type": "event", "events": [
  {"control": "stop"},
  {"control": "x", "data": "d"},
  {"event": "Timeout", "timeout": 50, "functions": [{"name": "inc", "function": "Increment"}]},
  {"event": "Panel Close?", "filter": "f", "constants": [{"name": "t", "type": "bool", "value": true}]}]}

with wires ["d.NewVal", "last"], ["W.i", "inc.x"], ["inc.x+1", "ticks"], ["t", "f.Discard?"].

• "data" names the frame's event data node. Wire its items by name, such as NewVal, OldVal, CtlRef, Coords, and Button. The node shows the items that are wired.

• "Timeout" runs when no other event arrives within "timeout" milliseconds. The constant is wired to the structure's hourglass terminal.

• Filter events end in ?. "filter" names their filter node, such as Discard? for "Panel Close?", which keeps the window open.

• Other VI events: "Panel Close", "Panel Resize", "Key Down", "Mouse Enter", and more.

Property and Invoke Nodes

"property_nodes": [{"name": "p", "control": "chart", "properties": ["Visible"], "write": true},
                   {"name": "a", "class": "Application", "properties": ["App.Version"]}],
"invoke_nodes":   [{"name": "i", "control": "x", "method": "Reinit To Dflt"}]

• Linked: "control" links a node to a front-panel object, like right-clicking it and choosing Create ▸ Property Node.

• Unlinked: "class" makes an unlinked node. Wire a reference to "p.reference"; Application needs none.

• Read or write: properties are read unless "write" is true or lists them.

• Wiring: wire nodes as "p.Visible", "i.<parameter>", "p.error in", and "p.error out". Chain the error wires to set the order of nodes.

• Names: use LabVIEW's short names, such as Visible, Value, DefVal, Disabled, and App.Version. lv_class_properties lists them for a class. If LabVIEW names a property's terminal differently, the wire is redirected to the right terminal.

• Nested properties: write them as LabVIEW shows them, such as Label.Text, Plot.Plot Color, or YScale.Multiplier, and wire them the same way ("p.Label.Text"). LabVIEW's scripting call refuses nested names, so they are set through the item's own (deprecated) Property setting, as NI suggests on its forum.

• Charts and other UI controls: a node linked to a chart, slide, or listbox needs that control's "style" ("Waveform Chart", "Vertical Fill Slide", "Listbox"), so the control has those properties.

• Placement: nodes work at the top level, in loops and cases, inside event frames, and in vi_edit.

Strings are stored in the Windows ANSI code page, as LabVIEW does, so characters outside it (for example é on Korean Windows) become the closest match.

Types: dbl sgl i8 i16 i32 i64 u8 u16 u32 u64 bool string path error, VI Server references ("ref:Control", "ref:VI", "ref:Boolean[]"), enums ({"enum": [...]}), arrays ("dbl[]", "i32[][]", or {"array": <type>, "dims": 1} for arrays of clusters), and clusters ({"cluster": [{"name": "gain", "type": "dbl"}, ...]}). Other types (waveform, picture, timestamp, class objects, typedefs, numbers with units) are copied from an existing VI: vi_dump gives such a control or constant a "flat" entry, and that entry ({"flat": "...", "data": "..."}) works as a type, with the original default value. Function terminals use the names shown in LabVIEW's Context Help; Unbundle By Name and Bundle By Name are wired by element name ("u.gain"). SubVI terminals use the subVI's control labels.

Projects and builds

{"path": "C:/work/Demo/Demo.lvproj",
 "files": ["C:/work/Demo/Main.vi"],
 "build_specs": [
   {"name": "Demo App", "type": "exe", "startup": ["C:/work/Demo/Main.vi"],
    "include": ["C:/work/Demo/Plugin.vi"], "file_name": "Demo.exe", "version": "1.2.0.0"},
   {"name": "Lib", "type": "ppl", "library": "C:/work/Demo/Tools.lvlib"},
   {"name": "Src", "type": "source", "include": ["C:/work/Demo/Main.vi"]}
 ]}

project_create takes this. project_build with build_spec="Demo App" then produces builds/Demo App/Demo.exe next to the project. LabVIEW creates the project, its items, and the empty build specs through its ActiveX Project interface. The build settings are the properties that LabVIEW itself writes for each spec type, filled into the saved project file. project_build calls NI's Application Builder API (AB_API_Simple/Build (path).vi), the same VI that LabVIEWCLI's ExecuteBuildSpec operation uses.

• Application Builder is included in LabVIEW Community Edition and in the Professional edition. A built EXE needs the matching LabVIEW Run-Time Engine on the machine that runs it.

• lv_mass_compile saves the VIs it compiles. It refuses folders inside the LabVIEW installation. Don't mass compile a copy of a library while LabVIEW holds the original: the two get cross-linked, and LabVIEW re-saves the original.

Related MCP server: SW_MCP

Requirements

• Windows with LabVIEW installed. Community Edition works for personal and non-commercial use.

• In LabVIEW, open Tools ▸ Options ▸ VI Server and enable ActiveX.

• Python ≥ 3.10.

• vi_create, vi_dump, and vi_edit use small helper VIs shipped in the package and saved in LabVIEW 2015 format, so they open in LabVIEW 2015 and later. They call scripting methods that an older LabVIEW might lack. In that case the tool reports which helper cannot run, and vi_dump falls back to its scan reader where it can.

Tested on LabVIEW 2026 Q3 (64-bit, English) under Korean Windows. Reports from other versions and languages are welcome.

Install

pip install git+https://github.com/shlim-t/labview-mcp
claude mcp add labview -s user -- python -m labview_mcp

Other MCP clients use the same command: python -m labview_mcp over stdio.

How it works

agent ──MCP/stdio──▶ labview-mcp ──ActiveX (COM)──▶ LabVIEW.exe
                                                   ├─ ExportVIStrings  → vi_text
                                                   ├─ PrintVIToHTML    → vi_snapshot
                                                   ├─ CalleesPaths     → vi_hierarchy
                                                   ├─ Set/Run/GetValue → vi_run
                                                   ├─ helper VIs       → vi_create, vi_edit
                                                   ├─ Project + AB API → project_*, lv_mass_compile
                                                   └─ helper VI        → vi_dump

• All COM calls run on a single dedicated thread.

• vi_snapshot temporarily changes LabVIEW's print options to render hidden frames. It always restores them afterwards.

• Read tools never modify or save VI files. vi_create only writes the new file you name, and it refuses to overwrite an existing file unless you pass overwrite=true.

• vi_edit copies the VI to .lvmcp-backup/ next to it before editing. It refuses to touch a VI with unsaved changes in LabVIEW. It reverts instead of saving if the edit breaks the VI or LabVIEW silently drops a requested wire.

• vi_create and vi_edit translate the spec into LabVIEW's internal diagram-scripting XML. Small helper VIs shipped in the package (vis/) run that script. The spec is validated in Python first, so malformed input never reaches LabVIEW.

• vi_dump runs LabVIEW's dataflow (DFIR) exporter through a helper VI and parses its output.

Safety

vi_run executes LabVIEW code on your machine. That code can drive real instruments, such as DAQ, power supplies, and motion stages. MCP clients ask for confirmation before each tool call, so review what you approve.

Roadmap

• vi_dump: block-diagram graph (nodes, wires, constants) as JSON.

• vi_edit: add code wired to an existing VI's controls and indicators, with backup and revert.

• vi_edit: remove and replace nodes; add code inside existing loops and case frames.

• vi_edit: rename controls, set constant and default values, retype numbers, cut and re-make wires.

• vi_edit: move objects, add and remove case frames, add shift registers to existing loops.

• vi_edit: wrap existing code in a loop or structure.

• vi_dump for any VI (scan fallback), including broken ones and VIs with property nodes and event structures.

• vi_diff: a semantic diff between two versions of a VI, for code review on binary files.

• Projects: create, add files and build specs (EXE, packed library, source distribution), build, mass compile.

• Installers, shared libraries (DLL), VI Analyzer, unit tests; creating libraries and classes.

• vi_create: new VIs with controls, constants, functions, subVIs, and wires.

• vi_create: For/While loops, shift registers, case structures (boolean, integer, string), nesting.

• vi_create: connector pane and error clusters, so generated VIs can call each other.

• vi_create: front-panel styles and event structures (control events) for user interfaces.

• Property and Invoke Nodes, linked to controls or of any VI Server class.

• lv_class_properties: a class's properties by name. Methods are not listed yet.

• Enums, enum cases, and state machines.

• Queues: producer/consumer and queued message handlers.

• Event structures: Timeout, VI events (Panel Close?), event data (NewVal, Coords) and filter nodes (Discard?).

• Event structures: editing with vi_edit; dynamic (user) events.

• vi_run operates a running VI's front panel: click, set, read.

• Helper VIs saved for LabVIEW 2015 and later.

• Verified on LabVIEW versions older than 2026 and on localized (non-English) LabVIEW.

Development

• Hand-built helpers are edited in LabVIEW from vis_src/.

• Generated helpers are built by python tools/helpergen.py from Python specs into vis_src/. Start from a freshly started LabVIEW so that no VI with the same name is already in memory. The generator uses diagram scripting together with the two hand-built configuration helpers: lvmcp_propconfig and lvmcp_invokeconfig.

• Shipping: python tools/build_helpers.py saves every helper for LabVIEW 2015 into src/labview_mcp/vis/, which is what ships.

• Class table: src/labview_mcp/vi_classes.json maps VI Server class names to the class numbers used in refnum type descriptors. It was measured by wiring a refnum of each class number into a Property Node and reading the node's class.

• tests/live_vi_create.py, tests/live_vi_edit.py, tests/live_project.py, and tests/smoke_mcp.py need Windows and LabVIEW.

• Measurement: python tools/measure.py run reads every software example VI shipped with LabVIEW (about 960), converts each to a vi_create spec, rebuilds it in a scratch folder, and compares the rebuilt VI with the original. python tools/measure.py report ranks the features that block rebuilding by how many examples use them. Originals are only read, never saved. The first baseline: 962/964 examples read, 23 rebuilt identically. After v0.17.0's reader fixes, examples blocked by a read gap fell from 742 to 374, and 27 are rebuilt identically; with v0.23.0's real terminal names, 32; with v0.25.0's Property/Invoke Node rebuild, 35, and no example is blocked by a Property Node any more (180 before); with v0.26.0's copied types (waveform, picture, timestamp, class objects, typedefs, units), 77, and examples stopped by a feature with no spec fell from 834 to 616; with v0.27.0's Bundle/Unbundle By Name, Format Into String sizes and exact connector-pane matching, 84, and failed rebuilds fell from 123 to 84; with v0.28.0's polymorphic VI paths, array-node terminal maps, wiring by terminal reference and consistent growable-node numbering, 123, and examples blocked by an unnamed wire end fell from 304 to 208; with v0.29.0's shift registers in the scan reader (paired sides, stacked elements) and stacked shift registers in vi_create, no example is blocked by a shift register any more (100 before), and 124 are rebuilt identically; with v0.30.0's event structure rebuild (frame events read from LabVIEW, several events per frame, event data and filter nodes, frames wired to shift registers and case tunnels, values passed through a frame) and the case-selector and frame-order fixes in the scan reader, no example is blocked by an event structure any more (64 before), and 130 are rebuilt identically; with v0.31.0's functions placed by palette name (Merge Errors, First Call?, To Time Stamp, TDMS, file I/O, Shared Variable), rebuilds LabVIEW refused for an unknown function fell from 33 to 3, and 138 are rebuilt identically. They build real VIs, run them, and check the results.

License

MIT. LabVIEW is a trademark of National Instruments (Emerson). This project is not affiliated with or endorsed by NI.