MyFitnessPal MCP

Log MyFitnessPal by talking to your AI.

Quickstart · Tools · Authentication · Changelog

▶ Watch the launch video

MyFitnessPal MCP is a free, open-source MCP server that connects MyFitnessPal to Claude, Cursor, VS Code, or any MCP client. Log meals by talking, search the food database with macros, track trends, and export your nutrition history, all against your real MyFitnessPal diary.

Published on PyPI as mfp-mcp and in the official MCP Registry as io.github.Mason-Levyy/mfp-mcp.

Unofficial. MyFitnessPal has no public API; this reverse-engineers the

web app's own endpoints. It can break whenever MFP changes their site. Use at

your own risk, with your own account.

Why this one?

MyFitnessPal moved behind Cloudflare + NextAuth, which broke the username/password login that most existing integrations rely on. This server:

• Authenticates with your browser session cookie over a real Chrome TLS fingerprint (curl_cffi), which passes Cloudflare
• Auto-refreshes the session (optional): a headless browser profile rotates the token when it expires, and failed calls retry automatically
• Writes, not just reads: log, modify, and delete real diary entries
• Search-then-log: get candidates with macros, then log the exact item

Quickstart

1. Connect your account (one-time; prompts you to paste a cookie — see Authentication):

   uvx mfp-mcp auth

1. Add the server to your client. The install buttons at the top do this in one click for Cursor and VS Code.

Claude Code

   claude mcp add myfitnesspal -- uvx mfp-mcp

Or install it as a plugin:

   /plugin install myfitnesspal-mcp --marketplace Mason-Levyy/myfitnesspal-mcp

Claude Desktop (claude_desktop_config.json), Cursor (~/.cursor/mcp.json), Windsurf (~/.codeium/windsurf/mcp_config.json), and Cline (cline_mcp_settings.json) all take the same entry:

   {

"mcpServers": { "myfitnesspal": { "command": "uvx", "args": ["mfp-mcp"] } } }

VS Code, Codex CLI, Gemini CLI

VS Code (or use the button above):

   code --add-mcp '{"name":"myfitnesspal","command":"uvx","args":["mfp-mcp"]}'

Codex CLI:

   codex mcp add myfitnesspal -- uvx mfp-mcp

Gemini CLI:

   gemini mcp add myfitnesspal uvx mfp-mcp

1. Talk to it: *"log a banana as a snack"*, *"what did I eat yesterday?"*, *"chart my weight this month"*.

Requires uv. Any MCP client that speaks stdio or streamable HTTP works, not just Claude.

Finding this useful? A ⭐ on

GitHub helps other

MyFitnessPal users find it.

Authentication

This server signs in with your browser's MyFitnessPal session cookie:

1. Log in at myfitnesspal.com
2. Open DevTools (F12) → Application (Chrome) or Storage (Firefox) → Cookies → https://www.myfitnesspal.com
3. Copy the value of __Secure-next-auth.session-token
4. Paste it into the mfp-mcp auth prompt, or on macOS run mfp-mcp auth --clipboard and copy the cookie: it connects as soon as the token reaches the clipboard

Sessions last 30 days from their last renewal. The server renews the session whenever it builds a client and saves the cookies MyFitnessPal re-issues, so the saved session stays current as long as it's used at least once a month. mfp-mcp auth --check reports whether the saved session still works and whether auto-refresh is set up; it renews and saves the session as it checks and exits 1 when the session needs attention, so running it on a schedule (cron, launchd) keeps an idle session alive and warns before it lapses.

Auto-refresh (recommended)

With the autorefresh extra, auth also seeds a persistent headless browser profile. When MyFitnessPal rejects the session mid-call, the server tells your client it is retrying, boots the profile headlessly, lets MyFitnessPal rotate the session token, saves the fresh cookie, and retries the call.

uvx --from 'mfp-mcp[autorefresh]' playwright install chromium

uvx --from 'mfp-mcp[autorefresh]' mfp-mcp auth

Then use the same --from 'mfp-mcp[autorefresh]' form in your client config (e.g. uvx --from 'mfp-mcp[autorefresh]' mfp-mcp).

Tools

Logging flow

Food logging is draft-then-confirm, so what lands in your diary never depends on MyFitnessPal's search order:

1. fitness_draft_food("greek yogurt", min_protein=15, max_calories=150) returns numbered options. Each lists every serving size with calories and macros for the whole entry (serving × quantity) plus a suggested serving; options that meet the targets come first, near misses follow. Call it again with different targets to refine.
2. fitness_log_food(draft_id=..., option=2, serving=1) logs exactly that food and serving, and remembers the choice for that query.
3. Next time, fitness_log_food(query="greek yogurt") logs the remembered food and serving without searching.

A bare fitness_log_food(query=...) with nothing remembered logs only when exactly one result matches the name exactly; otherwise it logs nothing and returns a draft to choose from. Remembered choices live in the local cache (fitness_list_food_pins, fitness_clear_food_pin). Drafts expire after 24 hours.

fitness_modify_food picks the replacement the same way, before deleting anything: a remembered food or a single exact-name match is used directly; otherwise the entry is left alone and a draft comes back — call fitness_modify_food again with the same query plus draft_id and option.

fitness_log_food, fitness_delete_food, and fitness_modify_food all take a meal argument the same way: breakfast/lunch/dinner/snacks, or the literal name of any meal section currently on your diary — including a renamed default meal or one of the up to two extra meals MyFitnessPal lets you add in Diary Settings. Matching is case-insensitive against your account's current meal labels. If you renamed a default meal, the keywords still work: breakfast/lunch/dinner/snacks fall back to your first through fourth meal, unless that slot now carries a different default name (e.g. lunch won't land in a second meal you renamed to "Dinner"). Any other unrecognized meal raises an error instead of silently logging into the wrong section.

Day summaries and trends read from a local SQLite cache that gap-fills from MyFitnessPal (first call on a fresh install fetches up to 30 days, one request per day).

Water logging reads the day's current total from /food/water, adds the requested quantity, and posts the new total back to the same endpoint. Pass replace=True to set the day's total outright (e.g. to fix a mislogged amount); every call returns previous_ml, so a mistake can be reverted by passing it back as amount with unit="ml" and replace=True. The separate /stats request with a water_logged event is analytics telemetry; it does not persist the water total.

Remote / HTTP mode

The default transp