Runna MCP Server: Connect Runna Training to Claude

You want the model to see the block Runna just wrote you

You are eleven weeks into a Runna half marathon plan. Every session has landed on your watch the night before, you have run almost all of them, and the app has been quietly adjusting paces as your fitness moved.

So you open Claude and ask whether tomorrow's tempo is a good idea given how the last three weeks have gone. And Claude asks you to describe your training.

You type a summary. Four runs a week, one tempo, one long run, feeling a bit flat. You get a thoughtful answer built on that paragraph, when the real answer is sitting in eleven weeks of splits. The model does not know that your last two tempo sessions ran 4 seconds per kilometer slower at the same heart rate. It does not know your easy runs have crept up in effort while your paces stayed identical.

That is what people are looking for when they search "runna mcp". They want the model to read the training instead of listening to a summary of it. The honest answer is that Runna does not offer a way to do that, and that you can still get most of what you want through a different door.

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 quickly beyond Claude: ChatGPT, Cursor and Perplexity all speak it now.

The design is deliberately boring. 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 rather than as text the model has to parse.

For training data that shape is exactly right. You do not want eleven weeks of runs pasted into a context window, going stale the moment you finish tomorrow's session. You want the model to go and fetch a specific window when a question calls for it, the same way you would open an app and scroll to a particular week.

So "Runna MCP server" would mean a server that exposes your Runna plan and your completed sessions as callable tools. Ask "did my tempo pace at a given heart rate improve across this block?" and the model would fetch both windows and do the comparison against real splits.

Runna has no MCP server, and no developer API either

Being plain about this saves you an afternoon.

Runna's public support documentation covers connected apps, watches, heart rate monitors and calendar syncing. It does not describe a developer API, there is no self-serve credential page, and Runna publishes no MCP server. If you went looking for a Runna API key so you could build your own connector, there is nothing to find on the public side.

This is not a criticism. Shipping an MCP server in 2026 is still unusual for a consumer training app, and the platforms that have done it are almost all ones that already ran a developer API for years beforehand. Runna has built a very good coaching product and has not built a developer surface, which is a completely reasonable set of priorities. Runna was also acquired by Strava in April 2025, which has not changed anything about what it publishes for developers.

The practical consequence is simple: no configuration, no third-party wrapper and no clever prompt will make Claude read your Runna plan objects directly. Anything that claims otherwise is either scraping the app, which breaks on the next release, or describing a product that does not exist.

The route that works: your watch is the bridge

Here is the part worth knowing. Runna is not a closed box. It writes to the device you already wear.

Runna's Connected Apps and Watches documentation lists Apple Watch, Garmin, COROS, Suunto and Amazfit watches, alongside Strava and Fitbit, plus Bluetooth heart rate monitors and calendar sync for scheduling. The watch integrations are how the plan reaches your wrist in the first place: Runna pushes the planned session, you run it, and the completed activity flows back.

That completed activity is the thing you actually want the model to read. It carries the full recording: pace, per-kilometer splits, heart rate, cadence, duration, elevation, and on most watches the lap structure of the session. It is frequently richer than what Runna itself shows you, because the watch records at one second resolution and the app displays a summary.

Every one of those watch platforms is readable over MCP through AthleteData. Garmin, COROS and Suunto all connect directly, and Apple Health comes through an iOS app that reads HealthKit on the device and forwards the samples. Amazfit reaches the same place through Zepp. So the chain is: Runna writes the session to your watch, your watch syncs to its own platform, and the connector reads that platform. Three hops, all of them ones you already have, and none of them requiring anything from Runna's side.

Runna also syncs to Strava, and Strava is deliberately not the route here: Strava's API terms do not permit serving Strava data to third-party AI tools, so it is excluded from the connector. Garmin, COROS, Suunto and Apple Health are the routes, and they hold the richer recording anyway.

There is a small piece of supporting evidence for the direction of flow in Runna's own guidance. Runna is explicit that it cannot pass a Garmin-recorded activity onward to another service, because activities reach Runna from the watch rather than through it. Runna is a coaching app that writes to your watch. It is not a data hub, and it does not try to be one.

What you get and what you lose

This is the section that matters most, because the failure mode with a partial data source is not an error message. It is a confident answer built on something that was never there.

What you get. The executed session, in full. Pace and splits, heart rate including drift across the run, cadence, duration, distance, elevation, and lap structure where the watch recorded laps. Alongside that, because the connector reads everything you have connected rather than one app, you get derived analytics nothing in the Runna app computes: fitness and fatigue balance over the block, pace curves showing your best effort at every duration, week over week load, and your HRV and resting heart rate series if you wear something that measures them overnight.

That combination answers the question you actually wanted to ask. "Across my last six tempo sessions, did my heart rate at target pace drift up or down?" is unanswerable by scrolling an app and trivial for a model with tool access.

What you lose, and it is real. You do not get Runna's plan objects. The upcoming sessions, the prescribed paces, the plan structure and the week-by-week progression stay inside Runna. You do not get Runna's coaching rationale, the text explaining why a session exists. You do not get its adaptation logic, meaning the model cannot see why Runna moved a pace target or reshuffled a week.

And you do not get the non-running sessions. This one catches people out. Runna's Garmin integration transfers running workouts only, in both directions. Strength, yoga, mobility and everything else Runna prescribes never leaves the app, so a model reading your watch sees a week with four runs in it and no idea that Runna also programmed two strength sessions you completed. If you are running a plan with a meaningful strength component, log those separately or the load picture is wrong. Our guide to connecting training data to ChatGPT or Claude covers the full source list if you want the strength side coming from a dedicated app.

The short version: you get an excellent record of what you did, and none of what Runna intended. For most of the questions people actually ask an AI assistant, which are about execution and trend rather than about the plan document, that trade is fine. For "is this plan right for me", it is not, and you should say so up front rather than let a model fill the gap.

