docs: AI-native MCP planning (RFC + v0.1 issue drafts)#231
Open
tylerkron wants to merge 1 commit into
Open
Conversation
Adds docs/planning/mcp/ with three documents proposing a first-class Model Context Protocol server for Nyquist devices, positioning DAQiFi as the "AI-native DAQ" before T&M competitors bolt LLM chat onto existing GUIs. Mirrors the docs/archive/simulator/ planning convention: RFC.md for review, GITHUB_ISSUES.md for ready-to-paste issue drafts, README.md as folder index. Open for feedback before issues are created. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Review Summary by QodoRFC and v0.1 issue drafts for AI-native DAQiFi MCP server
WalkthroughsDescription• Proposes AI-native MCP server for DAQiFi Nyquist devices • Positions product as agent-first control surface vs. legacy T&M competitors • Includes RFC with stack rationale, architecture, safety model, and launch plan • Provides 12 ready-to-paste GitHub issues with effort estimates and dependencies • Establishes LLM-safe streaming as key differentiator (summaries vs. raw samples) Diagramflowchart LR
A["Strategic Position<br/>AI-native DAQ"] --> B["MCP Server<br/>Daqifi.Mcp"]
B --> C["LLM-Safe Streaming<br/>Summaries + Sparklines"]
B --> D["Safety Model<br/>read-only/control/admin"]
B --> E["Distribution<br/>AOT + dotnet tool + npx"]
C --> F["5 Recipe Prompts<br/>Demo + Marketing"]
D --> F
E --> F
F --> G["v0.1 Launch<br/>~66h effort"]
File Changes1. docs/planning/mcp/RFC.md
|
Code Review by Qodo
1. WiFi recipe scope mismatch
|
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
Comment on lines
+559
to
+569
| ### Objective | ||
|
|
||
| Ship 5 MCP prompts that double as in-product onboarding and marketing artifacts. Each prompt is parameterized and runnable end-to-end against a real Nyquist device. | ||
|
|
||
| ### Prompts | ||
|
|
||
| - `setup_thermocouple_sweep(channels, sample_rate_hz, threshold_c, log_to_sd?)` | ||
| - `battery_soak_test(channels, duration_h, summary_interval_min, log_to_sd?)` | ||
| - `vibration_capture_fft(channel, duration_s, sample_rate_hz)` | ||
| - `multi_channel_pressure_test(channels, sample_rate_hz, threshold_v, log_to_sd?)` | ||
| - `wifi_provision_new_device(ssid, password)` |
There was a problem hiding this comment.
1. Wifi recipe scope mismatch 🐞 Bug ⚙ Maintainability
Issue #mcp-10 requires each prompt to be runnable end-to-end but includes wifi_provision_new_device, while the RFC scopes all network provisioning tools (configure_wifi, configure_static_ip) to v0.2, creating an inconsistency that will block implementing that prompt as written in v0.1.
Agent Prompt
### Issue description
The v0.1 recipe prompt list includes `wifi_provision_new_device(ssid, password)` and states prompts are runnable end-to-end, but the RFC explicitly defers network tools (`configure_wifi`, `configure_static_ip`) to v0.2. As written, v0.1 cannot satisfy the “runnable end-to-end” requirement for this recipe without expanding v0.1 scope.
### Issue Context
This doc is “ready-to-paste issue drafts”; any scope mismatch here is likely to become real scheduling/implementation churn.
### Fix Focus Areas
- docs/planning/mcp/GITHUB_ISSUES.md[559-570]
- docs/planning/mcp/RFC.md[130-141]
- docs/planning/mcp/RFC.md[160-169]
### Suggested fix options (pick one)
1. **Move the WiFi provisioning recipe to v0.2**, and replace it in v0.1 with a recipe that is supported by v0.1 tools (e.g., an SD-download-and-summary flow).
2. **Promote minimal WiFi provisioning support into v0.1** (add a v0.1 network tool and update the v0.1 tool table accordingly).
3. If you want to keep it as a “marketing preview,” **remove the “runnable end-to-end” guarantee** for that specific prompt and label it explicitly as “v0.2 placeholder / requires manual step.”
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
cptkoolbeenz
added a commit
that referenced
this pull request
May 27, 2026
Three additions to the RFC (#231): 1. Safety: send_scpi v0.2 design — two-tier net (destructive deny-list per-call allowDestructive, wiki-pattern hallucination warn with edit-distance suggestions). Mode-interaction matrix. Wiki snapshot strategy. Non-blocking — firmware response is ground truth. 2. Structured error response contract (v0.1 work) — drain SYST:ERR? before/after, optional SYST:LOG? scrape, readback failures as structured errors. Uniform {success,response,errors[],warnings[]} shape across all SCPI tools so the model never has to grep free text. 3. v0.2 fast-follow priority note — per chat: ship v0.2 quickly so the MCP becomes the primary firmware-feature-testing harness, replacing the per-feature Python harness pattern. Tool table phasing, marketing, open questions, tech stack untouched. send_scpi stays in v0.2 per original RFC.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Proposes positioning DAQiFi as the AI-native DAQ by shipping a first-class MCP (Model Context Protocol) server for Nyquist devices. Lab researchers, test engineers, and educators would drive a device end-to-end through Claude, Cursor, Cline, or any MCP-aware agent — discovery, channel configuration, streaming, SD logging, alerts — without writing application code.
The strategic bet: every T&M competitor (NI, MCC, Dataq) will bolt LLM chat onto an aging GUI within 12 months. None can rewrite their core control surface to be agent-first without years of internal lift. DAQiFi has two SKUs, a clean cross-platform .NET SDK, and no installed-base baggage — we can ship in weeks and plant a flag in this position before it's contested.
What's in this PR
Three documents under
docs/planning/mcp/, mirroring thedocs/archive/simulator/planning convention:Key decisions captured in the RFC
ModelContextProtocolNuGet (co-maintained by Microsoft + Anthropic).Daqifi.Coreis the asset — rewriting the wire protocol in Node or Python doubles maintenance forever. Distribution via AOT binary +dotnet tool+npxshim covers every audience without forking the protocol logic.read-only/control/admin), parameter clamps for sample rate and voltage range, confirmation flags for destructive ops. ""Agent-safe by design"" doubles as marketing.Decisions that need an answer
Two of the open questions in the RFC are blocking or near-blocking:
npx @daqifi/mcpdistribution:read-only(safer; the launch demo doesn't work until users pass a flag) orcontrol(works on first try; an agent could mis-configure on first contact). Blocks #mcp-9.The other six open questions (buyer segmentation, telemetry, MCP stability contract, LabVIEW interop, hosted recipe library, Desktop alignment) are flagged for discussion but don't block v0.1.
Test plan
This PR is documentation-only; nothing to run.
🤖 Generated with Claude Code