Hevy MCP Server: Connect Hevy to Claude and ChatGPT

You ask Claude if your bench is stalling and it asks you for numbers

You have logged every session in Hevy for fourteen months. Nine hundred sets of bench press, each one with a weight, a rep count and often an RPE. It is one of the cleanest training datasets a lifter can own.

So you open Claude and ask whether your bench is stalling. And it asks you what your last few sessions looked like.

You type three of them from memory. The model gives you a thoughtful, articulate answer built on three data points out of nine hundred. It does not know your top set has been 102.5 kg for seven weeks. It does not know your volume on the lift dropped 30 percent when you added a second leg day in June. It does not know your last four sessions were all logged after 9pm.

The model is not the problem. It is genuinely good at this reasoning. It is blind, and you cannot type your way out of blindness. An MCP server fixes that at the root: instead of you describing the training, the model fetches 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 has since been adopted well beyond Claude, with ChatGPT, Cursor and Perplexity all speaking it.

The protocol is boring in the good way. A server advertises a list of tools, each with a name and a schema. The model decides when to call one. Results come back as structured data the model can reason over.

For a strength log, that shape is exactly right. You do not want your whole lifting history sitting in the model's context window going stale the moment you finish tonight's session. You want the model to ask a question when it needs an answer, the same way you would open Hevy and scroll to a specific exercise.

So "Hevy MCP server" means a server that exposes your Hevy log as tools. Ask "has my squat volume actually gone up since April, or does it just feel harder?" and the model calls a tool that returns every squat set in both windows, then does the comparison against real numbers.

What the Hevy connector exposes

The AthleteData MCP server registers 18 Hevy tools when Hevy is connected. They fall into four groups.

Sessions. hevy_get_workouts returns a paged list of completed workouts with full exercise breakdowns, every set carrying reps, weight, RPE and rest. hevy_get_workout pulls one session in depth once the model knows which one it wants. hevy_get_workout_count gives the total, and hevy_get_workout_events surfaces changes to sessions after the fact, which matters when you edit a workout two days later.

Progression. hevy_get_exercise_progress is the tool that earns its place. Give it one exercise template ID and it returns every set you have ever logged for that movement, with weight, reps and an estimated 1RM trend across the whole history. This is the tool behind "is my bench actually stalling", and it is the question Hevy's own charts answer visually but cannot argue about.

Programming. hevy_get_routines, hevy_get_routine and hevy_get_routine_folders read your saved programs. hevy_get_exercise_templates and hevy_get_exercise_template resolve exercise names to the IDs everything else keys on. hevy_get_body_measurements covers weight and the other body metrics you log in the app.

Writing back. hevy_create_routine and hevy_update_routine build and revise programs. hevy_create_workout and hevy_update_workout log or correct a session. hevy_create_exercise_template and hevy_create_routine_folder handle the cases where your movement is not in Hevy's default library. These are the tools that turn a conversation into a program sitting in your app on Monday morning.

Alongside those, the connector registers derived analytics that are not Hevy fields at all but computed across everything you have connected: get_pmc_status for fitness and fatigue balance, get_training_trends, get_load_balance, get_injury_risk and get_readiness_today. If you also wear a watch, those are the tools that let the model connect a bad session to a bad night rather than to your programming.

The paging problem, which is the real reason this needs a server

Hevy's public API is genuinely good, but it caps most list endpoints at 10 records per request and returns an error if you ask for more. A twelve-week review is therefore not one call. It is twenty or thirty, walked in sequence, with the results stitched together before anyone can reason about them.

That constraint is why "just give the model an API key" does not work in practice. A model handed a raw endpoint will fetch page one, see ten workouts, and answer from those ten as if they were the whole picture. It will not tell you it stopped early, because from where it sits, it did not.

The connector handles the walk. When the model asks for a training block, it gets the training block. This sounds like plumbing, and it is, but it is the specific plumbing that separates an answer about your last two weeks from an answer about your last two sessions.

Why this beats the alternatives

Screenshots. The model reads a Hevy screenshot imperfectly, cannot follow up, and cannot compare tonight's session to one in March. You are also implicitly choosing which data matters before the model has looked at any of it, which is the opposite of what you wanted when you asked.

CSV exports. Hevy will export your history, and that file works exactly once. The moment you train again it is stale, and re-exporting before every conversation is enough friction that nobody does it twice.

Typing it out. This is the default, and it silently caps every answer at the handful of sessions you happen to remember. It also biases the answer, because you type the sets you think are the story.

The hosted connector uses Hevy's official API through a key you generate and can rotate. Nothing runs on your machine, nothing breaks when the Hevy app ships an update, and revoking access is one click on the Hevy integration page.

Setting it up

The whole flow is about five minutes.

1. Get your Hevy API key. API access requires a Hevy Pro subscription, and the key is generated from the Hevy web app rather than the phone app. Sign in at hevy.com, open settings, and generate a key.

2. Connect Hevy. Sign in at athletedata.health, open the integrations page, and paste the key into the Hevy card. Your workout history starts syncing immediately, and unlike wearable APIs with a rolling backfill window, Hevy returns your full history rather than the last 30 days.

