Loading ToolBench
MCP server for the Electra One plugin. Exposes nine tools that combine USB SysEx push (via mido + python-rtmidi), MIDI log capture, doc search, validation, bundling, and emulator screenshots.
Single tool 'push_to_device' has a detailed description (>500 chars) but lacks critical schema documentation. Input parameters are defined in the docstring (preset_path, bank, slot, out_port) with types and descriptions, but no formal JSON Schema is visible in the source code. The tool performs a destructive operation (device firmware upload) but has no error handling guidance, confirmation pattern, or recovery instructions. Parameter descriptions are present but lack constraints (e.g., bank range 0-5, slot range 0-11 are mentioned in docstring but not in schema). No output schema documented. Tool naming is clear (verb_noun pattern), but the implementation is incomplete for production use.
Upload a widget preset to the Electra One, end-to-end. Reads the preset JSON, auto-detects whether it's in the repo's "tiles" schema (`schemaVersion`, `tiles[]`) or the device firmware's "controls" schema (`version`, `controls[]`). For "tiles" presets, converts to the "controls" format via the byte-identical port of `projectToPreset` from app.electra.one's JS bundle. Splits the `lua` field into a separate main.lua upload. Sends: 1. `09 08 bank slot` — switch to target slot 2. `01 01 <preset.json>` — upload preset 3. `01 0C <main.lua>` — upload Lua (if present) 4. Slot-flip reload — `09 08 bank (slot XOR 1)` then back — forces the device to cold-reload from disk (`08 08 Reload Preset Slot` NACKs on firmware 4.1.4). Each step waits for ACK on the CTRL input; NACK aborts.
No formal JSON Schema visible for tool input. Parameters documented in docstring only; FastMCP decorator lacks explicit schema definition with types, constraints, and required fields.
No output schema documented. Tool returns dict[str, Any] with 'ok' and 'error' fields, but success response structure is undefined. LLM cannot plan downstream actions.
Destructive operation (firmware upload) lacks confirmation pattern or dry-run mode. No guidance on recovery if upload fails mid-stream. Error responses do not indicate retryability or next steps.
Parameter constraints (bank 0-5, slot 0-11) stated in docstring but not enforced in schema. No enum or range validation visible. LLM may pass invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
Error handling returns raw dict with 'ok' and 'error' fields but does not classify errors (retryable vs fatal) or suggest recovery actions. LLM has no guidance on next steps.