intervals.icu MCP Server: Connect intervals.icu to Claude

You already have the data. The model is the part that cannot see it

If you use intervals.icu, you are not the athlete who needs convincing that data matters. You already look at your fitness and fatigue chart. You already know what your best twenty minutes was this year. You have probably built a custom chart or two.

So you open Claude and ask whether the last four weeks worked, and it asks you what the last four weeks looked like.

You type a summary. Around nine hours a week, two hard sessions, CTL drifted up, felt flat by the end. The model answers well, because models answer well. But it answered a paragraph, not a training block. It does not know your twenty-minute best went up eleven watts in week two and gave four of them back in week four. It does not know your resting heart rate sat two beats above baseline for the last nine days, which is the actual thing you noticed and could not name.

The gap is not intelligence. It is access. And the fix is not a better prompt, it is a connection.

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 has been adopted well beyond Claude: ChatGPT, Cursor and Perplexity all speak it.

A server advertises a set of tools, each with a name and a schema. The model decides when to call one, passes arguments, and gets structured data back. That is the whole idea.

For a platform like intervals.icu the fit is unusually good, because intervals.icu is already the place where everything has been normalized. Your Garmin rides, your Zwift sessions, your wellness rows and your planned calendar are all in one account with consistent units. A connector on top of that is not scraping and stitching; it is reading a database somebody already curated.

So "intervals.icu MCP server" means a server that exposes that account as tools. Ask "compare my power curve from this build to the one before" and the model fetches both windows and answers off the curves.

Why intervals.icu is the easiest of these connections and the deepest

Most training platforms make this hard. COROS runs a partner program with no self-serve credentials. Zwift is the same. Plenty of others have no documented API at all, which is why so many integrations you find on GitHub work by pretending to be a phone.

intervals.icu is the opposite, and deliberately so. It publishes an API, it will hand you a personal key from your own account settings, and it supports OAuth for applications that want scoped access without holding your credentials. That openness is a large part of why the platform has the user base it does.

This connector uses the OAuth route rather than the key route. You approve access on intervals.icu's own page, the grant is scoped, and you can revoke it from the same place at any time. Nothing about your password is shared and there is no key for you to paste or rotate.

The scopes it asks for are worth naming, because they explain what the tools can and cannot do: read and write on activities, read on wellness, write on the calendar, and read on your sport settings. The activity write scope is what powers the optional coach recap, which posts a short post-session summary as a comment on the activity itself so it lives next to the ride rather than in a chat window.

What the connector exposes

Eleven tools, and they split cleanly into reading and writing.

Activities in a date window. Every session in a range with training load, power and heart rate averages, intensity and rep structure. This is the workhorse: the tool the model reaches for whenever a question spans more than one session.

One activity in full. The complete payload for a single session when the question is about that session rather than the block.

Per-rep interval breakdown. Watts and heart rate rep by rep with the recoveries in between, which is how you find out that reps three and four are where the session actually went wrong rather than staring at an average that covers all six.

Wellness rows by day. Resting heart rate, HRV, sleep duration and quality, weight, plus anything you enter yourself: fatigue, soreness, mood, stress. The subjective fields are underrated here, because they are the only data in your account that knows how you felt.

Mean-max power curve. Best watts at every duration from one second to an hour over any window you name. For sizing intervals off real numbers rather than off a percentage of a threshold you tested in March, this is the tool that matters. Runners get the pace-curve equivalent.

Sport settings. FTP, power zones, heart rate zones and load settings, so the model prescribes in your zones rather than in generic ones.

Your calendar. Everything planned rather than completed: scheduled workouts, races, notes. This is what lets the model answer "what is coming up" and "does this week's plan still make sense given how last week went" in the same breath.

And three write tools. Create or update a workout, move one to a different day, delete one. Structured intervals survive the trip, so a session written back is a real workout rather than a title and a note.

The write path is the part people miss

Reading is table stakes. The write path is what changes the shape of the conversation.

intervals.icu already syncs its calendar out to devices: Garmin, Wahoo, COROS and others pull scheduled workouts from it. That means a workout written onto your intervals.icu calendar through the connector arrives on your head unit through a pipe that already exists and that you already trust.

The practical version: you have a conversation about how the block is going, you agree that Thursday's session should drop from 5x5 to 4x5 because your last two sessions faded on the final rep, and the change is on your calendar and on your bike computer before you close the tab. Nobody exports a file. Nobody re-types intervals into a workout builder.

That is also the honest reason this connector is deeper than most: for the majority of platforms, an AI can only observe. Here it can observe and then act, in the same place you already plan.

If you want the sport-specific version of that loop rather than the general one, our guide to pushing workouts to a Garmin watch covers the direct path, and the Garmin MCP guide covers reading Garmin's own data alongside this.