3. Copy your MCP URL. In the dashboard, use the Copy MCP URL button. It produces a URL of the form https://mcp.athletedata.health/mcp?apiKey=sk_soma_.... That key is yours alone and is revocable from the same page.

4. Add it to your AI client. In Claude, open Settings, then Connectors, then Add custom connector. Name it athletedata, paste the URL, and click Add. The connector should show as Connected. ChatGPT, Cursor and Perplexity each have an equivalent panel, and there are step-by-step pages for all of them in the MCP setup section.

5. Ask it something specific. Open a new chat and ask a question that needs data you have never typed, for example "what is my estimated 1RM trend on bench press over the last six months, and when did it flatten?" You will see the tool calls fire before the answer arrives. That is the confirmation that it is reading rather than guessing.

What changes about the conversation

The interesting shift is not that the model can recite your sets. It is that you stop pre-filtering.

When you have to type your context, you decide in advance what is relevant. You mention the stalled bench because the stalled bench is the story you noticed. You do not mention that your weekly chest volume quietly halved in June when you reshuffled the split, because you never connected the two. With tools available, the model can go looking.

Weekly set counts are the clearest example. Schoenfeld, Ogborn and Krieger's 2017 meta-analysis in the Journal of Sports Sciences found a dose-response relationship between weekly sets per muscle group and hypertrophy, with the gains continuing to accumulate past ten sets. Counting your actual weekly sets per muscle group by hand across a training block is tedious enough that almost nobody does it. A model with tool access does it in one call and then tells you your rear delts have been at four sets a week since spring.

A worked example, because the difference is concrete. Ask a model without tools "why has my bench stalled?" and you get a competent paragraph about periodization and progressive overload. Ask a model with tools and it calls hevy_get_exercise_progress on bench, sees your top set frozen at 102.5 kg for seven weeks, calls hevy_get_workouts across the same window, notices your total pressing volume fell after you moved bench from Monday to Friday, and gives you the specific thing: the lift did not stall, the volume did.

If you train both strength and endurance, that cross-source reasoning is where the answers get genuinely hard to get anywhere else. The hybrid athlete training guide covers what that interference actually looks like in the data.

The limits worth knowing about

The dumbbell weight ambiguity is real, and honest tools say so. Hevy stores the exact number you typed into the weight field and computes volume as weight multiplied by reps, with no automatic per-hand doubling. So for a dumbbell exercise, 30 kg might mean one 30 kg dumbbell in each hand, or a 30 kg pair total. The convention depends entirely on how you log, and it can differ between athletes and even between exercises for the same athlete. There is no fixed rule to apply. The connector puts that ambiguity in front of the model rather than letting it guess, because guessing silently halves or doubles a number that looks perfectly reasonable either way. If you tell the model your convention once, it is worth writing down.

Hevy Pro is required. API access is a paid Hevy feature. That is Hevy's decision, not a platform constraint, and there is no way around it.

Routines written by the API sit outside your folders. A routine created through the API lands in your Hevy account but is not filed into one of your folders, and the phone app can cache its routine list for a few minutes. So a routine that the model confirms it created and that you cannot immediately see is a refresh-and-scroll problem, not a failed write.

Strava is not available over MCP. Strava's API terms do not permit serving Strava data to third-party AI platforms and tools, so it is excluded from the connector. Every other source works.

Tool access is not a coach. The connector answers questions you ask. It does not notice that your squat has been flat for a month and message you about it, because nothing is running between your conversations. That distinction is the real difference between the two products: the MCP tier at $9/month, or $69/year, is for querying your own data in your own AI client, while the full coaching plan at $39/month adds a coach that watches the data continuously and starts the conversation itself. Both include a 7-day free trial. The Hevy AI coach guide covers where that line falls in practice.

Hevy is one source among many. The same connector exposes Garmin, WHOOP, Oura, Withings, Apple Health, Intervals.icu, TrainingPeaks, Wahoo, COROS, Polar and others through one connection. If you lift with Hevy and run with a Garmin, the model sees both. The Garmin MCP server guide covers that side, and the general guide to connecting training data to ChatGPT or Claude has the full source list.

Putting it together: a Hevy MCP setup checklist

1. Confirm you have Hevy Pro, then generate an API key from the Hevy web app settings page. The phone app does not expose it.
2. Paste the key into the Hevy card on your AthleteData integrations page and wait for the first sync to finish. Your full history comes across, not a rolling window.
3. Copy your MCP URL from the dashboard. Treat it like a password, because the API key is embedded in it.
4. Add the connector to your AI client and confirm it reports as Connected.
5. Run one verification question that needs data you have never typed, such as your heaviest logged set of the last twelve months. If the number is right, the pipe is good.
6. Tell the model your dumbbell logging convention once, in the first substantive conversation. It removes the single biggest source of wrong-but-plausible strength numbers.
7. Ask a structural question next, not a single-lift one. "Which muscle groups have been under ten weekly sets for the last month?" is the kind of question this is actually for.
8. Revoke the key from the dashboard if you ever share a machine or stop using a client. It takes one click and invalidates every session using it.

You have already done the hard part. Fourteen months of honest logging is a better dataset than most lifters will ever have. The only thing missing was a way for something smart to read it without you typing it out first.