Workout Tracker MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_HOST | No | Host for HTTP server (default: 0.0.0.0). | |
| MCP_PORT | No | Port for HTTP server (default: 8000). | |
| MCP_TRANSPORT | No | Transport mode: stdio or http (default: stdio). | |
| AWS_ACCESS_KEY_ID | Yes | Your AWS Access Key ID for DynamoDB access. | |
| AWS_DEFAULT_REGION | Yes | AWS region for DynamoDB (e.g., us-west-2). | |
| AWS_SECRET_ACCESS_KEY | Yes | Your AWS Secret Access Key for DynamoDB access. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| log_workoutB | |
| calculate_volumeA | |
| save_workout_plan_to_dynamodbA | |
| get_workout_plan_from_dynamodbA | |
| log_workout_session_to_dynamodbA | |
| get_all_exercisesA | |
| get_exercise_by_idA | |
| search_exercisesA | |
| get_exercises_by_body_partA | |
| get_exercises_by_target_muscleA | |
| get_exercises_by_equipmentA | |
| list_body_partsB | |
| list_target_musclesA | |
| list_equipmentA | |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| workout_plan_prompt | Generate a comprehensive, science-based workout plan with structured output for DynamoDB storage Args: goal: Primary training goal (strength, hypertrophy, powerlifting, endurance, athletic_performance) experience_level: Training experience (beginner, intermediate, advanced, elite) training_frequency: Days per week available for training (3-6) session_duration_min: Available time per session in minutes (45-120) equipment_available: Equipment access (full_gym, home_gym_barbell, home_gym_dumbbells, bodyweight_only) age: User's age for recovery and volume considerations gender: Biological sex for hormonal/recovery considerations (male, female) current_maxes: Current 1RM estimates (e.g., "Squat: 315, Bench: 225, Deadlift: 405") injuries_limitations: Any injuries or movement restrictions program_duration_weeks: Length of program (4-16 weeks recommended) Returns: A detailed prompt for generating a periodized workout plan with JSON-structured output |
| format_workout_plan | Transform DynamoDB workout plan JSON into client-friendly, printable format Args: workout_plan_json: JSON string of workout plan in DynamoDB schema format (the output from workout_plan_prompt) Returns: A prompt that transforms technical JSON into a beautiful, readable workout plan that clients can print and take to the gym |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| get_exercise_list | Returns a list of available exercises |
TDQS
Scored across 14 tools
log_workout and log_workout_session_to_dynamodb both log workouts but at different levels of detail and persistence, creating real ambiguity for an agent. The multiple get_exercises_by_* filters are largely distinct but could be confused with search_exercises, especially since they all return exercise lists.
Tool names consistently use snake_case with a verb_noun pattern, such as list_*, get_*, log_*, and save_*. Minor deviations like calculate_volume (no resource object) and the long 'to_dynamodb'/'from_dynamodb' suffixes are still readable and predictable.
With 14 tools, the count is on the higher end but still within a reasonable scope for an exercise database combined with workout plan and session logging. A few tools, especially the redundant log_workout, could be consolidated, but the overall count is not excessive.
The server provides save/get for workout plans and a session logger, but lacks list, update, and delete operations for plans or logs. There is also no way to retrieve a user's workout history, leaving significant lifecycle gaps that would cause agent failures in common tracking workflows.