DAQiFi

io.github.daqifiPublished by GitHub account daqifiv1.9.1Updated Nov 6, 2026

Discover, configure and read DAQiFi Nyquist data-acquisition hardware from an AI agent

VerifiedSTDIODesktop onlyDeveloper ToolsData & Analytics

Overview

AI-generated overview

Lets an AI assistant discover, connect to, configure and read DAQiFi Nyquist data-acquisition hardware, including live samples and SD-card logs.

What you can do
  • Discover and connect to DAQiFi devices over USB/serial or WiFi, list and disconnect them, and check status and channels
  • Enable analog and digital channels, set digital direction and output, drive PWM, and set or latch DAC voltages on Nyquist 3 boards
  • Set the sample rate and read the latest value on every enabled channel or capture a block of live samples
  • Start and stop on-device SD logging, list log files and storage, download a log (parsed to CSV) and delete files
  • Report the server's own version and whether a newer release is published
When to use it
Useful when you have a DAQiFi Nyquist device attached and want an assistant to set up channels and sample rates, take spot readings or short captures, or manage SD-card logging and retrieve the resulting data for analysis.
Requirements
Runs locally as a .NET tool launched over stdio: install the Daqifi.Mcp global tool (needs the .NET runtime) or run it with dnx (needs the .NET 10 SDK). A DAQiFi device reachable over USB/serial or WiFi is required; SD logging needs a USB/serial connection. No API keys or environment variables are declared.
Before you install
Tools change real hardware: channel and rate configuration, digital and PWM outputs, DAC voltages, logging start/stop and SD file deletion. Use the read-only flag to block changes. Downloads write files into the machine's temp directory. The server makes one anonymous startup request to nuget.org unless the version check is disabled; device data stays local.

Installation

In SourceWeft

  1. Open DAQiFi in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

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

ToolPurpose
get_server_infoThis server's own version, and whether a newer Daqifi.Mcp is published.
discover_devicesFind devices on USB/serial and WiFi. Call first; returns device_ids.
connect_deviceConnect to a discovered device_id.
list_connected_devicesList currently-connected devices.
disconnect_deviceDisconnect and release a device.
get_device_statusConnection state, streaming/logging flags, sample rate, enabled channels.
list_channelsAll channels with type/enabled/direction.
configure_analog_channelsEnable exactly the given analog channels; disable the rest.
configure_digital_channelsEnable exactly the given digital channels; disable the rest.
set_digital_directionSet a digital channel to input or output.
set_digital_outputDrive a digital channel high or low (switches it to output if needed).
set_pwm_outputStart PWM on a capable channel: duty 1-100%, shared frequency 6-50000 Hz.
disable_pwmStop PWM on a channel (pin is left high-impedance).
list_analog_outputsThe DAC channels with the voltage range each accepts and the value it is driving.
set_analog_outputDrive a DAC channel to a voltage (Nyquist 3 only); range-checked before it is sent.
latch_analog_outputsApply the voltages staged with set_analog_output latch=false, together.
read_analog_outputAsk the device what a DAC channel is holding.
set_sample_rateSet sample rate in Hz (ceiling depends on the enabled channel count; over-cap requests are rejected).
read_channel_valuesLatest value on every enabled channel, with the timestamp it was sampled at.
capture_samplesA block of live data as rows: one row per sample tick, one column per channel.
start_sd_loggingStart on-device SD logging (requires a USB/serial connection).
stop_sd_loggingStop SD logging.
list_sd_filesList the log files on the SD card, with size and creation date.
get_sd_storageFree/used/total space on the SD card.
download_sd_fileFetch a log file to this machine and (by default) parse it into a CSV.
delete_sd_fileDelete a file from the SD card. Destructive; blocked by --read-only.

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.

Run it

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

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

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

bash
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)

bash
dotnet run --project src/Daqifi.Mcp

Flags

--read-only               Expose discovery/introspection only; block configuration and logging.--max-sample-rate-hz <n>  Reject set_sample_rate requests above <n> 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.

bash
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 staleness is unknown.

Point your agent at it

An stdio MCP server is just a command the client launches. Every client config reduces to command + args.

Claude Desktop — claude_desktop_config.json:

json
{  "mcpServers": {    "daqifi": { "command": "daqifi-mcp", "args": [] }  }}

Claude Code:

bash
claude mcp add daqifi -- daqifi-mcp

Cursor — ~/.cursor/mcp.json (same shape as Claude Desktop).

Codex CLI — ~/.codex/config.toml:

toml
[mcp_servers.daqifi]command = "daqifi-mcp"args = []

During development, point the client at the source build instead: { "command": "dotnet", "args": ["run", "--project", "/abs/path/to/src/Daqifi.Mcp"] }.

Then plug in a DAQiFi over USB (or join its WiFi) and ask, e.g.: "Discover my DAQiFi, connect, enable analog channels 0–3 at 1 kHz, and start logging to the SD card." "Stop the log, then download it and tell me the average on AI0." "What voltage is on AI1 right now?" "Capture two seconds off channels 0–3 and tell me if anything looks noisy."

Notes

  • stdout is reserved for the MCP JSON-RPC stream; all logging goes to stderr.
  • The server runs locally and talks to the device exactly like Daqifi.Core does — no measurement, device or configuration data ever leaves your machine. The one outbound request is the startup version check described above, which sends nothing but a user agent and can be disabled with --no-version-check.

Source: src/Daqifi.Mcp/README.md at commit 5ddf099

Tools

0
SourceWeft started this package once in an isolated sandbox, without credentials, to list its tools. That failed: the package type cannot run in the sandbox.

Version history

3
  1. v1.9.1LatestNov 6, 2026
  2. v1.9.0Nov 4, 2026
  3. v1.8.0Sep 16, 2026

Score

50% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts

    Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.

  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts