Loading ToolBench
Exposes Telepath #[command] functions as MCP tools. Unified CLI for Telepath: interactive shell and MCP server for embedded RPC communication.
Telepath is a low-level embedded RPC framework, not an MCP server. Tools have complete JSON schemas with proper types and required fields, but descriptions are extremely terse (10 - 50 chars), far below the 50 - 200 char LLM-optimized baseline. No parameter descriptions exist, only tool-level descriptions. Error handling is absent; no recovery guidance. Tool names are verb-noun (ping, add, crc32, echo, led_set, led_pattern, led_pattern_get, button_read, ficr_uid, temp_read, rng_u32, saadc_vdd_mv) but lack context for LLM selection. Schemas are well-formed but parameter semantics are undocumented. This is a hardware control toolkit, not an agent-facing tool suite.
Returns `a + b`.
Instantaneous snapshot of all four button states. Bit 0 = BTN1, bit 3 = BTN4. Pressed = 1 (active-low hardware, inverted here). No wait semantics: the caller polls at its own rate.
CRC-32/ISO-HDLC over the provided payload.
Returns the payload unchanged.
Unique 64-bit chip ID from FICR.DEVICEID[0..1]. Pure MMIO read — no peripheral initialization required. The value is factory-programmed, stable across reboots, and unique per die. Example (one particular nRF52840-DK): `(0x893CE2C0, 0xA94DF961)`. Your board will return different values; treat as an opaque identifier.
Set all four LEDs in one round trip. Bit 0 = LED1, bit 3 = LED4. Upper nibble is ignored. Returns the applied mask (bits 0–3 only).
Parameter descriptions completely absent. Tools have input schemas with types but zero documentation of what each parameter controls, valid ranges, or constraints. LLMs cannot infer semantics from names alone (e.g., 'mask' in led_pattern lacks explanation of bit layout).
Tool descriptions are extremely terse (10 - 50 chars), far below the 50 - 200 char LLM-optimized baseline. Descriptions lack context for when to use each tool, what it returns, or how it differs from similar tools. Example: 'Sanity check; returns 0xDEADBEEF' (ping) provides no actionable guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Read back the current driven state of all four LEDs. Bit 0 = LED1, bit 3 = LED4. On (illuminated) = 1, Off = 0 (active-low hardware is inverted here).
Set one LED. `id` must be 1–4; returns `false` and does nothing if out of range. Active-low hardware: `on = true` drives the pin low to illuminate the LED.
Sanity check; returns `0xDEADBEEF`.
True random u32 from the hardware RNG with bias correction enabled. Each call generates 4 fresh random bytes; values should differ across calls.
Supply voltage in millivolts via the SAADC VDD internal channel. Typical value: ~3300 mV under USB power, ~3000 mV from a coin cell.
Die temperature in 0.25 °C units. Returns a signed integer: divide by 4 to get °C, or multiply by 250 for m°C. Example: 100 → 25.00 °C; 111 → 27.75 °C. Operating range: −160…340 (nRF52840 specification: −40 °C to 85 °C).
No error handling or recovery guidance. Tools return raw values with no indication of failure modes, invalid inputs, or what the LLM should do if a call fails. Example: led_set returns false for out-of-range ID but description does not explain this.
Ambiguous parameter names without type suffixes. 'id' in led_set could be a string or integer; 'mask' in led_pattern is opaque without bit-layout documentation. Naming should follow 'param_type' convention (e.g., led_id, bit_mask).
Output schemas not documented. Tools return values (e.g., temp_read returns signed integer in 0.25°C units) but no formal output schema is visible. LLMs cannot plan downstream operations without knowing return types and field names.