Loading ToolBench
Coros MCP has solid naming conventions (verb_noun pattern throughout), generally clear descriptions aligned with functionality, and comprehensive JSON schemas with proper type constraints and enums. However, several tools lack sufficient output schema documentation, some parameter descriptions are minimal, and error handling guidance is sparse. The server demonstrates good intent around tool composition (auth, discovery, CRUD) and properly gates tools via _TOOLSET environment variable. Main weaknesses: output schemas for complex operations (create_workout, schedule_workout) are not explicitly documented in the code; error messages lack recovery guidance; and a few tools have thin descriptions that could better explain prerequisites and dependencies.
Authenticate with Coros using email and password. Returns StoredAuth (access_token, mobile_access_token, region, user_id, timestamp). Stored for future calls.
Authenticate with Coros mobile API only (for sleep data). Returns StoredAuth with mobile_access_token.
Create a new structured workout with steps (warm-up, intervals, cooldown, recovery, etc.). Steps can contain repeating intervals. Returns the new workout with Coros-assigned IDs.
Delete one or more workouts by ID.
Get activities (runs, cycles, swims, etc.) for a date range, with pagination.
Get detailed data for a single activity (splits, average pace/hr/cadence, elevation, power, efficiency, max speed, max altitude).
Output schemas not documented in code for complex tools. create_workout, schedule_workout, and other write operations describe what they do but do not explicitly specify the structure of their return values. LLMs cannot plan downstream calls or extract needed IDs without knowing response shape.
Thin parameter descriptions on discovery and utility tools. Tools like list_planned_activities, list_sport_types, get_exercises lack details on expected size of results, pagination limits, and filtering. Description text should state 'Returns up to N items; use pagination for larger datasets' to set LLM expectations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 70 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get local cache coverage: record counts and date ranges for daily_records, sleep_records, and activities.
Get daily metrics (steps, distance, calories, heart rate average/min/max, training load) for a date range.
Get exercise names, types, and muscle groups for a sport type (used when building workouts).
List all available tools and their descriptions.
Call any Coros API endpoint directly (advanced/escape hatch). Path is appended to the base URL; params and json body are passed through.
Get sleep records (total hours, deep/light/rem/awake durations, sleep score) for a date range.
Get planned/scheduled activities (workouts) for a date range.
List available sport types (running, cycling, swimming, etc.) for building workouts.
Remove a scheduled workout from the training calendar.
Add a workout (created or fetched) to the training calendar for a specific date.
Full historical backfill: pull all data from Coros (12-week chunks) and store locally. Returns sync counts (daily_records, sleep_records, activities) and cache coverage.
Call any Coros API endpoint and update the local cache with the response (advanced). Used after direct API updates to sync cache.
Error handling lacks recovery guidance. Code includes _is_auth_error() and _run_with_auth() retry logic server-side, but tool descriptions do not explain to the LLM what to do on auth failures, network timeouts, or Coros API rejections. Error messages should be actionable, e.g. 'Re-authentication failed; check COROS_EMAIL and COROS_PASSWORD in .env or call authenticate_coros manually.'
Escape hatch tools (get_raw, update_raw) lack validation and safety guardrails. These advanced tools accept arbitrary API paths and parameters, bypassing schema validation. No description warns about misuse, no dry-run mode exists, and no permission gating prevents unauthorized API calls. LLMs can invoke undocumented endpoints or trigger unintended side effects.
create_workout step parameter structure underdocumented. The 'steps' array is described as 'List of workout steps (each with duration_minutes/duration_meters/duration_open and optional intensity, recovery, repeat)' but no JSON schema or example shows the exact shape of each step object. LLMs must guess at nested structure, field names, and valid values.
schedule_workout and remove_scheduled_workout require opaque IDs (plan_id, plan_program_id, entity_id) with no clear user-facing way to obtain them except via list_planned_activities. No alternative lookup by name, date, or sport type. This forces multi-step discovery and wastes agent tokens.
Credentials handled securely via env vars (COROS_EMAIL, COROS_PASSWORD) and keyring, but no explicit warning in tool descriptions against passing plaintext passwords in calls. While the server does accept email/password in authenticate_coros for manual auth, there is no reminder that these are sensitive and will be logged.