daq-mcp

An MCP server that lets an AI coding client talk to NI DAQ hardware.

Most MCP demos wrap APIs or filesystems. This one wraps a data-acquisition device: list channels, read voltages, write digital lines, acquire a short waveform. That is interesting because the failure modes are physical — a hallucinated channel name or a stray analog output can damage equipment or hurt someone. The protocol plumbing is the easy part; the safety model is the point of the project.

Safety model

Writes are off by default. Only channels on an explicit allowlist can be touched. Analog output is clamped to a configured voltage range, and every write returns what actually happened (including clamp flags and digital read-back) so the model can verify its own actions.

The MCP tools never import nidaqmx directly. They call a backend interface. That boundary is what makes the server testable and portable.

Related MCP server: rigol-dho-mcp

Simulated by default (no NI drivers required)

Clone this on a machine without NI-DAQmx — including macOS — and it still runs. Set DAQ_MCP_SIMULATE=1 to force the pure-Python backend, or leave it unset: the server tries the real driver and falls back to simulation with a clear log line if NI is missing.

The simulator exposes two fake devices (Dev1 / Dev2) with realistic channel inventories. Dev1/ai0 is a slow sine with noise; Dev1/ai1 is a noisy DC level. Digital lines keep state across calls.

Install

Requires Python 3.11+ and uv.

cd MCP-NIDAQMX
uv sync

Optional real-hardware extra (needs NI-DAQmx drivers on the machine):

uv sync --extra hardware

Run the server:

uv run server.py

Useful environment variables:

DAQ_MCP_SIMULATE=1      # force simulated backend
DAQ_MCP_ALLOW_WRITE=1   # enable digital / analog output

Verify with MCP Inspector

cd MCP-NIDAQMX
DAQ_MCP_SIMULATE=1 npx -y @modelcontextprotocol/inspector uv run server.py

On Windows PowerShell:

cd C:\Users\folayaod\personal\MCP-NIDAQMX
$env:DAQ_MCP_SIMULATE = "1"
npx -y @modelcontextprotocol/inspector uv run server.py

Cursor configuration

Add to your Cursor MCP settings (user-level mcp.json). Prefer the full path to uv so Cursor does not depend on PATH:

{
  "mcpServers": {
    "daq-mcp": {
      "command": "C:\\Users\\folayaod\\.local\\bin\\uv.exe",
      "args": [
        "run",
        "--directory",
        "C:\\Users\\folayaod\\personal\\MCP-NIDAQMX",
        "server.py"
      ],
      "env": {
        "DAQ_MCP_SIMULATE": "1"
      }
    }
  }
}

Add "DAQ_MCP_ALLOW_WRITE": "1" only when you intentionally enable outputs.

A copy-paste template lives at .cursor/mcp.json.example. Put your real machine config in .cursor/mcp.json (gitignored) or in Cursor's user MCP settings — do not commit local paths or write-enable flags.

Tests

uv run pytest

All tests run against the simulated backend.

Tool design decisions

One tool per complete operation. Splitting "create task / add channel / start / read / close" into separate tools would force the model into multiple round-trips and make it easy to leave a hardware task open. Each tool opens what it needs, does one job, and closes everything before returning.

Summary over raw data for waveforms. monitor_analog returns mean, RMS, peak-to-peak, standard deviation, and a downsampled preview of at most 50 points. Dumping thousands of floats into the model context is expensive and rarely what you need for "is my sensor behaving?"

Project layout

server.py                 # MCP tools + safety layer
src/daq_mcp/backend/      # DAQBackend ABC, simulated + nidaqmx backends
tests/                    # pytest against the simulator