Der Chat als Trainingsplaner

Ein Sprachmodell plant eine Trainingswoche erstaunlich gut. Es weiß nur nicht, wie die letzte gelaufen ist.

Wer im Hobby für Triathlon, Laufen oder Radrennen trainiert, plant um einen Alltag herum, der sich in keine Trainings-App eintragen lässt. Dienstag ist Schwimmverein, donnerstags sind die Kinder dran, am Wochenende steht mal ein Geburtstag und mal eine Ausfahrt mit Freunden im Weg. Einem Sprachmodell sagt man das in zwei Sätzen. Es schiebt die Einheiten so lange hin und her, bis die Woche passt, und erklärt dabei, warum der lange Lauf nicht direkt nach dem harten Radtag liegen sollte.

Das ist die Stärke des Chats als Oberfläche. Er nimmt Einschränkungen in Alltagssprache entgegen, fragt nach, wenn etwas unklar ist, und ändert den Plan, wenn am Mittwoch der Rücken zwickt. Kein Formular kann das.

Wo es auseinanderfällt

Wer das ein paar Wochen macht, stößt auf vier Probleme, und keines davon hat mit der Intelligenz des Modells zu tun.

Das Modell kennt die Daten nicht. Also kopiert man jede Woche Screenshots aus Garmin Connect in den Chat, mal eine CSV-Datei, mal die Zusammenfassung von intervals.icu. Das kostet Zeit, und es fehlt immer etwas. War der Ruhepuls heute erhöht? Wie viele Kilometer waren es in den letzten vier Wochen? Ohne die Zahlen rät das Modell, wie belastet man ist.

Es erfindet, wenn es nicht weiß. Das ist der bekannte Teil. Ein Sprachmodell antwortet flüssig, auch wenn es die Antwort nicht kennt. Bei Trainingsfragen klingt eine erfundene Faustregel genauso überzeugend wie ein belegter Befund. Fragt man nach einer Quelle, bekommt man gern eine Studie, die es so nicht gibt: plausibler Titel, plausible Autoren, plausibles Jahr.

Es vergisst. Jedes neue Gespräch fängt bei null an. Die gereizte Achillessehne aus dem Frühjahr, das Ziel Mitteldistanz im Juni, die 45 Minuten, die mittwochs nur drin sind: Das erzählt man jedes Mal neu, oder es steht in einem Projekt-Prompt, der langsam veraltet.

Sein Trainingswissen hat keine Fundstelle. Das Modell hat die Trainingswissenschaft aus seinen Trainingsdaten gelernt, ungleichmäßig und vermischt mit Forenweisheiten. Ob „80/20" bei sechs Stunden die Woche trägt oder nur für Profis mit zwanzig Stunden belegt ist, kann es nicht sagen. Es weiß nicht, woher es das weiß.

Die Einheiten selbst kommen auch nicht von allein. Was gestern gelaufen wurde, muss man dem Modell erzählen, und ob die geplante Einheit erledigt ist, prüft niemand.

Der Ansatz: kein eigener Chat

Die naheliegende Lösung wäre eine App mit eingebautem Coach: eigener Chat, eigenes Modell, eigene Persona. So habe ich coachframe.ai angefangen, und dort ist mir klar geworden, was ich damit nachbaue. Das Abwägen, Nachfragen und Umplanen erledigen Claude und ChatGPT schon sehr gut. Ein eigener Chat müsste das nachbilden und hätte trotzdem weniger zur Hand: keine Webrecherche, keine Dateien und Kalender, keine anderen Verbindungen, die jemand in seinem Client längst eingerichtet hat. Das Rad wollte ich nicht ein zweites Mal erfinden, und coachframe habe ich deshalb nicht weitergebaut.

Bei training mcp habe ich es andersherum gemacht. Es gibt keinen eigenen Chat und keine eigenen Aufrufe an ein Sprachmodell. Das Modell gehört dem Nutzer, er sucht es aus und bezahlt es selbst. training mcp ist ein MCP-Server, der diesem Modell zwei Dinge gibt, die ihm fehlen: die eigenen Trainings- und Vitaldaten und ein Fachwissen mit Belegen, auf das es sich berufen kann.

