Loading ToolBench
Apple Health MCP server — reads Health Auto Export CSVs
Apple Health MCP provides 3 read-only tools with explicit JSON Schema input definitions and descriptions. All tools are properly named with verb-noun patterns (apple_health_*) and have basic descriptions. However, output schemas are not formally documented in code, they are only visible in the text descriptions. Parameters have type constraints (regex patterns, optional flags) but descriptions lack important context about defaults, edge cases, and how tools relate to each other. Error handling is absent: there is no guidance for when CSV files are missing or malformed. The server uses STDIO transport, which is a hard cap at 50 points for protocol readiness, significantly limiting production viability.
Get Apple Health daily summary: steps, energy, HR, HRV, sleep stages, body comp, workouts
Get daily health metrics for a date range (steps, HR, HRV, sleep, weight)
Get workout sessions for a date
Output schemas not formally documented. The code returns structured objects (DailyMetrics, Workout[], trend data) but the MCP tool registration does not declare outputSchema. LLMs cannot predict what fields to expect without trial and error.
Missing error recovery guidance. When CSV files do not exist (e.g., no workouts on a given date), parseMetrics() and parseWorkouts() return null or empty arrays silently. The tool descriptions do not explain what to expect or how to handle these cases. Pattern: recovery-guide.
Parameter descriptions lack detail on defaults and constraints. The 'date' parameter states 'defaults to today' but the code shows today() is only called in the tool handler, not in the input schema. 'days' parameter for trends has no min/max bounds stated in the description, risking unbounded lookback requests.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 51 | - | v1 |
No tool dependency documentation. The three tools read the same data (Daily Export CSVs). There is no guidance on which tool to call first or in what order for a multi-step health query. Pattern: tool-chain.
Missing required description for optional parameters. The 'date' and 'days' parameters are optional, but the descriptions do not clearly state what the default behavior is if omitted. For 'date', the code calls today(), but this is not explicit in the parameter description.
Incomplete field naming consistency. The 'date' parameter accepts YYYY-MM-DD strings with a regex pattern, but the response objects use flat snake_case field names (e.g., 'sleep_deep', 'active_energy'). No documented field mapping or response schema.