A local MCP assistant server for H7-TOOL development workflows. The server exposes H7-TOOL status, local device-library search, target identification, and focused diagnostic reads to MCP-compatible AI clients.
Server exposes 12 tools with complete input schemas and descriptions. However, descriptions are generic and lack LLM-optimized guidance on WHEN to use each tool vs. alternatives. Parameter descriptions exist but are minimal (avg ~40 chars, below 72-char baseline). No output schemas documented, LLMs cannot predict response structure. Error handling is absent; tools return raw subprocess output without recovery guidance. Tool naming is verb-first (good), but several tools (uart_transact, can_transact, i2c_transact, spi_transact) are nearly identical in structure, risking LLM confusion. No tool annotations (readOnlyHint, destructiveHint) despite clear risk stratification (READ_ONLY vs WRITE). Security: device_lua parameter accepts file paths, potential path traversal if not validated.
Read analog-to-digital converter (ADC) values from the target device.
Send a CAN frame and optionally receive responses from the target device.
Retrieve detailed information about a device definition file.
Read the state of GPIO pins on the target device.
Query the current status of the H7-TOOL device, including hardware information, clock, and uptime.
Perform I2C transactions (write/read) with a target device on the I2C bus.
Probe the connected target device to identify its type, IDCODE, CPUID, and unique ID.
No output schemas documented. LLMs cannot predict response structure or plan downstream tool calls. parse_* functions exist in code but are not exposed as tool documentation.
Four transact tools (uart, can, i2c, spi) have nearly identical parameter structures and descriptions. LLMs will struggle to distinguish when to use each. Descriptions lack WHEN guidance (e.g., 'Use uart_transact for serial communication with baud rate control; use can_transact for CAN bus frames').
No error handling or recovery guidance. Tools return raw subprocess output (e.g., parse_response, parse_target_probe_output) without actionable error messages. If a tool fails, LLM has no guidance on what to try next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
Read a block of memory from the target device at a specified address.
Read option bytes (flash configuration) from the target device.
Search the local H7-TOOL device library for device definitions matching a query pattern.
Perform SPI transactions (write/read) with a target device on the SPI bus.
Send data over UART and receive response from the target device.
device_lua parameter accepts file paths without documented validation. Potential path traversal vulnerability if LLM passes '../../../etc/passwd' or similar. No sanitization visible in code.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are marked READ_ONLY or WRITE in metadata, but this is not exposed to the MCP client. Agents cannot distinguish safe vs. risky tools.