DAQiFi

Daqifi.Mcp

A Model Context Protocol (MCP) server that lets an AI agent (Claude Desktop, Claude Code, Cursor, Codex, …) drive a DAQiFi Nyquist data-acquisition device: discover it, connect, configure analog channels and sample rate, read live measurements, and run on-device SD-card logging.

It is a thin layer over Daqifi.Core — all device/protocol logic lives there. The server speaks MCP over stdio, so the client launches it as a subprocess.

Tools

Two ways to get data, for two different jobs. read_channel_values and capture_samples

stream live to the agent — good for spot checks and short captures, bounded by a duration and a

row budget so the answer stays a tool result rather than a file. SD logging is on-device: the

device writes to its own card at full rate for as long as you like, and you retrieve it afterwards

with download_sd_file, which writes the raw file and a CSV into this machine's temp directory.

Both live tools start the device's stream only if nothing is streaming yet, and stop it again

afterwards; a session that was already running is read and left alone. Neither works while the

device is logging to its SD card — the data goes to the card instead of to this machine, so those

calls are refused with that explanation rather than returning nothing.

Retrieve before you stream, unless discover_devices reports a firmwareVersion of 3.7.3 or

later (treat an empty or unknown version as older). On older firmware a live streaming session

collapses the device's SD buffer (firmware #703), after which downloads come back empty until the

device is power-cycled or another SD recording re-arms it. Firmware 3.7.3 keeps the buffer large

enough to read through and reports a failed read instead of going silent.

Analog output is Nyquist 3 hardware. On any other board set_analog_output is refused

outright, because the firmware would otherwise discard the command without saying so and the call

would look like a success. set_analog_output applies the voltage immediately unless you pass

latch=false, which stages it instead so several channels can be made to change together on one

latch_analog_outputs. Neither the staged value nor read_analog_output is a measurement of the

pin — the DAC has no readback path, so the device answers with the value it was last told to

drive.

Resources

The server also publishes the specifications of each board as MCP resources. What a device cannot tell you about itself is how fast it can go — there is no capability field for the single-channel sample-rate ceiling, so without this an agent finds it by provoking a rejection — or whether its analog inputs sample simultaneously, which decides whether two values in one captured row share an instant. An unconnected device cannot answer anything at all, and "which board do I need for ±10 V?" is a fair question to put to this server.

These describe the board model, not the unit on your bench, and for resolution and range they are the weaker source. A device declares both in its capability document (analog_in_res, analog_in_port_range) and Daqifi.Core scales every sample by exactly those numbers, so `list_channels` is the authority for anything connected — which is why the catalog's fields are named nominal…. The same goes for channel counts, PWM capability and DAC ranges. A value the catalog does not know is null rather than guessed: only Nyquist 1 publishes a rate ceiling, so the other two report maxSampleRateHz: null.

Resources are how a *person* hands this data to an agent: you attach one in your client. Most clients will not let the model fetch one on its own, which is why the same catalog is also the get_hardware_info tool. Both read the same table.

Prompts

Ready-made starting points for the jobs people actually bring a DAQ, listed by any client that supports MCP prompts:

The tool descriptions say what each tool does on its own; what they cannot say is which four to call, in what order, to answer "is this signal noisy?". That is what these carry.

A `--read-only` server lists only `summarize_sd_log`. Every other job opens by enabling channels or setting a rate, which read-only refuses on the first tool call, so offering them would advertise four dead ends. Retrieving a log survives because list_sd_files and download_sd_file are both allowed, and neither is refused while a log is running; only the opening stop_sd_logging is, so that prompt tells the agent to say so and summarize the file as it stands. The board resources are all still served — reading a specification changes nothing.

Run it

Option A — install as a .NET global tool (recommended)

dotnet tool install -g Daqifi.Mcp     # provides the `daqifi-mcp` command (requires the .NET runtime)

Option B — run it without installing (.NET 10 SDK)

dnx Daqifi.Mcp --yes                  # downloads and runs the server for this invocation

This is how a client that found the server in the MCP Registry (as io.github.daqifi/daqifi-mcp) will launch it.

Option C — from source (development)

dotnet run --project src/Daqifi.Mcp

Flags

--read-only               Expose discovery/introspection only; block configuration and logging.

--max-sample-rate-hz Reject set_sample_rate requests above Hz. --no-version-check Do not ask nuget.org at startup whether a newer release exists. -h, --help Show help.

A flag the server does not recognize — a typo such as --read-onyl included — stops it at startup with a one-line error on stderr naming the flag, and exit code 2, rather than starting it without the setting you meant. If your MCP client reports that the server failed to start, check its server log for that line.

--read-only blocks anything that changes the device or the card: channel/rate configuration, DIO/PWM output, analog output (set_analog_output, latch_analog_outputs), start/stop logging, and delete_sd_file. Reading data back is still allowed — list_sd_files, get_sd_storage, download_sd_file, list_analog_outputs and read_analog_output all work, since they change nothing on the device (the download does write its two files into this machine's temp directory, which is the only way the data can reach the agent at all).

The live tools sit on the line: reading a stream that is already running changes nothing and is allowed, but starting one is a change, so read_channel_values and capture_samples are refused under --read-only when the device is idle — and say so.

Staying current

The tool list grows with each release, so an out-of-date install is not merely behind — it is *missing capabilities*. A Daqifi.Mcp from before the live-data tools landed, for instance, can configure a device and start SD logging but cannot read a single value back, and an agent driving it reasonably concludes the hardware cannot measure anything. Nothing about that is visible from the inside.

So the server tells you. It reports its version in the MCP handshake, asks nuget.org once at startup whether a newer release exists and writes one line to stderr if so, and answers get_server_info with the same finding — call that whenever a tool you expected is not there.

dotnet tool update -g Daqifi.Mcp     # then restart your MCP client

That startup check is the only outbound request the server ever makes: one anonymous GET for a static nuget.org version index, no device data, five-second timeout, and a failure is silent. --no-version-check turns it off, after which get_server_info still reports the running version and says stal