Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
作者提供的说明(英文原文)
Discover, configure and read DAQiFi Nyquist data-acquisition hardware from an AI agent
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
打开 Claude Desktop → Settings → Developer → Edit Config,把下面的内容粘贴到 claude_desktop_config.json
{
"mcpServers": {
"daqifi": {
"command": "dnx",
"args": [
"Daqifi.Mcp",
"--yes"
]
}
}
}在终端中运行这条命令
claude mcp add daqifi -- dnx Daqifi.Mcp --yes粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"daqifi": {
"command": "dnx",
"args": [
"Daqifi.Mcp",
"--yes"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"daqifi": {
"type": "stdio",
"command": "dnx",
"args": [
"Daqifi.Mcp",
"--yes"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
这个服务器在你的电脑上运行,而 ChatGPT 只能连接互联网上的服务器。请选择其他应用。
你的选择通过 Cookie 保存在这台设备上,无需账户。
这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
它在你的电脑上运行;安装后,工具列表会显示在你的 AI 应用中。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月6日
注册名称已通过 GitHub 账户 daqifi 验证,该账户拥有此仓库
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
它在你的电脑上运行,没有互联网端点
在你的电脑上运行,改用本地设置
它在你的电脑上运行;我们只能读取互联网端点的工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。
它在你的电脑上运行。你的 AI 应用会在需要时启动它,数据不会经过作者的服务器(除非它自己调用在线服务)。
GitHub 仓库最后更新于–,最新版本(1.9.1)于今天进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。你的电脑上还需要有 .NET。
同一分类中有:Spec Driven Development, Remote Desktop Commander, Recta
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
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.
Cheaper cross-chain stablecoin routes for AI agents; 5 % of the verified saving, nothing if none.
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
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.