DEV Community: Flavio Sacca

How I Built an AI Coach: Claude + Garmin, Yazio and FitDays via MCP, with a Git Repo as Memory

Flavio Sacca — Tue, 06 Oct 2026 13:08:47 +0000

The starting point

My Garmin watch knows how much I sleep and tracks all my health metrics, Yazio knows what and how much I eat and my FitDays scale knows how much I weigh and (more or less) how much lean mass I have.

I had the data but nobody able to read it. Turning it into something useful (a meal plan, a training program, an answer to "why am I not improving?") takes someone who can cross-reference sleep, calories and weight and turn them into a decision: a nutritionist, a personal trainer. So I asked myself: what if an AI did that reading, with my real numbers, and answered my questions in real time?

So I connected Claude to all three through MCP (Model Context Protocol) and gave it a clear role: nutritionist and personal trainer, with written rules, persistent memory in a git repo, and a set of commands for recurring tasks. The result is an AI coach that reads my real data, writes plans, syncs them to my Garmin calendar, and remembers why it made every decision.

In this article you'll find:

how I wired up the MCP servers (with alternatives if you use MyFitnessPal or a Renpho scale);
the CLAUDE.md that turns a generic chatbot into a coach;
how file-based memory works, and why it's the most important part;
the slash commands I use every day and every week;

Note: I'm Italian, so the original prompts and file names in the repo are in Italian. The snippets in this article are translated.

The architecture: three sources of truth and a repo that remembers

The system has two halves:

The first is the MCP servers, which give Claude read and write access to my data
The second is a plain git repository that acts as brain and memory: Claude reads it at the start of every session and updates it at the end.

Each server owns one domain, and the coach must not mix them up:

Domain	Source	What it provides
Activity and recovery	Garmin	workouts, sleep, HRV, resting heart rate, body battery, training status
Nutrition	Yazio (or MyFitnessPal)	calories and macros consumed, foods, water
Weight and body composition	FitDays (or Renpho)	weight, body fat, lean mass

The repo looks like this:

coach_planner/
├── CLAUDE.md              # role, rules, red flags: the "system prompt"
├── RIFERIMENTI.md         # (references) MCP server gotchas
├── .claude/commands/      # slash commands (/checkin, /settimana, ...)
├── profilo/               # (profile)
│   ├── anagrafica.md      # stable data, equipment, body measurements
│   ├── obiettivi.md       # goals: ACTIVE / ON HOLD / HISTORY
│   └── preferenze.md      # what I eat, how much time I have
├── piani/                 # (plans)
│   ├── dieta/CORRENTE.md          # current diet
│   └── allenamento/CORRENTE.md    # current training
├── memoria/               # (memory)
│   ├── DIARIO.md          # session log, append-only
│   ├── apprendimenti.md   # learnings: what works for me
│   └── decisioni.md       # decisions: why we chose what
└── dati/                  # append-only CSVs: weight, nutrition, workouts, weeks

Using Markdown and CSV files inside git is deliberate: both Claude and I can read them, I can edit them by hand when needed and every session ends with a commit, so if the coach makes a bad call I have the full history of what it knew and why it decided what it did.

Setting up the MCP servers

All three servers I use are community projects built on unofficial or reverse-engineered APIs. They work well, but they can break overnight: keep that in mind before building anything critical on top of them.

Garmin

Taxuspt/garmin_mcp exposes 110+ tools: activities, sleep, HRV, weight and, most importantly, creating and scheduling workouts on the Garmin calendar. You authenticate once from the terminal, and the OAuth tokens are stored in ~/.garminconnect.

Tokens last about six months. When they expire, the fix is to re-run the auth with --force-reauth, not to retry the call.

Yazio

fliptheweb/yazio-mcp runs with npx and reads daily summaries, consumed items, goals and water intake. It can also add and remove foods from your diary.

FitDays

roquerodrigo/fitdays-mcp-server is read-only: weight history, latest measurement, users and devices on the account. It requires Node.js 22+.

The configuration

In the project root I keep a .mcp.json that reads credentials from environment variables, so they never end up in the repo:

