Loading ToolBench
Model Context Protocol server that proxies the Prog Strength API.
Strong foundation with comprehensive tool coverage and detailed descriptions. All 13 tools have clear names following verb_noun convention and substantive descriptions (100-400+ chars). Input schemas are present with type definitions and parameter descriptions. However, output schemas are not explicitly documented in the visible code, and some parameter relationships lack clarity. Error handling guidance is present but inconsistent across tools. No tool annotations (readOnlyHint/destructiveHint) detected despite clear WRITE vs READ_ONLY risk classifications.
Get the full detail for one activity of any type.
Per-day macro totals, one row per user-local calendar date in the supplied IANA `timezone`. Use this for "how did my macros look this week?" prompts. Pass exactly one of `date` (single day) or `start_date`+`end_date` (range), all YYYY-MM-DD — the API validates the one-of constraint. Empty days do not appear in the response; fill gaps client-side only if you need a dense series for comparison.
Read the user's daily macro targets (protein, carbs, fat, calories). The API always returns 200. When the user has never set goals the response has all four numbers at 0 and null created_at / updated_at — that's the "not set yet" signal. The agent should read those nulls as "the user hasn't picked targets" and say so in conversation rather than answering with zeros. Pair with `get_daily_macros` for "how am I doing today?" prompts: read both, do the comparison in prose. There is no precomputed comparison tool by design.
List the calling user's activities across every type, most recent first. Identity is sourced from the inbound MCP session's Authorization header. Use this for runs, walks, rides, and mixed histories; for a strength-only view, list_workouts is the strength-typed shortcut. This tool deliberately exposes NO date-range parameters: constructing UTC bounds for a user-local day is a known bug source, so never fabricate timestamps to scope this list. For date-scoped questions ("what did I run on Tuesday?", "activities last week") prefer get_training_snapshot, which takes a timezone plus local YYYY-MM-DD dates and resolves the day boundaries server-side. Alternatively, call this list with a generous `limit` and filter the returned `start_time` values yourself.
Output schemas not documented in visible code. Tool descriptions explain what is returned in prose, but formal JSON Schema output definitions are absent. LLMs cannot reliably plan downstream tool calls without knowing return field names and types.
Tool annotations missing. Risk classifications (WRITE vs READ_ONLY) are documented in metadata but not exposed as tool annotations (destructiveHint, readOnlyHint, idempotentHint). Agents cannot infer safety properties from the tool definition alone.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | <=2025-11-25 | v2 |
List the user's blood-pressure entries, most recent first.
List the user's bodyweight entries, most recent first. Pair with get_daily_macros (or list_nutrition_log) to comment on weight trajectory against caloric intake — deficit, surplus, or roughly at maintenance.
List the shared, admin-curated exercise catalog. Call this before create_workout to discover the exact slug IDs the API expects — natural-language exercise names are not accepted there. Both filters are optional; pass them to narrow the catalog when the user describes a focused session (e.g., a quad day).
List the user's nutrition log entries, most recent first. Each entry carries denormalized macros and a reference to the source pantry item. Dates are interpreted in the supplied IANA `timezone`; pass either `date` for a single day or `start_date`+`end_date` for a range (the API validates that exactly one shape is supplied). For totals over a day or a range, use get_daily_macros — it returns sums computed by the API. Do not list entries and sum macros yourself; arithmetic across many items is unreliable.
Log a new activity of any registered type for the calling user. Identity is sourced from the inbound MCP session's Authorization header (the user's JWT); there is no user_id parameter. The `details` payload is type-specific and forwarded to the API verbatim, where the type's descriptor validates it: - endurance types ('running', 'walking', 'cycling', 'hiking') expect `{"distance_meters": <positive number>, ...}` — distance is required for these; optional keys include `avg_pace_sec_per_km`, `elevation_gain_meters`, `environment` ('outdoor'|'indoor'). - 'other' tolerates absent/empty details (a zero-distance entry). - 'strength_training' expects `{"exercises": [{"exercise_id": <slug>, "sets": [{"reps", "weight", "unit"}], "superset_group"?, "notes"?}]}` — exercise order comes from list position. Prefer create_workout for this shape. An unknown `activity_type` or invalid `details` surfaces as an error whose message explains what the API rejected.
Log a single blood-pressure reading (systolic/diastolic, optional pulse).
Log a single bodyweight reading. Returns the created entry. There's no update tool — to fix a bad reading, the user deletes it in the UI and logs the right value. The audit trail stays clean.
Log everything the user ate in one message as a single call. Collect EVERY food the user mentioned into one `items` list rather than calling this tool once per food. Each item carries its own `meal` bucket and optional `consumed_at`, so one call can span breakfast + a snack or backfill several entries at different times. For each item, check `list_pantry_items` first: if a saved pantry item or recipe matches, use kind "pantry"/"recipe" with its id and a `quantity` of servings/batches (5 eggs against a 1-egg pantry item is quantity=5; half a recipe is 0.5). Otherwise use kind "custom" with the food's name and your best-estimate total macros as the user ate them. Logging is best-effort: each item is logged independently and the response's `results`/`logged`/`failed` report which items (if any) did not log, so you can tell the user. `meal` is one of breakfast, lunch, dinner, snack. `consumed_at` is an RFC3339 UTC timestamp; omit it to default to now.
Replace the user's daily macro targets with the supplied four numbers. Set-replacement semantics: pass ALL four values every call, even when the user only asked to change one. Workflow for "bump my protein to 200": 1. Call `get_macro_goals` to read the current values. 2. Apply the user's diff to the relevant field. 3. Call this tool with all four numbers, the unchanged three taken verbatim from step 1. The API does not enforce calorie consistency with the macro breakdown — the user is allowed to set protein=180/carbs=300/fat=70/calories=2400 even though those macros sum to 2,550 kcal. Mention the mismatch in your reply if the user might benefit from knowing, but do not refuse the write.
get_activity description is minimal (60 chars). Lacks context on when to use it vs list_activities, what fields are returned, or whether it requires prior discovery. Should explain: 'Retrieve full details for a specific activity by ID. Use after list_activities to get detailed metrics, notes, and type-specific fields.'
Mutually exclusive parameter groups not clearly documented. log_consumption_batch items have conditional logic (kind='pantry'|'recipe'|'custom' determines which fields apply), and list_nutrition_log / get_daily_macros require exactly one of (date) or (start_date+end_date). Descriptions mention this but could be more explicit with examples.
Error recovery guidance is present but uneven. log_activity and set_macro_goals provide detailed error explanations, but list_exercises only states 'Invalid values return a 400 from the API' without guidance on valid muscle_group/equipment enums. Agents need actionable error messages.