Loading ToolBench
Connector process that bridges a local Hermes CLI to Hermes Mobile relay. Provides real-time location and health data from the user's phone.
Server has 8 tools with consistent naming (verb_noun pattern: get_*) and reasonable descriptions (100-250 chars, within baseline 194 avg). All tools are READ_ONLY, lowering risk. However, input schemas are present but minimal, most lack parameter descriptions, and output schemas are entirely undocumented. The query_sensor_data tool accepts arbitrary SQL, creating injection risk without validation guidance. No error handling patterns visible (recovery guides, retryability classification, actionable error messages). Tool composition is reasonable (each does one thing), but parameter documentation is sparse.
Get time-series data for a specific health metric. Returns historical samples for the requested metric ordered newest first. Available metrics: steps, active_calories, distance_walking, heart_rate, resting_heart_rate, blood_oxygen, respiratory_rate, body_mass, workout_minutes, stand_hours, sleep_duration.
List all available health metrics and their latest values. Returns the names of all health metrics that have been recorded, along with their most recent values. Use this to discover what health data is available before querying specific metrics.
Get a summary of all the user's latest health metrics. Returns current values for all tracked health metrics (steps, heart rate, calories, sleep, etc). Use this for general health queries or when the user asks about their overall health status.
Get the user's recent location history. Returns a trail of location readings ordered newest first. Use this for queries like "where have I been today" or to understand the user's travel patterns.
Return the SQLite schema for the sensor database. Shows all table definitions, column types, and indexes. Use this to understand the data structure before writing custom queries with query_sensor_data.
Output schemas completely undocumented. LLMs cannot plan downstream tool calls or extract structured data without knowing what fields to expect. All 8 tools lack return type documentation.
Parameter descriptions missing or minimal. 'since' and 'limit' params in get_location_history and get_health_metric have descriptions, but get_user_location, get_health_summary, get_health_metrics_list, get_user_activity, and get_sensor_schema have empty input schemas with no param guidance.
query_sensor_data accepts arbitrary SQL with only a 'limit' constraint. No validation guidance, injection prevention, or error recovery hints. LLMs could pass malicious or malformed queries without clear feedback on what went wrong.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Get the user's current physical activity (stationary, walking, running, driving, cycling). Returns the latest activity classification from the device's motion sensors, with freshness metadata. Stale if older than 15 minutes.
Get the user's current location (latitude, longitude, address). Returns the most recent location reading from the user's phone. Use this when the user asks about their current location, wants nearby recommendations, or needs location-aware assistance.
Run a read-only SQL query against the sensor database. Use this for custom analysis, trend queries, aggregations, or building dashboards. The database contains tables: location_current, location_history, health_samples, health_latest, health_daily.
No error handling patterns visible. Tools lack recovery guides (e.g., 'If location is stale, try get_user_activity'), retryability classification, or actionable error messages. Agents cannot distinguish transient failures from permanent ones.
No pagination or result-limiting guidance in descriptions. get_location_history and get_health_metric accept 'limit' params but descriptions don't explain default behavior, max cap, or when pagination is needed. Agents may request excessive data.