{
  "mcpServers": {
    "garmin": {
      "command": "uvx",
      "args": ["--python", "3.12", "--from",
               "git+https://github.com/Taxuspt/garmin_mcp", "garmin-mcp"]
    },
    "yazio": {
      "command": "npx",
      "args": ["-y", "yazio-mcp"],
      "env": {
        "YAZIO_USERNAME": "${YAZIO_USERNAME}",
        "YAZIO_PASSWORD": "${YAZIO_PASSWORD}"
      }
    },
    "fitdays": {
      "command": "npx",
      "args": ["-y", "fitdays-mcp-server"],
      "env": {
        "FITDAYS_EMAIL": "${FITDAYS_EMAIL}",
        "FITDAYS_PASSWORD": "${FITDAYS_PASSWORD}"
      }
    }
  }
}

The Garmin server needs no credentials in the config: it uses the saved tokens. If its 110 tools flood the context, the GARMIN_ENABLED_TOOLS variable lets you pass an allowlist of just the tools you need.

Alternatives: MyFitnessPal and Renpho

If you use different apps, the system works the same way: only the tool names referenced in CLAUDE.md and the commands change.

MyFitnessPal → AdamWalt/myfitnesspal-mcp-python. Reads and writes diary, measurements, exercises and water. One advantage over Yazio: it has mfp_set_goals, so the coach can update calorie and macro targets on its own. Requires Python 3.10–3.12 and preferably authenticates using cookies from a logged-in browser session.
Renpho → StartupBros-com/renpho-mcp-server. Full body composition, trends over N days, and diagnostic tools for measurements that don't sync. It works with the Renpho Health app (not the legacy one) and you install it by cloning the repo and building it.

CLAUDE.md: from chatbot to coach

Connecting the data is the easy part. Without instructions, Claude with access to the apps is a great analyst that tells you generic things. CLAUDE.md is where I tell it who it is, what it can do and, above all, what it must not do. Here are the parts that made the difference.

An opening ritual and a closing one

Every session starts by reading the profile, the current plans, the last lines of the log and all the learnings. And it always ends the same way:

## Session close — ALWAYS
1. Max 8 lines in `memoria/DIARIO.md`.
2. Plan changed → archive to `archivio/YYYY-MM-DD-*.md`, rewrite `CORRENTE.md`,
   rationale in `memoria/decisioni.md`.
3. New data → append to `dati/*.csv` (never rewrite, never duplicate dates).
4. `git add -A && git commit -m "session YYYY-MM-DD: <what>"`

This is what makes the memory reliable: it doesn't depend on Claude "remembering" to save, it's a mandatory step.

A coach that lasts years, not a workout generator

My favorite section is about goals. One primary goal at a time, each with a measurable exit criterion, and transitions handled explicitly:

- One primary goal at a time. If I ask for a new one while one is active,
  stop: either we close the old one or the new one goes ON HOLD. Don't stack them.
- Flag conflicts. Calorie deficit + maximum strength gain, or high-volume
  running + aggressive hypertrophy, don't coexist. Tell me the cost, propose a
  sequence, not a silent compromise.

Without this rule, an LLM tends to please you: ask for strength and fat loss and it hands you a plan that does both badly.

Writes always require confirmation

The coach can create workouts on Garmin and log foods on Yazio, but never on its own initiative. It first shows exactly what it's about to write, then waits for my OK. If there are five operations, it lists them all and asks for a single confirmation, so a session doesn't turn into a barrage of "yes".

Non-negotiable rules and red flags

There are numbers the coach can't cross, whatever I ask: maximum deficit of 20–25% of TDEE, an absolute calorie floor, protein between 1.6 and 2.2 g/kg, a deload every 4–6 weeks. TDEE must be recalculated from real data (average calories vs. weight change) as soon as there are two weeks of history, not estimated with a formula.

Then there's a list of red flags that stop everything and send me to a doctor: chest pain, dizziness during exercise, HRV dropping and resting heart rate rising for more than 10 days, under 5 hours of sleep on average, weight loss that's too fast, signs of a disordered relationship with food. The coach is not a doctor, and it knows it.

How to read the scale

I weigh myself every morning, and that's a risk: a coach that comments on every weigh-in will drive you crazy. So the rule is strict: never comment on a single weigh-in, reason only on 7-day moving averages, compare averages with averages. And never use weight as a motivational lever, in either direction.

Memory: four files with four different jobs

The weak spot of any "AI coach" is that every conversation starts from scratch. I solved it with Markdown files split by purpose, because a single notes file becomes unreadable within weeks.

