Loading ToolBench
MCP server for teensy_loader_cli — flash firmware to Teensy boards from AI coding agents
Five tools with clear verb-noun naming (check_cli, list_mcus, flash_hex, boot_device, soft_reboot). Descriptions are present and substantive (100-300 chars), explaining WHAT and WHEN. All tools have input schemas with types and descriptions. However, output schemas are not formally documented, responses are JSON strings without declared field structures. Error handling is minimal: no recovery guidance, no categorization of retryable vs fatal errors. Parameters lack constraints (enums, ranges) for critical values like 'mcu' and 'timeout_seconds'. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels (WRITE vs READ_ONLY). Missing idempotency guidance for destructive operations (flash_hex, boot_device).
Reboot a Teensy into its application firmware without programming (CLI -b). Useful when HalfKay is running and you want to start the previously flashed sketch, or after a no_reboot flash. Args: mcu: Target MCU (e.g. TEENSY41). wait: Wait for the device to appear in HalfKay. soft_reboot: Soft-reboot into bootloader first if needed (-s). hard_reboot: Use external rebootor (-r). verbose: Verbose CLI output. timeout_seconds: Command timeout.
Check whether teensy_loader_cli is installed and report its path and version. Returns JSON with found path, version string, and server version.
Program an Intel HEX firmware file onto a Teensy board via HalfKay. Args: hex_path: Absolute or relative path to the .hex file to flash. mcu: Target MCU (e.g. TEENSY41, TEENSY40, TEENSY32, imxrt1062, mk20dx256). wait: Wait for the device to appear (press the program button). Default true. soft_reboot: Send a soft reboot request if the board is not in bootloader (Teensy 3.x/4.x USB Serial). Maps to -s. hard_reboot: Use an external rebootor Teensy on C7. Maps to -r. no_reboot: Do not reboot into the app after programming. Maps to -n. verbose: Enable verbose CLI output. Default true. timeout_seconds: Max seconds to wait for the CLI (include button-press time). Returns: JSON with success flag, command run, and CLI output.
List supported Teensy MCU identifiers for --mcu=. Returns logical names (TEENSY40, TEENSY41, …), chip IDs (imxrt1062, …), board names, and flash sizes. Use the logical name when flashing.
Output schemas not formally documented. Tools return JSON strings without declared field structures (ok, action, details, output, error). LLMs cannot plan downstream operations or extract specific fields reliably.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite clear risk levels. flash_hex and boot_device are WRITE operations that modify device state; check_cli and list_mcus are READ_ONLY. Agents cannot reason about safety or retry semantics.
Critical parameter 'mcu' lacks enum constraint. Accepts free-form strings (TEENSY41, imxrt1062, mk20dx256, etc.) without validation. LLMs may hallucinate invalid MCU names. Should declare enum of valid values from MCU_CATALOG.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2026-07-28+ | v2 |
Send a soft reboot request to a Teensy board (CLI -s).
Error responses lack recovery guidance. Errors are returned as plain strings (e.g., 'TeensyLoaderNotFoundError') without actionable next steps. No categorization of retryable vs fatal errors. LLMs cannot self-correct or plan recovery.
Numeric parameters (timeout_seconds) lack range constraints. flash_hex defaults to 120s, boot_device to 60s, but no min/max documented. LLMs may pass absurd values (0, 999999) causing timeouts or resource exhaustion.