Loading ToolBench
Model Context Protocol server for DAQiFi device control, data acquisition, and SD card management
The server defines 26 tools with consistent naming, good verb-noun conventions, and documented input schemas. All tools have descriptions and parameter types are declared. However, output schemas are not visible in the source code, parameter descriptions vary in quality (some are minimal), and error handling guidance is absent. Tool annotations (destructiveHint, readOnlyHint) are present and properly declared. The codebase is well-structured with contract tests, but the MCP server interface itself (tool registration, output documentation) is not directly visible in the provided samples. Schema quality is solid where visible, but lack of output documentation and limited error context prevent a higher score.
Capture a time-windowed set of samples from all enabled channels
Enable or disable specific analog input channels
Enable or disable specific digital input channels
Connect to a DAQiFi device by serial number
Delete a file from the device's SD card
Disable PWM output on a digital channel
Disconnect from a DAQiFi device
Output schemas not documented in provided source. Tool definitions show input schemas clearly (device_id, channel, etc.) but return types/structures are not visible in the code samples provided. This prevents LLMs from understanding what data is available after a tool call, forcing inference or trial-and-error on downstream chaining.
Error handling and recovery guidance absent. Tools have no documented error cases, validation messages, or recovery hints. An LLM encountering 'device not found' has no suggestion for what to try next (e.g. call discover_devices() first). This violates the recovery-guide pattern and forces agents to guess.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
Discover available DAQiFi devices
Download a file from the device's SD card and optionally export as CSV
Get the current status of a connected device
Get SD card storage capacity and usage information
Retrieve server information
Apply all staged analog output values together
List available analog output (DAC) channels on a device
List all channels available on a device
List all currently connected DAQiFi devices
List files on the device's SD card
Read the current or pending voltage of an analog output channel
Read the latest sampled values from enabled channels
Set voltage on an analog output (DAC) channel, optionally latched to take effect
Set digital channel as input or output
Set digital output channel to high (1) or low (0)
Configure PWM (Pulse Width Modulation) on a digital channel
Set the data acquisition sample rate
Start logging data to the device's SD card
Stop logging data to the device's SD card
Destructive operations (set_digital_output, set_pwm_output, set_analog_output, delete_sd_file, latch_analog_outputs) lack confirmation or dry-run support. Agents can accidentally set hardware outputs or delete files without review. No idempotent hints visible despite risk annotations present.
Parameter descriptions are minimal and inconsistent in detail. Most parameters have single-sentence descriptions like 'Device serial number identifier' without constraints, valid ranges, or format guidance. Baseline rubric expects 'at least 72 chars of context per param', many fall short. No enum descriptions for multi-value fields beyond the values themselves.
No pagination or result limiting documented for list_* tools (list_connected_devices, list_channels, list_sd_files). If a device has hundreds of channels or files, no cap or cursor guidance is visible. This risks context window exhaustion in large deployments.
Tool composition may force multi-step workflows. Example: to set a PWM on a digital channel, the agent may need to call set_digital_direction first, then set_pwm_output. Dependency hints are absent from descriptions. No 'See also' or 'Prerequisites' guidance visible.