Loading ToolBench
Model Context Protocol server wrapping the Intervals.icu API for read-only and gated write access to athlete activities, wellness data, and workout management
Strong schema definitions with proper JSON Schema types and descriptions for all parameters. Tool naming follows verb_noun convention (get_*, create_*, update_*, delete_*). All 8 tools have descriptions and input schemas. Write operations include safety gates (confirm, dry_run). Main gaps: descriptions are functional but brief (avg ~80 chars, below 194-char baseline); no output schemas documented; error handling lacks recovery guidance; no tool annotations (readOnlyHint/destructiveHint/idempotentHint) despite clear risk levels.
Create a new workout event with validation of workout-text format and optional idempotent retry via external_id
Delete an event, gated by confirm flag and supporting dry_run preview
Retrieve athlete activities within a date range
Retrieve detailed information about a specific activity, optionally including interval/lap breakdown
Retrieve the athlete's profile information
Retrieve athlete events (workouts, notes) within a date range, optionally filtered by category
No output schemas documented. LLMs cannot plan downstream tool calls or extract required fields without knowing response structure. Baseline: 100% of A+ tools document return types.
Tool annotations missing. Write operations (create_workout, update_event, delete_event) declare risk levels in metadata but lack MCP tool annotations (readOnlyHint, destructiveHint, idempotentHint) that inform LLM behavior.
Error handling lacks recovery guidance. No evidence of actionable error messages that tell LLMs what to do next (e.g., 'User not found. Try search_users() first'). Baseline: A+ tools categorize errors as retryable/user-fixable/fatal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
Retrieve athlete wellness data within a date range
Update an existing event with read-modify-write semantics, gated by confirm flag and supporting dry_run preview
Descriptions are functional but brief (avg ~80 chars vs 194-char baseline). Missing context on WHEN to use each tool vs similar ones. E.g., get_activities vs get_events distinction unclear from descriptions alone.
No pagination guidance in list tools. get_activities, get_events accept 'limit' but no documentation of default limit, max limit, or how to fetch next page. Baseline: tools returning lists should document pagination strategy.