What Claude can actually read through Strava
Strava's connector is not a thin activity feed. What it actually exposes, checked directly rather than read from marketing copy, is substantial: full activity history with distance, pace, heart rate and power; heart-rate, power and running-pace zones; an FTP figure, including whether Strava calculated it or you set it yourself; weight and measurement preference; bikes and shoes; and, per activity, personal records, segment efforts and best efforts.
That is a genuinely capable read. Claude can tell you your easy-run pace has drifted, which shoes you have logged the most distance in this year, or how your average power has trended over eight weeks. None of that requires a separate record; Strava already has it, and the connector already gives Claude access to it.
Every one of those values is something Strava computed
The connector's own field for FTP carries a flag showing whether the number was estimated by Strava or set by the athlete. That flag exists because the two are different things, and Strava is explicit that they can diverge. Zones work the same way: a run pace zone can be derived from a single reference race rather than a value the athlete confirmed as current.
This is not a criticism of Strava. It is a description of what the connector is for. It is built to answer questions about training that happened, using values Strava's own algorithms derived from that training. An estimated FTP is still a reasonable answer to “what is my FTP,” and most of the time it will be close enough. The connector is not built to hold a value you tested yourself and want treated as authoritative until you say otherwise.
What has no field at all
The connector's full set of available tools (activity listing, activity detail, performance data, streams, athlete profile, zones, gear, club information and a training-plan generator) holds none of the following: a future race with a date and a target time, an injury or a constraint, or an explicit value the athlete has confirmed as current rather than one Strava calculated. That is a genuine absence, not a guess: it is what the documented tool set does not contain, checked directly rather than inferred from what the connector is generally described as doing.
Ask Claude what your FTP is with only Strava connected, and it will answer from whichever figure the connector reports, estimated or confirmed, current or three months stale, with no way for you to tell which from the answer alone.
One rider, one FTP, two different numbers
Take an illustrative rider recovering from three weeks off the bike after a knee injury. Before the layoff, Strava had estimated their FTP at 245W from ride data. They have since done a proper 20-minute test and know it is closer to 225W, lower because three weeks off cost them fitness, but they have not logged a ride that would let Strava recalculate its own estimate downward.
Ask Claude to set interval targets for this week and, with only Strava connected, it reasons from 245W: the number the connector reports, because it is the only number it has. It has no way to know a test happened, and no way to know the knee was ever a factor. The answer is not wrong given what Claude can see. It is wrong given what is actually true.
That gap is what Athmex fills. The rider enters 225W as their FTP with the date they tested it; Athmex keeps 245W as the value it replaced. The knee goes in as a constraints note until it stops being relevant. When Claude reads Athmex alongside Strava, it has the confirmed current number and the reason the old one no longer applies, not just whichever figure Strava last calculated.
Athmex does not read Strava or recalculate anything. The athlete enters and confirms the value directly, which is the entire mechanism: a number only changes when the athlete says it has. See how Athmex works.
What each one is actually reporting
The distinction is what kind of value each one is holding, not just what data reaches Claude.
| What is being compared | Strava connector | Athmex athlete context |
|---|---|---|
| Where a value comes from | Computed by Strava from recorded activity data. | Entered or confirmed by the athlete directly. |
| FTP | A figure that may be estimated by Strava rather than set by the athlete, with a flag showing which. | The value the athlete tested, with the date it applied and the previous figure kept as history. |
| Zones | Derived from activity data or, for run pace, sometimes a single reference race. | Not separately stored; Athmex holds the threshold values zones are usually built from. |
| Race and goal | No field for a future race or a target time. | Stored as a dated event with a target. |
| Injuries and constraints | No field for this. | Kept as a constraints note the athlete maintains. |
| Gear | Bikes and shoes, with total distance. | A shoe rotation by name and type (race, tempo, trail, daily recovery). No bikes, and no distance: Athmex holds no activity data to compute that from. |
| Which assistants | Claude, as of this connector's June 2026 launch. No documented ChatGPT route. | Claude and ChatGPT. ChatGPT needs a paid plan for custom connectors; Claude works on a free account. |
When this actually matters
If you mostly ask Claude to summarise recent training, Strava's connector alone is enough. It reads what happened accurately, and Strava's own numbers are a reasonable default when nothing more specific is available.
It matters more when a session recommendation depends on a number you have deliberately updated, or on a constraint Strava has no way to see. That is a narrower case than “any Strava user,” and it is the one Athmex is for. Setup for Strava itself, including the connection steps and subscription requirement, is covered separately. This page is about what the connector does and does not report once it is connected.