Overview
Trainerrr is a fitness app. You plan your training weeks, log your sessions, track your nutrition, and keep a journal of your progress in one place, on your phone.
That is the visible product. Trainerrr also ships an MCP server that gives an AI assistant like Claude a structured way to read and write fitness data on the user's behalf.
Once it is connected, you can talk to Claude the way you would talk to a personal trainer who already knows your history.
What the app does
Trainerrr follows the same loop each week.
- Plan your training week with named workout days, exercises, sets, and reps.
- Run the session from your phone and log each set as you go.
- Review your journal, weekly check-ins, and progress over time.
Nutrition sits alongside training. You can log meals, search Open Food Facts, and track daily intake against a calorie target. Bodyweight check-ins, training notes, and weekly summaries give you a record you can use.
The app has no social feed or advertising layer. It is a planning and logging tool for people who already care about staying consistent.
The MCP layer
MCP stands for Model Context Protocol. It is an open standard that lets AI models connect to external data sources and take actions through a defined set of tools.
Trainerrr exposes an MCP server at mcp.trainerrr.xyz/mcp.
Once you connect it to Claude Desktop, Claude Code, or any other MCP-compatible client, the model gets access to more than 20 tools tied directly to your account data.
It can:
- Read your workout history and weekly summaries.
- Search your exercise library and create custom exercises.
- Build a complete workout plan and save it to your account.
- Log a workout from a natural language prompt.
- Search Open Food Facts and log meals.
- Pull today's nutrition totals and remaining calories.
- Read your training journal and weekly check-ins.
- Update weekly workout targets and daily calorie goals.
Authentication runs through OAuth, so the user signs in once and the server issues a token scoped to that account. Tool writes are rate-limited, and the model only touches the user's own data.
What this looks like in practice
Ask Claude for a 4-day push, pull, legs split for an intermediate lifter, and it can check the existing exercise library, create missing exercises, and call create_workout_plan in one back-and-forth. When you open the app, the plan is already there.
After a session, you can say:
Log my workout. I did Romanian deadlifts 3x8 at 80kg, leg press 4x10 at 120kg, leg curl 3x12 at 40kg. Started about 45 minutes ago.
Claude can resolve the exercises, call log_workout, and the session appears in your history immediately.
For nutrition, you can ask:
What did I eat today and how many calories do I have left?
Claude calls get_nutrition_day, reads your target and logged entries, then gives you a clean breakdown without forcing you back into the app UI.
The workflow runs through the same Claude client the user already uses.
Why MCP fits this product
Natural language is faster for some jobs. Typing "log my workout" takes less effort than opening the app, finding the plan, tapping through each exercise, and entering sets manually.
The product question is which tasks benefit from natural language access and how little of the system the model needs to reach.
Trainerrr exposes typed tools with OAuth, rate limits, and clear read and write semantics. The model uses a predictable API instead of a custom AI layer or separate prompt logic for every feature.
There are a few practical lessons in that decision.
Keep tools narrow
Each MCP tool in Trainerrr does one job. log_workout logs a workout. get_nutrition_day returns one day of nutrition data. Narrow tools compose better and leave the model less room to guess about intent.
Give the model its own interface
The MCP layer is shaped differently from the mobile UI. A model needs bulk lookups, structured inputs with clear types, and deterministic outputs it can reason about. A polished mobile flow solves a different problem.
Authentication comes first
Without OAuth, an MCP server is either too open or too limited to matter. Getting authentication right before launch is much easier than trying to retrofit it after users already rely on the data.
Treat destructive actions seriously
The data your AI touches is the same data your users care about. There is no separate AI sandbox. If Claude calls delete_workout_plan, that plan is gone. Destructive tools need the same care you would give a mobile UI with no undo button.
Product boundaries
Trainerrr is a fitness planning and logging product, not a medical tool or a replacement for a coach, physiotherapist, or nutritionist. Its MCP server is a structured interface to account data rather than a general-purpose AI trainer. Claude handles the reasoning. The Trainerrr data model remains personal and belongs to one user account.
When MCP earns a place
AI product design starts by identifying where natural language works better than a traditional UI, then exposing only the surface required for those tasks.
For Trainerrr, the mobile app handles the active session experience. The MCP server handles the planning, logging, and review workflows where AI adds speed.
MCP is worth prototyping when users manage structured personal data over time. Trainerrr showed how much shorter a workflow can become when a user can describe the result instead of tapping through each step.
Trainerrr is live at trainerrr.xyz. The MCP server is live at mcp.trainerrr.xyz/mcp.