Loading ToolBench
MCP server for InBody body-composition data using the mobile REST API
Four well-named tools with clear, actionable descriptions (avg 180 chars). All tools have explicit input schemas with type definitions and parameter descriptions. Tool names follow verb_noun pattern (get_*, list_*). Descriptions explain WHAT, WHEN, and WHAT to expect. Error handling is comprehensive with HTTP-specific recovery guidance. Main gaps: output schemas are not formally documented in the code; no parameter constraints (enums, ranges) despite opportunities (e.g., limit/offset bounds); no explicit idempotency or retry guidance in descriptions despite all tools being read-only.
Get the InBody user profile. Returns identity and baseline body metrics (name, gender, age, height, weight, email) useful for interpreting scan results.
Get the full metric set for a single InBody scan. Returns the complete BCA (body composition), MFA (BMI/%fat/muscle with norm ranges), and IMP (segmental/multi-frequency impedance) blocks.
Get the total number of InBody scans available for the account.
List InBody scans with headline metrics, newest first. Returns a slim summary per scan (date, weight, BMI, %body fat, skeletal muscle mass, body fat mass, total body water, equipment). Use get_scan with a scan's raw_datetime for the full metric set.
Output schemas not formally documented. Tool descriptions mention returned fields (BCA, MFA, IMP blocks) but no JSON Schema or structured type definition is visible in code. LLMs cannot reliably extract or chain results without explicit output schemas.
Pagination parameters (limit, offset) lack numeric constraints. No min/max bounds documented. LLMs may pass absurd values (limit=999999) that break API or cause timeouts. Should specify limit 1 - 100, offset ≥0.
All tools are read-only but descriptions do not explicitly state idempotency or safe-to-retry semantics. Agents need to know which calls are side-effect-free. Annotations present (readOnlyHint=true) but descriptions should reinforce this.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | <=2025-11-25 | v2 |
Error responses return JSON with 'status' and 'message' fields, but no error classification (retryable vs user-fixable vs fatal). Agents cannot determine whether to retry, ask user, or abort. HTTP 429 is retryable; 401/403 require user action; 404 is fatal, this should be explicit.
Parameter 'raw_datetime' in get_scan is opaque (YYYYMMDDHHMMSS string). Description says 'Defaults to the most recent scan' but passing None/null is not documented as the mechanism. Should clarify: 'Omit or pass null to fetch the most recent scan.'