Die Kurzfassung aus der ersten Projektbeschreibung steht bis heute über allem:

Ein Sprachmodell ohne Daten rät, wie belastet der Athlet ist. Ein Sprachmodell ohne Wissensbasis erfindet Studien. Beides fällt im Trainingskontext schnell auf und kostet Vertrauen.

Das Model Context Protocol ist dafür der passende Weg. Ein Client wie Claude oder ChatGPT verbindet sich mit dem Server, bekommt eine Liste von Werkzeugen und ruft sie im Gespräch auf, wenn er sie braucht. Fragt man nach der letzten Woche, holt das Modell die Einheiten. Fragt man nach der Belastung, holt es die Trainingslast. Die Zahlen kommen aus der Datenbank, nicht aus dem Gedächtnis des Modells.

Wie das im Gespräch aussieht

Ein Beispiel, gekürzt, an einem Montag:

Ich: Plan mir die Woche. Mittwoch bin ich auf Dienstreise, Hotel ohne Pool.

Modell: [ruft planning-context, readiness und training-load auf]
        Dein Ruhepuls liegt seit zwei Tagen über deinem Normalbereich,
        die HRV darunter. Das ist ein Hinweis, keine Diagnose. Nach dem
        Rennen am Samstag passt das ins Bild. Ich würde Dienstag locker
        halten und das Schwimmen im Verein mitnehmen. Mittwoch im Hotel
        30 Minuten Kraft ohne Geräte, die Übungen sind in deinem Profil.
        ...

Drei Dinge passieren da, die vorher nicht gingen. Das Modell kennt die Dienstreise, weil sie als Abwesenheit gespeichert ist, und die festen Termine, weil sie in der Wochenvorlage stehen. Es liest Ruhepuls und HRV aus den Daten der Uhr, statt danach zu fragen. Und die Einordnung „über dem Normalbereich" stammt nicht vom Modell. Der Server hat sie nach einer Regel mit Namen und Fassung gerechnet.

Am Ende speichert das Modell die Woche über ein Werkzeug. Die Einheiten stehen danach im Konto, und sobald die Uhr eine Aufzeichnung liefert, gleicht der Server ab, was davon erledigt ist.

Was die Serie zeigt

Der Ansatz ist schnell erzählt. Interessant wird es bei der Frage, wie man die vier Lücken von oben tatsächlich schließt, und dafür gibt es drei weitere Teile:

• Teil 2: Daten im Chat. Wie Einheiten, Vitalwerte, Ziele und Beschwerden über MCP ins Gespräch kommen. Mit intervals.icu, Garmin, einer eigenen App für Apple Health und der Frage, was passiert, wenn dieselbe Einheit über drei Wege ankommt.
• Teil 3: Trainingswissen mit Beleg. Ein Kompendium aus gut 2.000 Befunden, jeder mit Belegstärke und Quelle, und die Arbeit, das Modell überhaupt dazu zu bringen, dort nachzusehen.
• Teil 4: Auswertungen neben dem Chat. Warum Diagramme über ein halbes Jahr nicht in ein Gespräch gehören und die Weboberfläche trotzdem nicht zum Coach wird.

Was es nicht verhindert

Eine Einschränkung gehört an den Anfang, damit sie nicht untergeht: Ganz verhindern lässt sich das Erfinden nicht. Ein Sprachmodell bleibt ein Sprachmodell, und wenn es ein Werkzeug nicht aufruft, antwortet es aus dem Gedächtnis. training mcp verschiebt die Wahrscheinlichkeiten. Mit echten Daten und belegten Befunden im Kontext erfindet das Modell deutlich seltener, und wenn es sich auf einen Befund beruft, kann man nachsehen, welcher es war.

Das ist der Unterschied zwischen einem Werkzeug, dem man bei jeder Zahl misstrauen muss, und einem, mit dem sich eine Woche planen lässt.

Call to Action

training mcp läuft gerade als Beta in einem kleinen Kreis. Anfang November geht es öffentlich an den Start. Alles Weitere steht auf https://training-mcp.app.

Im nächsten Teil geht es um den Maschinenraum: wie die Daten von der Uhr in den Chat kommen. Wenn du selbst einen MCP-Server baust und an einer Stelle hängst, melde dich gern.