File	Purpose	Rule
`memoria/DIARIO.md`	what happened in each session	append-only, max 8 lines per session
`memoria/apprendimenti.md`	what works for me	read in full every session; disproven hypotheses get struck through, not deleted
`memoria/decisioni.md`	why we chose what, and the rejected alternatives	never delete old decisions
`dati/*.csv`	time series of weight, nutrition, workouts, weeks	append-only, no duplicate dates

The split between log and learnings is the heart of the system: the log is a chronicle, the learnings are knowledge; a pattern is promoted from the log to the learnings only when it has repeated at least three times, and when a hypothesis is disproven it stays visible, struck through, with the new one below it.

The decisions file also records the rejected alternatives. It sounds like bureaucracy, but it's what stops the coach from re-proposing, two months later, the same idea you had already ruled out, without knowing why.

The goals file (obiettivi.md) is also built to last:

ACTIVE: a single goal, with an exit criterion and a review date. If it's empty, the coach refuses to produce plans.
ON HOLD: what I want but am not pursuing now, with the reason and the prerequisite to unlock it.
HISTORY: every closed goal, with its outcome and why it ended. Never deleted.

Finally, the CSVs mean Claude doesn't have to call the MCP servers for every calculation. For planning it works on local data; it only queries the servers when it needs fresh data. Over time, when the log exceeds 200 lines, the weekly review command archives old entries and leaves a monthly summary.

The commands: the whole workflow in eight files

Recurring operations live in .claude/commands/, one Markdown file per command. That way I don't rewrite the prompt for a weekly review every time, and the coach always does it the same way. (Command names are in Italian; the translation is in brackets.)

Command	When	What it does
`/obiettivo` (goal)	when direction changes	orientation session: 90 days of data, max 5 questions, reality check. You leave with a written goal, not a workout plan
`/nuovo-piano` (new plan)	after `/obiettivo`	diet, training types, calendar for the whole mesocycle, sync to Garmin
`/checkin`	every morning	weight, yesterday's nutrition, sleep and HRV: 3 numbers, 1 deviation, 1 action. Max 10 lines
`/settimana` (week)	every week	real TDEE, red flag and goal check, at most one parameter changed, report in Markdown and PDF
`/spesa` (groceries)	when needed	shopping list for a typical week, grouped by aisle, with a PDF to use at the supermarket
`/viaggio` (trip)	holidays, surprises, illness	temporary adjustment without touching the current plans
`/analisi` (audit)	after manual edits	audit of the existing plan against today's preferences and goal
`/consolida` (consolidate)	when memory grows	compacts the log and promotes recurring patterns

`/nuovo-piano`: three separate confirmations

The most complex command is also the one with the most checkpoints. First it shows the diet numbers (TDEE, target, macros) and waits for an OK. Then it proposes training types, not the actual program yet, each with one line of reasoning tied to the goal:

For each proposed type, say in one line why I recommend it for THIS goal
(e.g. "weights 3x/week: preserve lean mass during the deficit" /
"Z2 running 2x/week: aerobic base without interfering with strength recovery").

Only then does it write the plans, generate a menu with 3–4 interchangeable options per meal, and propose the calendar for the entire mesocycle. Then, if the user accepts, it syncs and schedules the workouts to Garmin.

`/settimana`: one parameter at a time

The weekly review recalculates TDEE from real data with a simple formula:

real TDEE = average kcal − (weight change × 7700 / days)

Then it decides, in this order: red flags, goal status against the exit criterion, any correction. The rule is to change at most one parameter at a time, with the rationale written in decisioni.md. If you change calories and volume together and things improve, you don't know what worked.

If the exit criterion has already been met, the coach must not keep going on autopilot: it sends me back to /obiettivo to close the goal and decide the next phase.

Prompt design lessons

Separate the sources of truth. Weight from FitDays, food from Yazio, activity from Garmin. Garmin and Yazio both know something about weight and calories, and without an explicit rule the model picks whichever source it happens to hit. If two sources disagree, it must say so instead of picking silently.

Write numbers, not adjectives. "Easy run" meant 170 bpm to me. "Z2 run, HR < 145, max 40 minutes" didn't. That applies to Claude as much as to me.

Make the model stop. The most useful commands have points where Claude must stop and ask: types before the program, calendar before the sync, report before changes in /analisi. Without them, an LLM tends to produce everything in one go and get you to accept the whole package.

