Training Plan Management + MCP-based third-party integrations

[lucaspal]

Hi Robin 👋

I'd love to start a conversation about a possible evolution: using SfS as a central training plan manager, with MCP-based connectors to push/pull workouts to third-party services.

The idea in short:

• SfS holds the canonical training plan (weekly structure, workout targets, periodization)
• Mark (or a dedicated agent) generates/adjusts the plan based on CTL/ATL/TSB, goals, etc.
• MCP plugins communicate with external platforms: e.g. MyWhoosh MCP, Intervals.icu MCP, Hevy, etc.

Questions / thoughts for you:

1. Are you considering to add a write model (workout/plan storage) to SfS, or is the vision firmly analytics-only?
2. Would a plugin/extension mechanism (similar to how Shoutrrr abstracts notifications) make sense for third-party integrations?
3. Is Mark's conversation state meant to become persistent, or remain ephemeral per session?

I'm a backend developer (Java/Spring) and would be happy to contribute, prototype, or just keep this as a design discussion. Totally understand if this is out of scope for the current direction. Just wanted to plant the seed 🌱

Thanks again for everything!

Resources (MCPs)

• https://github.com/mywhoosh-community/mywhoosh-mcp-server
• https://github.com/mvilanova/intervals-mcp-server
• https://github.com/chrisdoc/hevy-mcp

[robiningelbrecht]

Hi @lucaspal,

Thanks for writing out your idea.

Are you considering to add a write model (workout/plan storage) to SfS, or is the vision firmly analytics-only?

There is a good reason SfS currently is a read-only and analytics-only app. We consider Strava to be the write model, SfS is the read model and just processes what Strava tells it to process. This allows us to ignore authentication and authorization flows as Strava does this for us. Introducing a write model into SfS would imply we need to add a full user authentication flow, which I'd like to stay away from as long as possible.

For example: a lot op people ask to allow to configure settings via the UI. This, for me personally, is not worth the effort to introduce user authentication. A new killer feature might be though.

I'm just wondering, we have lots of training plan management apps out there no?

Would a plugin/extension mechanism (similar to how Shoutrrr abstracts notifications) make sense for third-party integrations?

I guess you are referring to a mechanism to push activities to third party services? If so, yes, the existing integration namespace would be ideal for that.

Is Mark's conversation state meant to become persistent, or remain ephemeral per session?

The reason I initially did not add state to the agent is because the package we are using (NeuronAI), was buggy at the time when using chat history. In the mean time they released a new major version, so it might be a good idea to revisit this decision.

[lucaspal]

There is a good reason SfS currently is a read-only and analytics-only app.

I imagined the intent was to keep SfS read-only and that's totally fine - I wanted to hear it from you though :)

I'm just wondering, we have lots of training plan management apps out there no?

At the moment, I am looking for a platform that would aggregate everything for me. I don't like the idea of this being Garmin for 3 reasons: 1) I have a Wahoo bike computer and I am not planning to change 2) Garmin strength is quite bad to use 3) I don't want to be bound that much to their ecosystem.
I am not sold to TrainingPeaks - beautiful suite but my current level does not justify the premium account at the moment (plus the same ecosystem argument applies).
The best candidate is intervals.icu but the UI is not really nice and this is still not OSS.

SfS is really special because it looks good, it has all the nice metrics and features (you can really see that it comes from a person that knows what he's doing) and it ticks the OSS box.

I guess you are referring to a mechanism to push activities to third party services? If so, yes, the existing integration namespace would be ideal for that.

I was rather thinking about add-ons to SfS but can you tell me more about integration namespace? I tried to search in the documentation but I couldn't find any resource.

[robiningelbrecht]

Going down the road of being a training plan management app, would mean massive amounts of development work.
Before even considering this, we would need a proper analysis of what we want and need. Both in written form as in mockups.

I don't have any experience with (good) training plan apps, as as just go with the flow. So I'd need to delve into the world of training apps. Keeping in mind that such feature should work for all sport types.

I was rather thinking about add-ons to SfS

Could you give some quick examples?

[lucaspal]

I agree, it is a bigger topic and we shouldn't just jump into it. I will keep an eye on the Github discussions and contribute if I can.

Regarding the add-ons, it was more wishful thinking than concrete ideas, I was thinking about ways to keep the core as a read only view of the training data and keep all other functionalities separate. Whether that ends up being implemented in an event driven fashion, exposing a REST api or something completely different is still an open question :)