What to be careful about

Two things, and the first one catches people.

Wellness is usually a relay, not a measurement. Most athletes populate intervals.icu wellness from a wearable, so the HRV and resting heart rate you see there arrived second hand. That is fine for trend reading and it is not fine for a question like "what exactly did my Garmin record on Tuesday night", because relays lag and occasionally disagree with the source. Connect the wearable directly as well and ask against its own data when the question is provider-specific. Our HRV-guided training guide explains why the trend matters more than any single night either way.

Load numbers are model outputs, not observations. Training load in intervals.icu is computed from your zones and your settings, which means it moves when your FTP or threshold heart rate moves, even if your riding did not change at all. A twelve-point jump in CTL after you updated your FTP is arithmetic, not fitness. Our guide to Training Stress Score covers what the number is actually measuring, and the threshold underneath it is less settled than most people assume.

Neither is a reason to distrust the connector. Both are reasons to ask the model to show its working, which it can do here because the underlying rows are right there.

Three questions that only work once it is connected

The clearest way to know whether this is worth five minutes is to look at questions that change shape entirely when the data is available.

"Is my fitness actually improving or is my CTL just going up?" Without a connection, this is a lecture about the difference between load and fitness. With one, the model pulls your mean-max curve for the current block and the previous one, checks whether your five-minute and twenty-minute bests moved, and cross-references that against how CTL behaved over the same period. Sometimes those two agree. When they disagree, that disagreement is the most useful sentence anyone will say to you that month, and it is not a sentence you can get from a chart you are looking at alone.

"Why did this session feel so much worse than the same one three weeks ago?" Without a connection, the answer is a list of plausible causes: sleep, fuelling, heat, accumulated fatigue. With one, the model reads both sessions rep by rep, sees that the watts were within four of each other but your heart rate ran eleven beats higher and drifted more inside each rep, then pulls your wellness rows and finds the resting heart rate elevation and the two short nights that preceded it. The list of plausible causes becomes one likely cause with evidence attached.

"Given the last two weeks, what should this week look like?" Without a connection, you get a template. With one, the model reads what you actually did against what your calendar said you would do, notices you have missed the second quality session in each of the last three weeks, and proposes a week built around two rather than three, then writes it to your calendar so the plan and reality stop diverging. The interesting part is not the plan. It is that the plan is built on your adherence rather than on your intentions.

The pattern across all three: the question stops being about training in general and starts being about you specifically. That is the entire value of the connection, and it is why the setup pays for itself on the first real question.

Setting it up

About five minutes.

1. Create an AthleteData account and open the integrations page on your dashboard.
2. Find the intervals.icu tile and click Connect. You approve access on intervals.icu's own page. No key to copy, no password shared.
3. Your history syncs in. New activities arrive as intervals.icu receives them from your devices.
4. Copy your MCP URL from the dashboard. It contains your personal API key, so treat it like a password.
5. Add it as a connector in your AI client. In Claude Desktop that is Settings, then Connectors, then Add custom connector, then paste the URL. ChatGPT, Cursor and Perplexity each have an equivalent and take the same URL.

The setup is identical for every provider you connect afterwards, so the second and third integrations cost you a click each rather than another five minutes. The full walkthrough is in our guide on connecting training data to ChatGPT or Claude, and the technical detail on what the server exposes lives on the MCP page.

A good first question is one that needs two fetches and a comparison: "pull my mean-max power curve for the last six weeks and for the six weeks before that, and tell me where the two diverge". If you get a real answer with real watts, the connection is live. If you get a paragraph about how power curves work, it is not.

Putting it together: an intervals.icu MCP protocol

1. Connect intervals.icu first. It is the account with the most normalized history, so it gives the model the widest view for the least setup.
2. Connect the wearable that feeds it as well. That turns wellness from a relay into a source, and it is the difference between a plausible recovery answer and a correct one.
3. Check your sport settings before you ask anything about load or zones. Every load number downstream inherits whatever FTP and threshold heart rate are sitting in there.
4. Ask comparison questions, not summary questions. "What did I do last week" is something intervals.icu already answers better than any chat window. "How does this block compare to the last one at the same point, by power curve and by load" is not.
5. Use the per-rep breakdown when a session felt wrong. Averages hide exactly the thing you are trying to find.
6. Let it write the change back. Agreeing to a modified Thursday session and then not putting it anywhere is how good conversations turn into no training difference at all.
7. Re-read the power curve every four weeks. It is the least gameable evidence that a block worked, and unlike a test ride it costs you nothing to collect.

You already believe in looking at the data. The connector just removes the step where you have to summarize it for someone else first.