The chat as a training planner

A language model plans a training week surprisingly well. It just doesn't know how the last one went.

Anyone who trains for triathlon, running or road cycling as a hobby plans around an everyday life that no training app has a field for. Tuesday is the swim club, Thursdays belong to the kids, and at the weekend there is sometimes a birthday and sometimes a ride with friends in the way. You tell a language model that in two sentences. It moves the sessions around until the week fits, and while doing so explains why the long run shouldn't come straight after the hard bike day.

That is the strength of the chat as an interface. It takes constraints in everyday language, asks when something is unclear, and changes the plan when your back starts acting up on Wednesday. No form can do that.

Where it falls apart

Do this for a few weeks and you run into four problems. None of them has anything to do with how intelligent the model is.

The model doesn't know the data. So every week you copy screenshots from Garmin Connect into the chat, sometimes a CSV file, sometimes the summary from intervals.icu. That takes time, and something is always missing. Was my resting heart rate elevated today? How many kilometres did I cover in the last four weeks? Without the numbers the model guesses how much load you are carrying.

It makes things up when it doesn't know. This is the well-known part. A language model answers fluently even when it doesn't know the answer. With training questions, an invented rule of thumb sounds just as convincing as a finding with evidence behind it. Ask for a source and you will often get a study that doesn't exist in that form: plausible title, plausible authors, plausible year.

It forgets. Every new conversation starts from zero. The irritated Achilles tendon from the spring, the goal of a middle distance race in June, the 45 minutes that are all Wednesday allows: you tell it all over again each time, or it sits in a project prompt that slowly goes out of date.

Its training knowledge has no reference. The model learned sports science from its training data, unevenly and mixed with forum wisdom. Whether "80/20" holds at six hours a week or only has evidence for professionals training twenty hours, it cannot say. It doesn't know where it knows this from.

The sessions themselves don't arrive on their own either. What you ran yesterday you have to tell the model, and nobody checks whether the planned session got done.

The approach: no chat of its own

The obvious solution would be an app with a built-in coach: its own chat, its own model, its own persona. That is how I started coachframe.ai, and that is where I realised what I was rebuilding. Weighing options, asking back and replanning are things Claude and ChatGPT already do very well. A chat of my own would have to replicate that and would still have less at hand: no web research, no files and calendars, none of the other connections someone has long since set up in their client. I didn't want to reinvent the wheel, and that is why I stopped building coachframe.

With training mcp I did it the other way round. There is no chat of its own and no calls of its own to a language model. The model belongs to the user, who picks it and pays for it. training mcp is an MCP server that gives this model two things it lacks: the user's own training and vitals data, and domain knowledge with sources it can refer to.

The short version from the first project description still stands above everything:

A language model without data guesses how much load the athlete is carrying. A language model without a knowledge base invents studies. Both are noticed quickly in a training context and cost trust.

The Model Context Protocol is the right way to do this. A client such as Claude or ChatGPT connects to the server, receives a list of tools and calls them during the conversation when it needs them. Ask about last week and the model fetches the sessions. Ask about load and it fetches the training load. The numbers come from the database, not from the model's memory.

What it looks like in a conversation

An example, shortened, on a Monday:

Me: Plan my week. On Wednesday I'm on a business trip, hotel without a pool.

Model: [calls planning-context, readiness and training-load]
       Your resting heart rate has been above your normal range for two
       days, your HRV below it. That's an indication, not a diagnosis.
       After the race on Saturday it fits the picture. I'd keep Tuesday
       easy and take the swim at the club. Wednesday at the hotel,
       30 minutes of strength without equipment, the exercises are in
       your profile.
       ...

Three things happen there that weren't possible before. The model knows about the business trip because it is stored as an absence, and about the fixed appointments because they are in the weekly template. It reads resting heart rate and HRV from the watch data instead of asking for them. And the assessment "above the normal range" doesn't come from the model. The server calculated it using a rule with a name and a version.

At the end the model saves the week through a tool. The sessions are then in the account, and as soon as the watch delivers a recording, the server matches up which of them are done.

What the series covers

The approach is quickly told. It gets interesting with the question of how to actually close the four gaps from above, and there are three more parts for that:

• Part 2: Data in the chat. How sessions, vitals, goals and complaints get into the conversation via MCP. With intervals.icu, Garmin, a dedicated app for Apple Health, and the question of what happens when the same session arrives through three channels.
• Part 3: Training knowledge with sources. A compendium of a little over 2,000 findings, each with evidence strength and source, and the work of getting the model to look there in the first place.
• Part 4: Analytics next to the chat. Why charts covering half a year don't belong in a conversation, and why the web interface still doesn't turn into a coach.

What it doesn't prevent

One limitation belongs at the start so it doesn't get lost: the inventing can't be prevented entirely. A language model remains a language model, and if it doesn't call a tool, it answers from memory. training mcp shifts the probabilities. With real data and findings with sources in its context, the model invents far less often, and when it refers to a finding, you can look up which one it was.

That is the difference between a tool you have to distrust with every number and one you can plan a week with.

Call to Action

training mcp is currently in beta with a small group of users. The public launch is in early November. Everything else is at https://training-mcp.app.

The next part is about the engine room: how the data gets from the watch into the chat. If you are building an MCP server yourself and are stuck somewhere, feel free to get in touch.