Zwift MCP Server: Connect Zwift to Claude and ChatGPT
Give Claude or ChatGPT live access to your Zwift rides, with per-second power and heart rate, so it answers from the intervals you held, not your summary.
You ask Claude how the block went and it asks you how the block went
You have ridden four VO2 sessions in six weeks. Every one of them sits in Zwift with a per-second power trace, a heart rate line, a cadence line and the exact structure of the workout you loaded.
So you open Claude and ask whether you are adapting or digging a hole. And it asks you to describe the sessions.
You type something reasonable. Four by eight at around 320 watts, felt harder the last two times, heart rate seemed high. The model gives you a thoughtful answer built on three sentences, when the real answer is sitting in four rides. It does not know that your first session held 322, 320, 318, 316 and your most recent one went 324, 316, 305, 298. It does not know your heart rate in the final rep was nine beats lower than six weeks ago at eighteen watts less, which is the actual tell.
The model is not being lazy. It is blind. And you cannot type your way out of blindness, because the thing you would need to type is a spreadsheet.
An MCP server fixes this at the root. Instead of you summarizing the block, the model reads it.
What MCP actually is
The Model Context Protocol is an open standard for letting AI assistants call external tools. Anthropic published it in late 2024 and it spread well past Claude: ChatGPT, Cursor and Perplexity all speak it now.
The protocol is boring in the good way. A server advertises a list of tools, each with a name and a schema describing what it takes and returns. The model decides when to call one. The result comes back as structured data rather than prose, so the model reasons over numbers instead of over your description of numbers.
For training data, that shape is exactly right. You do not want six weeks of rides pasted into a context window, going stale the moment you finish tomorrow's session. You want the model to go and look when it needs to, the way you would open the companion app and scroll back to a specific week.
So "Zwift MCP server" means a server that exposes your Zwift history as tools. Ask "did my third interval hold up better this week than last?" and the model fetches both rides and compares the reps.
Why Zwift is a harder connection than it looks
Search for a Zwift API key and you will not find one. Zwift operates a partner program with an application and an agreement behind it, not a developer portal where an individual generates credentials for their own account.
This is why almost every Zwift integration you find on GitHub is unofficial. They work by impersonating the mobile app against endpoints that were never published, which means they break without warning whenever Zwift ships a release, and they need your actual Zwift password rather than a revocable grant.
The connection here is the supported route. AthleteData is an official Zwift Training Partner, so connecting is a sign-in on Zwift's own page where you approve access once, and you can revoke it from your side whenever you want without changing your password.
There is a second, more interesting consequence of that partnership, and it runs in the other direction. Your coach's planned rides can be scheduled onto your Zwift home screen so they are waiting for you when you launch, which is covered in full in our Zwift coaching guide. That is a separate feature from the read path this article is about, and it is worth knowing both exist.
What the Zwift connector exposes
Once connected, the model gets tools rather than a data dump. The ones that matter for Zwift:
Ride history in a date window. Every Zwift ride in a range you name, with duration, distance, average and normalized power, average and max heart rate, cadence and elevation. This is the tool the model reaches for when you ask what a week or a block looked like.
Per-block interval breakdown. This is the one that separates a useful answer from a generic one. Zwift rides retain their per-second power and heart rate samples, and the connector reconstructs the session from them: rep by rep watts, rep by rep heart rate, and the recovery valleys between. A 4x8 comes back as four numbers, not one. A steady sweet-spot ride comes back as a trace you can read drift off, rather than a single average that hides it.
Derived analytics that Zwift has no screen for. Fitness and fatigue balance computed across everything you train rather than only your indoor riding. A power curve by duration, so your best five minutes and best twenty minutes are known quantities rather than something you go hunting for. Load balance across sports, and adherence against a plan if you are following one.
That last group is the part people underestimate. Zwift knows your Zwift rides. It does not know about the Saturday outdoor ride, the two runs, or the strength session, so its picture of your week is structurally incomplete in a way no amount of indoor data fixes. The connector reads all of them together.
What lands and what does not
Being specific here matters more than being flattering, because a model that thinks it has data it does not have will invent an answer rather than admit the gap.
Lands: rides and structured workouts, with power, heart rate, cadence, duration, distance and elevation. Per-second power and heart rate for interval reconstruction. Normalized power. Everything downstream of those, meaning training load, fitness and fatigue, and your power curve.
Does not land: sleep, HRV, resting heart rate, VO2max, body composition. None of that is a limitation of the connection. Zwift is a training platform running on a trainer and a screen, and it never measures any of it in the first place.
This is why Zwift is best treated as one input rather than the whole picture. Connect a watch or a ring alongside it and the recovery half arrives through the same connector, and then the model can actually answer the question you care about, which is not "how hard was that session" but "given how I slept, should I do the session at all". Our Garmin MCP guide covers that side of the pipe, and the same pattern works with WHOOP, Oura or Apple Health.
Setting it up
Five minutes, and most of it is waiting for a page to load.
- Create an AthleteData account and open the integrations page on your dashboard. The Zwift integration page lists exactly what the connection reads and writes if you want to check before you start.
- Find the Zwift tile and click Connect. You are sent to Zwift's own sign-in page, where you approve access once. Nothing about your Zwift password is shared with anyone.
- Your recent ride history syncs in. Anything you ride from that point forward arrives within moments of saving.
- Copy your MCP URL from the dashboard. It is a single URL with your personal API key in it, so treat it like a password.
- Add it as a connector in your AI client. In Claude Desktop that is Settings, then Connectors, then Add custom connector, then paste. ChatGPT, Cursor and Perplexity each have an equivalent, and the URL is the same one in all of them.
Then ask something you could not have asked before. A good first test is "compare the interval structure of my last two VO2 sessions and tell me which reps faded", because it forces the model to fetch two rides and read inside them, so you find out immediately whether the connection is live.
If you want the full walkthrough with screenshots for each client, our guide on connecting training data to ChatGPT or Claude covers the setup end to end, and the same MCP URL works for every provider you connect later.
What changes about the conversation
The difference is not that the model gets smarter. It is that the questions stop being hypothetical.
Before, you asked "should I raise my FTP estimate?" and got a paragraph about ramp tests and how to know when you are ready. Afterwards, you ask the same question and the model looks at your twenty-minute best from the last eight weeks, notices it went from 298 to 311 without a test ride in sight, and tells you the number you are training at is already stale. If you want the theory behind why those two numbers are not interchangeable, our guide on FTP vs Critical Power is the deeper read.
Before, you asked "was that ride hard?" and got a definition of normalized power. Afterwards, you ask why a ride that averaged 210 watts felt worse than one that averaged 240, and the model reads both traces, sees that the 210 was a punchy group ride full of surges and the 240 was a steady tempo block, and explains the gap in terms of your actual variability index. Our normalized power guide explains the metric itself if you want the arithmetic.
The pattern is consistent. Anything that used to require you to go and look something up, then paste it in, then ask the question, collapses into one question.
Where the indoor picture misleads you, and what the model should do about it
Zwift data has three quirks that a model reading raw averages will get wrong, and they are worth knowing because they change how you phrase the question.
Every workout target is a percentage of the FTP set inside Zwift. A .zwo workout file does not contain watts. It contains fractions, and the trainer app multiplies them by whatever number your profile holds at the moment you press start. So if your FTP in Zwift says 250 and your actual threshold is 275, a "sweet spot" block was ridden at 84% of your real threshold and the model will read it as sweet spot anyway, because the file says so. Ask about the watts you held, not the zone you were told you were in, and fix the number in Zwift before the next block.
ERG mode flattens the thing you would normally read effort off. In ERG the trainer holds the target watts regardless of what you do, so power variability inside a rep goes almost to zero by design. That makes normalized power and variability index nearly meaningless on an ERG session, and it makes heart rate drift the honest fatigue signal instead. On a race or a free ride the opposite is true and the power trace is the interesting one.
Indoor and outdoor power are not always the same number. Trainer calibration, drivetrain losses and heat all move it, and riders commonly see a gap in one direction or the other between their indoor and outdoor thresholds. The model reads both as watts, so if you train indoors and race outdoors, say so when you ask, and treat a step change in your power curve that coincides with a change of trainer as a measurement artifact until proven otherwise.
None of these are reasons to distrust the data. They are reasons to ask the second question. "Did I hold the target" is a question about the file. "What did I actually hold, and at what heart rate" is a question about you.
The limits worth knowing about
Four things are worth setting expectations on.
History depth. Your recent riding syncs in when you connect. If you have five seasons of Zwift behind you, the connector will know your current block well and your 2021 racing not at all. That is a reason to connect now rather than later, not a reason not to connect.
Indoor only. Zwift sees Zwift. Your outdoor rides come in through Strava, Garmin, Wahoo or whatever head unit you use, and they need their own connection. Once they are both in, the model reads them as one training history, which is the point.
The model can still be wrong. Real tool data removes the guessing about what you did. It does not make the reasoning about what to do next infallible. Treat a well-evidenced answer as a good second opinion, not as a coach.
A connector is not coaching. Reading your data on demand and having something proactively watch it are different products. The connector answers when you ask. If you want the version that notices the pattern before you do and messages you about it, that is the coaching tier. Both start with a 7-day free trial, and the pricing page has the split.
Putting it together: a Zwift MCP setup checklist
- Connect Zwift on your AthleteData integrations page and approve access on Zwift's sign-in.
- Connect a wearable alongside it. Zwift covers the training half; sleep, HRV and resting heart rate have to come from a watch or a ring.
- Copy the MCP URL from your dashboard and add it as a connector in Claude, ChatGPT, Cursor or Perplexity.
- Test with a question that requires reading inside a ride, not just listing rides. "Break down my last VO2 session rep by rep" is the right shape.
- Set your FTP correctly in Zwift before your next structured session, because every percentage target in every workout scales off it and a stale number quietly rewrites the whole plan.
- Ask the comparison questions rather than the summary questions. "How does this block compare to the last one at the same point" is where having real data pays, and "what did I do last week" is a question the app already answers.
- Revisit the power curve every four weeks. It is the cleanest evidence that a block worked, and it updates itself without you testing anything.
Your indoor rides already contain the answer to almost every question you ask about your form. The connector just stops you having to summarize them from memory first.