Give it permission to say no. Calorie floor, red flags, missing goal: there are situations where the right answer is not producing a plan. It has to be written explicitly, otherwise the model always finds a way to please you.

Remove the noise from answers. "No repeated disclaimers, no 'consult a professional' in every answer" sounds like asking for less caution. It's the opposite: with precisely defined red flags, the warning comes when it's needed and doesn't get lost among a hundred generic ones.

Limits

A few honest caveats before you copy the project.

It's not a doctor. CLAUDE.md says so explicitly: no diagnoses, no blood tests, no medication. If you have a medical condition, the coach is for organizing, not deciding.
The APIs are unofficial. Yazio, FitDays, Renpho and MyFitnessPal don't offer public APIs: the servers rely on reverse engineering and can stop working after an app update.
This is health data. Weight, body composition, sleep, heart rate. Keep credentials in environment variables and .env in .gitignore, and think twice before making a repo with your data public.
Bioimpedance is imprecise. The absolute body-fat value from a home scale is worth little; the trend over weeks is worth a lot more. The coach is instructed to reason that way.

If you have ideas to improve the commands or just want the source code of the repo, let me know in the comments.

Building an enterprise Claude Code marketplace

Flavio Sacca — Fri, 18 Sep 2026 12:46:46 +0000

If you're rolling out Claude Code across a company, at some point you’ll eventually hit the same question I did: how do you distribute internally built artifacts (skills, commands, subagents and MCPs) to every developer, without asking each person to hand-configure things one by one and, maybe, forcing them to use only some tool?

The answer turned out to be simpler than expected: Claude Code plugin marketplaces, hosted on a regular Git repo (GitLab, GitHub…). Here's what I learned setting one up, including where I initially got the mental model wrong.

The building block: a plugin marketplace

A marketplace is just a Git repo with one manifest file:

my-marketplace/
└── .claude-plugin/
    └── marketplace.json

{
  "name": "acme-internal-marketplace",
  "owner": { "name": "ACME Platform Team", "email": "platform-team@acme.example.com" },
  "plugins": [
    {
      "name": "acme-sentry-http",
      "source": "./plugins/acme-sentry-http",
      "description": "Sentry integration via remote MCP server",
      "version": "1.0.0"
    }
  ]
}

Anyone on the team runs:

/plugin marketplace add <your-repo-url>
/plugin install acme-sentry-http

and that's it: one command installs everything the plugin bundles, whether that's an MCP server, a skill, a command or a subagent. There's no separate "install the skill" vs "install the agent" step.

A quick note: your own marketplace doesn't have to contain only internally-built artifacts. A plugin entry's source can point anywhere: a subfolder of your repo or straight at someone else's GitHub repo, so you can re-list a good third-party plugin under your own governance umbrella instead of telling people to go find it themselves.

Say your team likes “ponytail”, an unofficial but well-maintained plugin: you'd vet it once, pin it to a commit and add it to your marketplace.json.

{
  "name": "acme-internal-marketplace",
  "owner": { "name": "ACME Platform Team", "email": "platform-team@acme.example.com" },
  "plugins": [
    { "name": "acme-sentry-http", "source": "./plugins/acme-sentry-http" },
    { "name": "acme-internal-crm", "source": "./plugins/acme-internal-crm" },
    {
      "name": "ponytail",
      "source": {
        "source": "github",
        "repo": "dietrichgebert/ponytail"
      },
      "description": "Third-party plugin, vetted and pinned by the Platform Team — not maintained by ACME."
    }
  ]
}

The four things a plugin can bundle

This was the part that took me a minute to get straight, because they all superficially "teach Claude how to do something", but the trigger mechanism and execution context are
genuinely different for each.

	Trigger	Runs where	Best for
MCP server	Always connected once plugin is enabled	External process/API	Giving Claude access to a system (CRM, monitoring, fitness data...)
Command	User types `/name` explicitly	Main conversation	A prompt you'd otherwise retype constantly
Skill	Claude decides it's relevant, based on the task	Main conversation	Domain knowledge / house conventions Claude should apply without being asked
Agent	User or Claude invokes it explicitly or automatically	Isolated context, returns only the final result	Heavy, multi-step work you don't want cluttering the main thread

Focus on - Agents

