Loading ToolBench
Mi Fitness MCP has 12 well-named tools with clear verb-noun patterns (get_, query_, sync_, summarize_). All tools have descriptions (avg ~40 chars, baseline 194 chars) and explicit JSON schemas with enums and required fields. However, descriptions are uniformly terse (10-30 chars), providing minimal context for LLM tool selection. Parameter descriptions are entirely absent, the schema declares types and enums but no text explaining what each parameter controls or when to use it. No output schemas are documented, forcing LLMs to infer response structure. Error handling is minimal; no recovery guidance or actionable error messages visible in code. Tool composition is sound (single responsibility, clear naming), but parameter documentation gaps and missing output schemas significantly limit LLM reasoning quality.
Compare workout totals between two date ranges
Check connection status
Get daily activity summary
Get data coverage
Get user profile information
Get personal workout records for a date range
Query body measurements
All parameter descriptions are missing. Schema declares types and enums but provides no text explaining what each parameter controls, when to use it, or expected format. LLMs cannot infer parameter semantics from names alone (e.g., 'granularity' could mean time unit, precision level, or aggregation scope).
Tool descriptions are uniformly terse (10-30 chars, baseline 194 chars). Descriptions like 'Check connection status' and 'Get user profile information' lack context for LLM selection. No explanation of when to call each tool, what it returns, or how it differs from similar tools.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | <=2025-11-25 | v2 |
Query heart rate samples
Query metric series
Query official Xiaomi workout sessions
Summarize workout volume by sport or ISO week
Synchronize Mi Fitness data
No output schemas documented. LLMs cannot plan downstream tool calls or extract required fields without knowing response structure. Baseline: 100% of A+ tools have documented return types.
No error handling guidance visible. Error responses should tell LLMs what to do next (retry, ask user, or fail). No recovery guides, error classification, or actionable error messages in code.
Date parameters (start_date, end_date) lack format specification. No description states whether format is ISO 8601, Unix timestamp, or natural language. LLMs frequently miscalculate date conversions without explicit format guidance.