Loading ToolBench
Python definitions for the ClawTouch HID v1.1 wire protocol (additive over v1.0 frozen baseline) — USB CDC frames spoken by ClawTouch Pico firmware. Includes the v1.1 MOUSE_BUTTON_DOWN/UP opcodes for drag gestures.
This is a protocol library, not an MCP server. It exposes 11 low-level HID command builders with well-structured schemas and detailed descriptions. Naming follows verb_noun convention (build_*, modifiers_to_mask). Descriptions are thorough (100-300 chars), explaining wire format, parameter ranges, and firmware behavior. All tools have complete input schemas with types and descriptions. However, the library lacks output schema documentation, error handling guidance, and composition patterns expected of production tools. No MCP transport layer is present, this is a pure Python library for frame serialization. Scoring reflects library quality, not MCP readiness.
Build a KEY_COMBO command frame. KEY_COMBO payload is [modifiers, keycode] — same byte order as build_key_press and build_key_release (unified v1.1.1). Note the positional order here is (modifiers, keycode) — the reverse of build_key_press / build_key_release, whose first positional argument is the keycode. Prefer keyword arguments.
Build a KEY_PRESS command frame. KEY_PRESS payload is [modifiers, keycode] (unified v1.1.1 — same as build_key_release and build_key_combo; matches the USB HID keyboard report layout where the modifier byte comes first). Warning: The positional parameter order is (keycode, modifiers) — the opposite of build_key_combo's (modifiers, keycode). The wire payload is identical either way, but a positional call written by analogy to build_key_combo would silently swap the two values. Prefer keyword arguments (keycode=, modifiers=).
Build a KEY_RELEASE command frame. KEY_RELEASE payload is [modifiers, keycode] — same byte order as build_key_press and build_key_combo (unified v1.1.1). Both arguments zero (the default) is panic-stop semantics: firmware releases every held key and mouse button. Pass explicit keycode/modifiers to release a specific key. Like build_key_press, the positional order is (keycode, modifiers) — opposite of build_key_combo. Prefer keyword arguments.
v1.1: press a mouse button and do NOT release it. Pair with build_mouse_button_up to compose a drag (with build_mouse_move frames in between).
No output schema documentation. Tools return bytes (serialized frames) but callers cannot see the structure. LLMs need to know what fields/types to expect from return values.
No error handling guidance. ProtocolError is raised for invalid payloads (e.g. payload > 1024 bytes, invalid seq_id), but descriptions do not explain what errors are possible or how to recover. LLMs cannot self-correct.
Parameter naming inconsistency: build_key_press and build_key_release use positional order (keycode, modifiers) opposite to build_key_combo (modifiers, keycode). Descriptions warn of this, but the inconsistency invites silent bugs when LLMs use positional args instead of keywords.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
v1.1: release a previously-pressed mouse button. Idempotent — releasing a non-held button is a no-op (no error).
Build a MOUSE_CLICK command frame with optional double-click flag
Encode a MOUSE_MOVE frame. x/y are signed int16 deltas (±32767); a value outside that range raises struct.error here, before anything reaches the wire. The firmware delivers the delta as USB HID Boot Mouse reports, which carry only int8 per axis (−127..127): Adafruit HID's Mouse.move() splits any |delta| > 127 into successive reports, so a large delta arrives in full over multiple reports. Neither side clamps — emitting deltas > 127 (e.g. a cross-monitor hop) is normal and supported.
Build a MOUSE_SCROLL command frame with signed int16 delta
Build a PING command frame
Build a KEY_TYPE_STRING command frame to type a UTF-8 encoded string
Translate names like ["ctrl", "shift"] to a modifier bitmask.
No composition guidance. Tools are low-level frame builders; no documentation on how to chain them (e.g. button_down → move → button_up for drag). Agents must infer the sequence.
Not an MCP server. This is a pure Python library with no transport layer, no tool registration, no MCP protocol implementation. Cannot be used directly by MCP clients.