Loading ToolBench
Server has 7 well-named tools with complete input schemas and descriptions. All tools follow verb_noun naming (get_*) and are READ_ONLY. Descriptions are adequate (100-200 chars, within baseline 194 avg). However, output schemas are NOT documented, LLMs cannot predict response structure for planning. Parameter descriptions are present but lack constraints (enums, ranges, format specs). No error handling guidance. Token/open_id are exposed as parameters (security risk). Missing pagination for list-returning tools (get_workouts, get_daily_data). Date format constraints stated in descriptions but not enforced via schema patterns.
Check if user is currently bound/linked to the COROS platform
Get daily health data: sleep times, resting heart rate, HRV, steps, calories. Date range max 30 days, max 3 months back.
Convenience tool: Get recent running workouts (outdoor + trail runs) for the last N days with formatted stats.
Get a training summary for a period: total distance, time, calories, number of workouts, breakdown by sport type.
Get COROS user profile info: nickname, total run distance, calories, total run time
Get the .fit file download URL for a specific workout by labelId
Output schemas not documented. LLMs cannot predict response structure, fields, or types. Breaks downstream tool chaining and forces agents to guess field names.
Credentials (token, open_id) exposed as tool parameters. These will be logged in agent traces and prompt history. Must use server-side secret injection via environment or vault.
No pagination support. get_workouts and get_daily_data return unbounded lists. Large result sets blow context window. Missing limit, offset, and total_count in response.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Get workout records for a date range (max 30 days, max 3 months back). Returns list of activities with distance, pace, duration, calories, etc.
Parameter constraints stated in descriptions but not enforced via schema. Date format (YYYYMMDD), days range (max 30), and date range limits (max 30 days, max 3 months back) lack JSON Schema validation.
No error handling guidance. Responses do not indicate what to do on failure (retry, ask user, fatal). No recovery paths for common errors (invalid token, user not found, rate limit).