Rosablanche

I’ve got years of training data in my Suunto. In order to query the past and benchmark Coros Apex 4 against my old setup, I need my old setup’s data — which turns out to be its own small saga. This post covers the Suunto side of that story.

The problem: no bridge between Suunto and Claude

Suunto has no MCP connector and no integration with any of the tools I actually use. If I want Claude to see a workout, I have exactly two options, and neither is quick.

Option one: screenshot the workout data on my phone and upload the images into a chat. Fine for a quick glance, useless for anything requiring real numbers.

Option two: export the workout from the Suunto app into one of several formats — GPX, KML, FIT, or JSON (Claude prefers JSON) — mail the file to myself, save it to my computer, and re-upload it into Claude Desktop from there.

I did try to shortcut this by saving the export directly on my phone and uploading straight into Claude’s mobile app. It never worked — my best guess is the file is simply too large for the mobile app to handle. So the round trip through email stays mandatory, for now.

A glimmer of hope: someone already built this

While grumbling about this workflow, I stumbled on a Reddit thread where a user called Googlarz mentioned he’d actually built an MCP server for Suunto. An actual bridge between the watch and Claude, built by someone clearly as fed up with the manual export dance as I am. Problem solved !

Spoiler alert: It wasn’t quite that simple.

Step zero: getting API access

So, I opened up the readme.md of Googlarz’ suunto-mcp project and followed the instructions. I first needed API access from Suunto itself — and this is where things slowed right down.

The process, as I followed it:

1. Go to apizone.suunto.com, scroll to the “Process” section, and click Apply for API access under step 2.
2. Fill out a form describing what you want to build and what you intend to do with the data. I kept my answer deliberately vague — I don’t think anybody reads that form very seriously back at Suunto’s office.
3. Submit, and then… nothing. No confirmation, not even an acknowledgment email.
4. Two weeks later, out of nowhere, an approval email arrives.

Great news — except that’s not actually the end of it. Approval just gets you through the door; the real setup is back in Googlarz’s README, and I’m now on Part 1, Step 3 of his instructions.

Update you Oauth settings

as per readme. They can be found in the profile tab of the apizone.suunto.com page or directly at https://apizone.suunto.com/profile.

Subscribe to development API

Now onto Part 1, section 4 of the readme.

Go to 3. Develop section of apizone.suunto.com and click on Subscribe to development API.

In the screen below, enter a name for your API (Iput test) and subscribe.

This creates your client id and subscription key, that can be found in the Subscriptions section of your profile.

Don’t leave optional .env variables blank

Part 2 of the readme now. Step 5 as described.

But with step 6, I hit my first real issue: the .env file had a couple of extra optional variables left as empty lines, like:

SUUNTO_TOKEN_PATH=
SUUNTO_DAILY_PREFIX=

Blank isn’t the same as absent — the code read that as an actual empty file path and crashed trying to write to it. The fix was deleting those lines entirely, not just leaving the value empty. If you hit an ENOENT error with an empty path in the stack trace, this is almost certainly why.

Error: ENOENT: no such file or directory, open ''

With that done, steps 7 & 8 should go smoothly

Windows isn’t macOS, and the guides assume macOS

Part 3 now !

The setup README (like most of these guides) is written for Terminal on macOS. A few translation notes for Windows Command Prompt:

• There’s no pwd. Use cd (with nothing after it) or echo %cd% to print your current folder.
• JSON needs backslashes in file paths escaped as double backslashes: C:\\Users\\Name\\..., not single ones.
• %APPDATA% is just a shortcut Windows uses for C:\Users\YourName\AppData\Roaming — useful to know if you’re ever unsure what a command is actually pointing at.

The config file might not be where every guide says it is

This was the big one. Every setup guide points to:

%APPDATA%\Claude\claude_desktop_config.json

On my machine, that path led to a file Claude Desktop never actually reads and the local MCP server was never uploaded. Because my install is a packaged/sandboxed version of the app, Windows silently redirects it to a completely different, much longer path buried under AppData\Local\Packages\.... I edited the “standard” file for ages with zero effect.

The fix: don’t trust the documented path blindly. Claude Desktop’s own Settings → Developer → Edit Config button opens the actual file it reads, wherever that really lives. Use that button rather than typing a path from a guide.

Then open the claade_desktop_config.json file.

Don’t overwrite the whole file

Step 10: That config file isn’t Suunto-specific — it’s the app’s general settings file, already containing preferences, paired devices, and other configuration. The fix is to add an mcpServers block alongside what’s already there, not replace the file wholesale. Losing existing settings by pasting over the whole file is an easy, avoidable mistake.

Bare commands can silently fail — use full paths

My config initially just said "command": "node". Claude Desktop launches configured servers with a deliberately minimal PATH, so short commands that work fine in your own terminal can fail invisibly here. The fix: find the full path with where node in Command Prompt, and use that instead — in my case, C:\Program Files\nodejs\node.exe.

A full quit means a full quit

Step 11: Config changes only load on a genuine restart, and closing the window is not a restart. On Windows, you need to right-click the Claude icon in the system tray and choose Quit — not just click the X. I lost real time here assuming a window close counted.

How to actually verify it’s working

Don’t rely on asking a question and guessing from the response — go to Settings → Developer → Local MCP servers. It lists every configured server with a live status (running, or an error), plus a View Logs button if something’s wrong. This is the fastest, most direct way to confirm a fix actually worked.

Then I asked the magic question: What’s my most recent Suunto workout ? And oh joy, it worked !! Claude replied with details of my latest workout.

Local MCP servers don’t work on mobile

One thing I didn’t realize until after all of this: everything above only works on the one computer where I set it up.

A local MCP server like this Suunto one is just a program — in this case a node process — running on your machine, launched by Claude Desktop, reading a config file and .env credentials that live on that machine’s disk. Claude’s mobile app has no way to reach any of that. There’s no PC to launch the process on, and no access to the local file or credentials it depends on.

Coros, by contrast, is a hosted connector — it runs on Coros’s own servers, not mine, so it follows my account everywhere: desktop, browser, mobile, all of it. That’s the real distinction to understand: local MCP servers are tied to one machine; hosted/remote ones follow your account.

Clearly this is a limitation to the Suunto connexion but I can accept that for historical data.

Conclusion

In conclusion, none of those steps are actually hard but there are things that make the whole setup derail, and some other things changed since Googlarz’ how-to was written. The 10-minute task can easily become an afternoon job so I hope this helps if you’re stuck.