Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Description from the maker (original English)
Discover, configure and read DAQiFi Nyquist data-acquisition hardware from an AI agent
These three are never merged into one score: opinions, measurements and popularity are different things.
We have not written a plain-language summary for this one yet. Below are the facts we read from the registry.
Pick the AI app you use, then copy the settings.
Which app do you use?
Pick your app above. We remember it, so next time the button says “Install in …”.
Open Claude Desktop → Settings → Developer → Edit Config, and paste this into claude_desktop_config.json
{
"mcpServers": {
"daqifi": {
"command": "dnx",
"args": [
"Daqifi.Mcp",
"--yes"
]
}
}
}Run this in your terminal
claude mcp add daqifi -- dnx Daqifi.Mcp --yesPaste into .cursor/mcp.json in your project, or ~/.cursor/mcp.json
{
"mcpServers": {
"daqifi": {
"command": "dnx",
"args": [
"Daqifi.Mcp",
"--yes"
]
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
Paste into .vscode/mcp.json in your project
{
"servers": {
"daqifi": {
"type": "stdio",
"command": "dnx",
"args": [
"Daqifi.Mcp",
"--yes"
]
}
}
}Your browser asks to open the app, then the app shows the settings and asks you to confirm. Key values are left empty for you to fill in.
This one runs on your computer, and ChatGPT can only connect to servers on the internet. Pick another app.
Your choice stays on this device in a cookie; no account needed.
These settings are generated from the maker’s registry entry. If the README says otherwise, follow the README.
Runs on your computer; the tool list appears in your AI app after you install it.
We check information anyone can see; we have not read the code. Checks that do not apply are left out of the count. · Checked Nov 6, 2026
The registry name was verified with the GitHub account daqifi, which owns the repo
We have not read this repo from GitHub yet
We have not read this repo from GitHub yet
This one runs on your computer; there is no internet endpoint
Runs on your computer and uses local settings instead
Runs on your computer; we can only read tool lists from internet endpoints
Compared with every active server in this category in the registry. Stars count only when the publisher owns the repo.
It passed 1 of 1 applicable basic checks. We have not read the code. Before adding a key or token, see what access the server asks for and use a key with only the permissions you need.
The registry does not list a required key, though some servers ask you to sign in on first use.
It runs on your computer. Your AI app starts it when needed, and data does not pass through the maker’s servers (unless it calls an online service itself).
The GitHub repo last changed –, and the latest version (1.9.1) reached the registry today.
Apps that support MCP, such as Claude Desktop, Claude Code, Cursor and VS Code. You also need .NET on your computer.
In the same category: Spec Driven Development, Remote Desktop Commander, zanadir
Servers in the same category from other makers, sorted by stars.
Reading a card:★ GitHub starsiThree pillars: reviews · checks · usageiUpdated = latest version published to the registryi
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Find what a repository's CI is missing, and which security checks cannot fail the build.
Copied from the maker’s repo as written. PopNx MCP has not reviewed or endorsed it. HTML, images and scripts are removed. Links lead off this site.
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.
| Tool | Purpose |
|---|---|
get_server_info | This server's own version, and whether a newer Daqifi.Mcp is published. |
discover_devices | Find devices on USB/serial and WiFi. Call first; returns device_ids. |
connect_device | Connect to a discovered device_id. |
list_connected_devices | List currently-connected devices. |
disconnect_device | Disconnect and release a device. |
get_device_status | Connection state, streaming/logging flags, sample rate, enabled channels. |
list_channels | All channels with type/enabled/direction. |
configure_analog_channels | Enable exactly the given analog channels; disable the rest. |
configure_digital_channels | Enable exactly the given digital channels; disable the rest. |
set_digital_direction | Set a digital channel to input or output. |
set_digital_output | Drive a digital channel high or low (switches it to output if needed). |
set_pwm_output | Start PWM on a capable channel: duty 1-100%, shared frequency 6-50000 Hz. |
disable_pwm | Stop PWM on a channel (pin is left high-impedance). |
list_analog_outputs | The DAC channels with the voltage range each accepts and the value it is driving. |
set_analog_output | Drive a DAC channel to a voltage (Nyquist 3 only); range-checked before it is sent. |
latch_analog_outputs | Apply the voltages staged with set_analog_output latch=false, together. |
read_analog_output | Ask the device what a DAC channel is holding. |
set_sample_rate | Set sample rate in Hz (ceiling depends on the enabled channel count; over-cap requests are rejected). |
read_channel_values | Latest value on every enabled channel, with the timestamp it was sampled at. |
capture_samples | A block of live data as rows: one row per sample tick, one column per channel. |
start_sd_logging | Start on-device SD logging (requires a USB/serial connection). |
stop_sd_logging | Stop SD logging. |
list_sd_files | List the log files on the SD card, with size and creation date. |
get_sd_storage | Free/used/total space on the SD card. |
download_sd_file | Fetch a log file to this machine and (by default) parse it into a CSV. |
delete_sd_file | Delete a file from the SD card. Destructive; blocked by --read-only. |
Two ways to get data, for two different jobs.
read_channel_valuesandcapture_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_devicesreports afirmwareVersionof 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_outputis refused
outright, because the firmware would otherwise discard the command without saying so and the call
would look like a success.
set_analog_outputapplies 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 norread_analog_outputis a measurement of the
pin — the DAC has no readback path, so the device answers with the value it was last told to
drive.
dotnet tool install -g Daqifi.Mcp # provides the `daqifi-mcp` command (requires the .NET runtime)
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.
dotnet run --project src/Daqifi.Mcp
--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.
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 staleness is unknown.
An stdio MCP server is just a command the client launches. Every client config reduces to command + args.
Claude Desktop — claude_desktop_config.json:
{
"mcpServers": { "daqifi": { "command": "daqifi-mcp", "args": [] } } }
Claude Code:
claude mcp add daqifi -- daqifi-mcp
Cursor — ~/.cursor/mcp.json (same shape as Claude Desktop).
Codex CLI — ~/.codex/config.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."*
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.