Loading ToolBench
Cross-platform Model Context Protocol (MCP) server, reverse-engineering toolkit, and biometric insights engine for COLMI R02, R03, and compatible smart rings.
8 tools with complete schemas and descriptions, but quality is uneven. Tool names follow verb_noun convention (scan_rings, get_ring_status, blink_ring, sync_time, get_daily_activity, get_sleep_and_recovery, read_realtime_vitals, get_motion_sample). Descriptions range 80 - 250 chars, meeting the 10 - 1024 baseline. All parameters have type definitions and descriptions. However, descriptions lack actionable context (when to use, prerequisites, dependencies). No output schemas documented. Error handling absent, no guidance on retryability, recovery steps, or failure modes. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Parameter descriptions are minimal (e.g., 'Bluetooth MAC address or UUID of ring (optional; auto-discovers if omitted)' repeated across 7 tools). No pagination, batching, or composition guidance.
Causes the green optical biosensor LEDs on the smart ring to blink twice. Can be used as a physical locator ('Find my ring') or as a physical notification signal from the AI.
Queries the smart ring for step count, estimated calories burned, and distance walked. days_ago: 0 for today, 1 for yesterday, etc.
Captures a single real-time 3-axis accelerometer sample from the Sensortek STK8321 sensor. Returns raw 12-bit counts, g-force (±4g), vector magnitude, pitch, and roll angles.
Connects to the smart ring and queries hardware revision, firmware revision, battery percentage, and current charging status. If address is omitted, automatically finds and connects to the nearest ring.
Pulls multi-night sleep hypnograms (Light, Deep, REM, Awake) from the ring's Big Data service. Computes sleep architecture metrics and a custom Recovery Score (0-100) based on sleep quality, resting heart rate nadir, and oxygen saturation.
No output schemas documented. LLMs cannot plan downstream calls or extract fields without knowing response structure. All 8 tools lack documented return types.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint). Risk classifications exist (READ_ONLY, WRITE) but are not exposed in tool definitions. LLMs cannot reason about side effects or retry safety.
Descriptions lack actionable context. No guidance on when to use each tool, prerequisites, or dependencies. E.g., 'Synchronizes the smart ring's internal real-time clock (RTC) with the host system's current time' does not explain why or when an LLM should call this.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | <=2025-11-25 | v2 |
Streams live optical pulse (Heart Rate in BPM) or SpO2 (blood oxygen %) from the smart ring for a configurable duration. Useful for spot-checks or AI-initiated vital sign monitoring.
Scans for nearby smart rings over Bluetooth Low Energy. Returns list of discovered rings with device name, MAC address/UUID, and RSSI signal level.
Synchronizes the smart ring's internal real-time clock (RTC) with the host system's current time.
No error handling or recovery guidance. Tools do not document failure modes, retryability, or what the LLM should do if a call fails (e.g., 'Ring not found. Try scan_rings() first.').
Repeated parameter descriptions across 7 tools ('Bluetooth MAC address or UUID of ring (optional; auto-discovers if omitted)') signal missed opportunity for composition. Consider a single 'resolve_ring_address' helper or a shared parameter pattern.