The one that surprised me most is the agent, because it's the only one of the four
that runs in a separate context window. If a task needs to crawl through dozens of files
or call a tool a hundred times, doing it as an agent keeps that noise out of your main
conversation, so you can keep only a clean summary instead of the full trace.

A minimal agent looks like this:

---
name: garmin-analyst
description: Analyzes training load, HRV and sleep trends from Garmin data. Use PROACTIVELY when the user asks about recovery or overtraining.
tools: mcp__garmin
model: sonnet
---

You are a sports physiology specialist. When given Garmin data (HRV, training load, sleep), interpret trends cautiously, flag overtraining patterns, and never give direct medical advice.

Focus on - MCP servers

I ended up needing three distinct
patterns:

1. Remote HTTP, SaaS-hosted (e.g. Sentry)

{
  "mcpServers": {
    "sentry": { "type": "http", "url": "https://mcp.sentry.dev/mcp" }
  }
}

No secrets in the file — either the remote server handles OAuth itself, or you
interpolate an env var for headers ("Authorization": "Bearer ${SENTRY_MCP_TOKEN}"). You should never hardcode a token in something that lives in a shared repo.

2. Stdio, published npm/pip package

{
  "mcpServers": {
    "filesystem": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem@1.2.3", "${WORKSPACE_DIR:-.}"]
    }
  }
}

Remember to always pin the version. npx -y package-name with no version means every user auto-pulls whatever gets published next, including a compromised release if that
ever happens upstream.

3. Stdio, internally built binary

{
  "mcpServers": {
    "acme-crm": {
      "type": "stdio",
      "command": "${CLAUDE_PLUGIN_ROOT}/bin/acme-crm-mcp",
      "args": ["--config", "${CLAUDE_PLUGIN_ROOT}/config/crm-config.json"],
      "env": { "ACME_CRM_API_URL": "https://crm-internal.acme.example.com/api" }
    }
  }
}

${CLAUDE_PLUGIN_ROOT} resolves to wherever the plugin got installed, so the path
works on any machine. Ship the compiled binary inside the plugin for zero-setup onboarding, or point to a pre-installed binary on PATH if it's already distributed some other way (apt/brew/choco/provisioning script): the trade-off is repo size and zero-config vs. syncing two release pipelines.

Enterprise governance

Everything above is opt-in (you make things available, users choose) and doesn’t lock out other sources (users can bypass you repo and install an artifact from any repo).

If you need to actually force the issue instead there are two separate knobs, and it's worth knowing them in order because they lock down two different layers.

1. Restricting MCP servers. allowedMcpServers + allowManagedMcpServersOnly: true in managed settings restricts which MCP servers are allowed to run at all, regardless of where they'd otherwise come from (plugin, project .mcp.json, or a user's own config). This is the narrower lock: it doesn't touch what plugins, skills or commands someone installs, it only decides whether the MCP connections inside them are permitted to actually start.

{
  "allowedMcpServers": ["sentry", "acme-crm", "filesystem"],
  "allowManagedMcpServersOnly": true
}

2. Restricting plugins/marketplaces. strictKnownMarketplaces in managed settings restricts which marketplaces Claude Code will even talk to. Set this and any /plugin marketplace add pointing somewhere not on your list (including Anthropic's own default marketplace if not specified) is rejected outright.

Nothing outside your approved marketplace(s) is even visible to /plugin, let alone installable.

{
  "extraKnownMarketplaces": {
    "acme-internal": {
      "source": { "source": "git", "url": "https://gitlab.acme.example.com/platform/claude-marketplace.git" }
    }
  },
  "strictKnownMarketplaces": true,
  "enabledPlugins": {
    "acme-sentry-http@acme-internal": true,
    "acme-internal-crm@acme-internal": true
  }
}

Stack the two and you get the pairing you actually want for governance: MCP servers restricted (only connections coming from your approved plugins are allowed to run) and plugins restricted (only your marketplace is even reachable) while still leaving you room to fold in vetted external tools under your own review, instead of forcing everything to be built in-house.

Users get /plugin, see your curated list, and that's the whole universe: nothing else shows up, and nothing else installs even if they try.

Takeaway

If you're standardizing Claude Code across a team, a single Git repo with a marketplace.json gets you a long way: internal + curated external skills, commands, subagents and MCP connections, all installable with the same two commands, versioned and reviewable like any other code.

The main things worth getting right up front are version-pinning anything that comes from outside your org, and keeping credentials out of the manifests entirely.