Loading ToolBench
MCP server providing access to Boostcamp fitness API, enabling retrieval of user profiles, training history, programs, payment information, and dashboard metrics.
Mixed-quality tooling with strong naming conventions but inconsistent parameter descriptions and missing output schemas. All 12 tools start with action verbs (get_, list_) as required. Nine tools are READ_ONLY with minimal required parameters, reducing schema complexity. However, most tools lack documented output schemas, and parameter descriptions vary significantly in completeness. get_training_history has excellent documentation with detailed parameter constraints and expected return structure; most other tools rely on implicit API documentation. No error handling guidance provided beyond generic exception catching. This is a READ_ONLY API wrapper, which simplifies the security surface, but the tool definitions lack the specificity needed for LLM reasoning at production scale.
Get training volume chart data.
Get muscle group distribution data.
Get a summary of active/recent user programs.
Get dashboard summary statistics (total workouts, weight, streak).
Get the current user's profile and settings from Boostcamp.
Get the user's payment history.
Output schemas not documented. LLMs cannot predict response structure or plan downstream tool calls. Most tools return raw API JSON wrapped in str(), but the shape of that JSON is not documented in the tool definition.
Minimal parameter descriptions for 11/12 tools. Parameter names alone are insufficient for LLM reasoning. For example, 'timezone_offset' exists on four tools (get_home_summary, get_home_programs, get_home_chart, get_home_muscle) with identical descriptions, but the default and constraints are only documented in get_training_history. LLMs cannot infer parameter semantics from name alone.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
Get detailed information about a specific program by its ID.
Get the user's workout history, filtered and paginated to stay compact. Args: start_date: Only workouts on/after this date, "YYYY-MM-DD" (inclusive). end_date: Only workouts on/before this date, "YYYY-MM-DD" (inclusive). detail: "summary" (date, program, exercises, total volume — default) or "full" (adds every set with weight/reps/RPE). page: 1-based page number, newest workouts first. page_size: Workouts per page. Capped at 100 for summary, 25 for full. timezone_offset: Timezone offset in minutes (default -300 / EST). Returns JSON with `workouts`, `pagination` (incl. has_more), `filters`, and a `hint` describing how to fetch more (next page, date range, or full detail).
List all available programs with pagination and optional keyword search.
List blog posts with pagination.
List the custom exercises created by the user.
List all fitness programs the user is currently enrolled in.
No error handling guidance in tool descriptions. When handle_api_call returns 'Authentication Error: ...' or 'Error: ...', LLMs have no recovery path documented. No guidance on whether to retry, call a refresh endpoint, or ask the user to re-authenticate.
get_training_history has a bug: 'api = get_api_client()' should be 'api = await get_api_client()'. This will cause a coroutine object to be passed instead of an BoostcampAPI instance, failing at runtime on every call.
Pagination parameters (page, page_size) present on list_all_programs and list_blogs but not documented with constraints. Baseline rubric requires stating min/max for numeric parameters. No documentation of whether page is 0-indexed or 1-indexed, or what happens on an out-of-range page number.
list_all_programs accepts 'keyword' parameter for search but no description of what fields are searched, whether search is case-sensitive, or whether partial matches are supported. Parameter description is too minimal.