Loading ToolBench
MCP server providing access to Ultrahuman Partnership API data for health metrics including sleep, movement, heart rate, glucose, and other biometric data
The server provides 6 health metrics tools with reasonable naming conventions (verb_noun pattern: get_*) and basic parameter documentation. However, there are significant gaps in output schema documentation, error handling guidance, and parameter constraint clarity. Tools follow a consistent pattern but lack the rigor expected for production-grade agent tooling. No tool annotations present (readOnlyHint, destructiveHint, idempotentHint). Date format validation is present in code but not reflected in schema constraints. Error responses return structured objects with success flags but lack actionable recovery guidance.
Get comprehensive health metrics for the default user (from environment) on a specific date.
Get glucose-related metrics for a user on a specific date.
Get heart-related metrics for a user on a specific date.
Get movement and activity data for a user on a specific date.
Get sleep-specific data for a user on a specific date.
Get comprehensive health metrics for a specific user and date from Ultrahuman.
Output schemas not documented. Tools return Dict[str, Any] with no description of response structure, field types, or required fields. LLMs cannot plan downstream operations or extract specific metrics without knowing response shape.
Date parameter lacks format constraint in schema. Description mentions 'YYYY-MM-DD format' but no regex pattern or formal schema constraint is visible. Code validates at runtime, but LLMs cannot enforce constraints without schema-level declarations.
Error responses lack actionable recovery guidance. Errors return {success: false, error: string} but do not suggest next steps (e.g. 'Missing ULTRAHUMAN_AUTH_KEY. Contact admin to set environment variable.' or 'Invalid date format. Use YYYY-MM-DD.') per pattern:recovery-guide.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 72 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
No tool annotations present. Tools are read-only (no state mutations) but lack readOnlyHint annotation for clarity. This forces LLMs to infer idempotency and retry safety.
Derived metrics tools (get_sleep_data, get_movement_data, get_glucose_metrics, get_heart_metrics) call get_user_metrics internally, then extract subsets. Return payloads are identical in structure but differ only in which metrics are included. This violates composition principle, either return full metrics with labeled subsets, or document clearly what fields each tool returns.
No pagination support. get_user_metrics returns full nested metrics object with no limit or next_cursor. For users with high-frequency data (e.g. heart rate samples), responses could exceed context windows.
Parameter descriptions are present but lack specificity. Email parameter shows example 'user@example.com' in description, which violates the rule against embedding example values (LLMs reuse them literally). Use only formal description: 'User email address (RFC 5321 format)'.