Loading ToolBench
Model Context Protocol (MCP) server for the Intervals.icu API — activities, wellness, power curves & training calendar
Solid foundation with 17 well-named tools covering a coherent domain (Intervals.icu fitness API). All tools have descriptions and input schemas with types. However, descriptions are often terse (many under 100 chars), parameter descriptions lack detail on constraints/formats, and output schemas are not documented. Error handling guidance is minimal. No tool annotations (readOnlyHint/destructiveHint) despite clear risk classifications. Composition is good, tools chain naturally (get_activities → get_activity_details → get_activity_streams). Security: API keys are optional parameters (should be server-injected only). Naming follows verb_noun convention consistently.
Create a new custom item for an athlete on Intervals.icu.
Delete a custom item for an athlete from Intervals.icu.
Delete an event for an athlete from Intervals.icu.
Delete events for an athlete from Intervals.icu in the specified date range.
Get a list of activities for an athlete from Intervals.icu. Each activity includes a 'Sync:' line with a derived data-completeness verdict, last-sync time (icu_sync_date) and upstream source. If the verdict is not 'complete' (e.g. analysis pending or streams still syncing), treat the metrics as provisional and caveat or re-check later instead of answering confidently from partial data. Args: athlete_id: The Intervals.icu athlete ID (optional, uses the configured default) api_key: The Intervals.icu API key (optional, uses the configured default) start_date: Start date in YYYY-MM-DD format (optional, defaults to 30 days ago) end_date: End date in YYYY-MM-DD format (optional, defaults to today) limit: Maximum number of activities to return (optional, defaults to 10) include_unnamed: Whether to include unnamed activities (optional, defaults to false)
API keys exposed as optional tool parameters instead of server-side secret injection. Credentials in tool params leak into agent logs and traces.
Destructive tools (delete_event, delete_events_by_date_range, delete_custom_item) lack confirmation/dry-run support and have no tool annotations (destructiveHint). Agents can delete data without safeguards.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Get detailed information for a specific activity from Intervals.icu. Includes a 'Sync & Data Completeness' section built from native API signals (analyzed, icu_sync_date, icu_sync_error, analysis_issues, stream_types, source). 'Data Complete' is a derived verdict: if it is not 'complete', the activity may still be syncing or processing — treat metrics as provisional and re-check later.
Get interval data for a specific activity from Intervals.icu. This endpoint returns detailed metrics for each interval in an activity, including power, heart rate, cadence, speed, and environmental data. It also includes grouped intervals if applicable.
Get stream data for a specific activity from Intervals.icu.
Get power curves for an athlete from Intervals.icu.
Get detailed information for a specific custom item from Intervals.icu.
Get custom items (charts, custom fields, zones, etc.) for an athlete from Intervals.icu.
Get detailed information for a specific event from Intervals.icu.
Get events for an athlete from Intervals.icu. Args: athlete_id: The Intervals.icu athlete ID (optional, uses the configured default) api_key: The Intervals.icu API key (optional, uses the configured default) start_date: Start date in YYYY-MM-DD format (optional, defaults to today) end_date: End date in YYYY-MM-DD format (optional, defaults to 30 days from today)
Get the gear catalog (bikes, shoes, etc.) for an athlete from Intervals.icu. Returns one line per gear item with id, type, name, and basic stats. The result is cached for the MCP process lifetime; pass refresh=true to re-fetch.
Get wellness data for an athlete from Intervals.icu.
Post event for an athlete to Intervals.icu. If event_id is provided, the event will be updated instead of created.
Update an existing custom item for an athlete on Intervals.icu.
Output schemas not documented. LLMs cannot predict response structure, forcing them to guess field names for downstream tool calls. Breaks tool chaining.
Many parameter descriptions are generic or missing constraint details. E.g., 'stream_types' says 'Comma-separated list' but does not enumerate valid types. 'limit' lacks min/max bounds.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications. MCP clients cannot auto-gate dangerous operations.