Loading ToolBench
Akari Health MCP server over the Akari Pulse HTTP service. Provides health data access from BlueOS watch and phone sources via MCP protocol.
Server demonstrates solid fundamentals: all 7 tools have descriptions (194 - 250 chars, within baseline), explicit input schemas with type constraints, and consistent tool annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint). Naming follows verb_noun pattern (latest, heart_rate, steps, sleep, today, range, daily). However, parameter descriptions are sparse or missing context. For example, 'metrics' in latest/heart_rate/range lacks guidance on valid metric names or discovery mechanism. The 'calendar_offset_minutes' parameter appears in 4 tools but its interaction with 'date' is underdocumented. Output schemas are not explicitly documented in tool definitions, only inferred from the statusSchema/outputSchema objects in code. Error handling is present (statusSchema enum: PASS, DEGRADED, NO_DATA, DENIED, UNSUPPORTED, API_MISSING, ERROR) but tool descriptions do not explain when each status occurs or how to recover. No pagination guidance for tools returning arrays (latest, heart_rate, range, daily). Composition is clean, each tool has one responsibility, but chaining IDs are not documented.
Get daily summary data for a specific date. Returns aggregated metrics for the day including step counts, heart rate statistics, and other daily summaries.
Get heart rate observations. Returns the newest observation first, then each source's own latest.
Get the latest health observations across all metrics and sources. Returns the newest observation first, then each source's own latest.
Get health observations within a time range. Supports querying specific metrics across a date range with optional calendar offset.
Get phone sleep session data for a calendar day. Returns all stored sessions (night sleep and naps) of the most recent returned day.
Get step count observations from watch and phone sources. Returns step_count (official watch metric), step_count_sensor (cumulative since boot), and phone step count side by side without merge or precedence.
Parameter descriptions lack actionable guidance. 'metrics' parameter in latest/heart_rate/range does not explain valid metric names, how to discover them, or what happens if an invalid metric is requested. LLMs cannot infer valid values without explicit enum or discovery tool reference.
Output schemas not documented in tool definitions. Tool descriptions do not specify what fields are returned, their types, or structure. LLMs must infer output shape from code inspection, risking misuse and downstream tool chaining failures.
Error recovery guidance missing. statusSchema defines DEGRADED, NO_DATA, DENIED, UNSUPPORTED, API_MISSING, ERROR but tool descriptions do not explain when each occurs or what the LLM should do (retry, ask user, abort). Agents cannot self-correct without this classification.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2025-06-18+ | v2 |
Get a summary of today's health data including watch metrics, phone daily summaries, and sleep sessions. Combines step counts, heart rate, and other daily metrics.
calendar_offset_minutes parameter interaction underdocumented. Four tools (steps, sleep, today, daily) accept both 'date' and 'calendar_offset_minutes', but descriptions do not clarify precedence, whether both can be omitted, or how offset interacts with the default Asia/Shanghai timezone. Ambiguous dependencies invite misuse.
No pagination or result-limit guidance. Tools returning arrays (latest, heart_rate, range, daily) lack limit/offset parameters and do not document maximum result size. Large result sets risk context window exhaustion and token waste.