Which watch you have, and what changes

Garmin. The best-supported route, and the one most Runna athletes are on. The integration is genuinely two-way for running: Runna sends the planned session to the watch and the completed activity comes back to Runna. On the connector side, Garmin brings activities with full lap structure, plus sleep, HRV, resting heart rate, body battery inputs and stress. Setup is a sign-in. The Garmin MCP server guide walks through it, including the history caveat: Garmin's API serves a rolling 30 day window, so a full history needs the export import that guide describes.

COROS. Runna pushes sessions to COROS watches and the completed runs come back. On the connector side COROS delivers activities with lap structure, overnight HRV, resting heart rate and a nightly sleep total, though no stage breakdown and no VO2max. The COROS MCP server guide is specific about what lands and what does not, which is worth reading before you rely on a sleep answer.

Suunto. Same shape. Activities, lap data and the wellness scalars come through. See the Suunto MCP server guide for the detail.

Apple Watch. Runna is deeply integrated with Apple Health, and this route works differently from the others: instead of a server-side OAuth grant, an iOS app reads HealthKit on your phone and forwards the samples. That is the only way it can work, because HealthKit has no server-readable API. Workouts, sleep, HRV, resting heart rate, weight and nutrition all come through. The Apple Health integration page has the setup.

Amazfit. Reaches the connector through Zepp, and behaves like the other watch bridges: completed activities and wellness data land, the plan stays in Runna.

Runna and WHOOP, which do not talk to each other

This comes up often enough to deserve its own section, because two of the searches that land on this page are about exactly it.

Runna's published Connected Apps and Watches list does not include WHOOP. So there is no Runna to WHOOP sync, no WHOOP recovery score feeding a Runna pace adjustment, and no amount of digging through settings will produce one. If you run Runna plans and wear a WHOOP for recovery, you are running two systems that are structurally unaware of each other.

The fix is to stop trying to make them talk and put both into one place instead. Connect your watch and your WHOOP to the same connector, and the model sees the run your watch recorded alongside the recovery WHOOP scored that morning. That is the cross-source question that is genuinely hard to answer anywhere else: not "what was my recovery" and not "how was my tempo", but "in the twelve weeks of this block, did my tempo sessions on low-recovery mornings actually go worse, or do I just remember them that way?"

The same applies to Oura, to Withings for weight, to Hevy for the strength work Runna cannot export. One connector, many sources, and the model does the joining. If you want the competitive framing rather than the technical one, we have a Runna comparison page that covers it directly.

Which AI client can hold the connector

The connector is one URL, and where you can paste it depends on your plan with the AI vendor, not with us. These were verified against vendor documentation on 2026-08-27.

Claude works on every tier, including Free. Custom connectors are available on claude.ai and Claude Desktop to Free, Pro, Max, Team and Enterprise accounts, and a Free account can add one custom connector, which is all you need here. If you are trying this out for the first time and do not want to pay two subscriptions to find out whether it is useful, this is the cheapest path.

ChatGPT needs a paid plan. Adding a custom MCP plugin requires Developer mode, which is available on Plus, Pro, Business, Enterprise and Education accounts, on chatgpt.com in a browser. Plus is enough, you do not need Pro. The iPhone and Android apps have no Developer mode toggle, so the connector has to be added on desktop, though it works in mobile conversations once added.

Cursor needs Pro or Business. MCP is not part of its free Hobby tier.

On our side, the MCP tier is $9/month or $69/year and gives you the connector and your data. The full coaching plan is $39/month and adds a coach that watches your data continuously and starts conversations without being asked, which is a genuinely different product from a connector that waits to be queried. Both include a 7-day free trial, and if you are running a Runna plan and want a second opinion on execution rather than a replacement for the plan, the running coach page explains what that looks like in practice.

Putting it together: a Runna to Claude setup playbook

1. Identify which watch platform your Runna sessions land on. Garmin, COROS, Suunto, Amazfit and Apple Watch are all on Runna's connected list, and whichever one you already use is the bridge.
2. Confirm Runna is actually pushing to it and that completed runs are coming back. Open a recent session in Runna and check it shows the recorded data, not just the prescription. If that loop is broken, nothing downstream works.
3. Connect that platform at athletedata.health. Garmin, COROS and Suunto are a sign-in and an approval. Apple Health is the iOS app reading HealthKit on your phone.
4. Let the initial backfill finish before you ask anything comparative. History streams in over minutes, and a question about two blocks asked against a half-loaded history returns a confidently wrong answer.
5. Add anything Runna cannot see. WHOOP or Oura for overnight recovery, a strength app for the sessions Runna programs but cannot export, a scale if weight matters to you. Each one is another thing the model can join against.
6. Copy your MCP URL from the dashboard and add it as a connector in Claude, ChatGPT or Cursor. It is one URL containing your personal key, it is revocable from the same page, and you should treat it like a password.
7. Verify with a question you have never typed the answer to. "What was my longest run in the last 90 days and what was my average heart rate on it?" If the number is right, the pipe is good.
8. Then ask the question that needed this. Something like "compare my tempo sessions from weeks 1 to 4 against weeks 8 to 11 at matched heart rate" is the shape of question that is unanswerable by scrolling and easy with tools.
9. Keep the boundary in your head. The model sees what you ran, not what Runna planned, and it sees no strength work. When an answer starts describing your plan structure or your strength progression, correct it rather than building on it. Pace targets are worth stating explicitly in the conversation, and our marathon heart rate guide covers how to frame them so a model can use them.

Runna knows what it wants you to run. Your watch knows what you actually ran. Until Runna publishes a developer surface, the watch is the honest source, and it is the one with the splits in it anyway.