MyFitnessPal MCP Service

A deployable Model Context Protocol (MCP) server for MyFitnessPal that works as a remote Claude connector: food diary, food search, exercises, body measurements, nutrition goals, water intake, and nutrition reports.

This is a fork of AdamWalt/myfitnesspal-mcp-python (MIT, tool implementations) restructured for remote deployment with the OAuth 2.1 / streamable-http transport skeleton from garmin-mcp-service. MyFitnessPal access is via coddingtonbear/python-myfitnesspal.

Tools

Food collections (recent / frequent / my foods)

mfp_get_recent_foods, mfp_get_frequent_foods, and mfp_get_my_foods each take an optional limit (recent/frequent default 10, my-foods default 100, max 100) and response_format (markdown or json). They intentionally use the legacy add-to-diary AJAX endpoints (/food/load_recent, /food/load_most_used, /food/load_my_foods) rather than the newer /food/mine, /meal/mine, or /food/new pages, which can redirect to /account/logout even when diary reads and API-token fetches still work.

Editing diary entries

mfp_get_diary with response_format=json now surfaces an entry_id for each meal entry. Pass that id to:

• mfp_update_food_entry - change meal, quantity, unit (serving-size label, e.g. "350 ml"), or weight_id (raw MFP serving-size option id, overrides unit) for an entry; requires date for historical entries. MyFitnessPal can rewrite an entry during edit, so the response reports current_entry_id and entry_id_changed so you can keep tracking the right row.
• mfp_delete_food_entry - delete an entry by entry_id (requires date for historical entries).

Creating a custom food

mfp_create_food submits a brand-new food to the MyFitnessPal database when mfp_search_food turns up nothing suitable. Required fields are description and the per-serving core macros (calories, fat, carbs, protein); brand, serving_size, servings_per_container, share_public, and the optional micronutrients (fiber, sugar, sodium, cholesterol, vitamins, etc.) round it out. All nutrition values are entered per single serving as defined by serving_size (e.g. serving_size="125 g" with the numbers for a 125 g portion). When the serving unit is a mass unit (g, mg, kg, oz, lb) the gram weight is recorded so MFP’s gram-based scaling stays correct.

On success it returns the new food’s mfp_id; pass that to mfp_add_food_to_diary to log it (it may take a short moment to also surface in mfp_search_food). Re-running with the same details creates duplicate foods.

share_public=True is irreversible — it submits the food to MyFitnessPal’s shared public database, and public foods can no longer be edited or deleted. Leave it False (default) to create a private food you can still delete.

Implementation note: the python-myfitnesspal library’s set_new_food() no longer works — MyFitnessPal replaced the server-rendered /food/new Rails form with a client-side SPA that has no authenticity_token input, so the library’s HTML scrape raises IndexError: list index out of range. mfp_create_food instead POSTs to the v2/foods API with the account’s bearer token (the same mechanism the library still uses for goals).

Authentication: the cookie strategy

MyFitnessPal’s login page is captcha-protected, so headless password login is dead - this server never asks for your MFP password. Instead it reads session cookies from one of:

1. Firefox profile sidecar (recommended): log into myfitnesspal.com once, interactively, in a Firefox profile; mount that profile directory read-only into the container at /profile. The server copies cookies.sqlite (and its WAL) to a temp file on each refresh - Firefox’s locks don’t matter - and extracts the myfitnesspal.com cookies. The copy is cached and only re-read when the file changes, so Firefox can keep running (e.g. a headless Firefox sidecar container you occasionally VNC into to re-login).
2. JSON cookies file: MFP_COOKIES_FILE pointing at {"cookies": {name: value}} (AdamWalt’s ~/.mfp_mcp/cookies.json format) or a plain {name: value} dict.

Session cookies expire eventually (~30 days); when tools start failing with auth errors, log into MFP again in that Firefox profile.

Environment Variables

Docker

docker build -t myfitnesspal-mcp-service .

docker run -d -p 8000:8000 \
  -v ~/.mozilla/firefox/abcd1234.default-release:/profile:ro \
  -e MCP_ALLOWED_HOSTS=mfp.example.com \
  -e MCP_RESOURCE_URL=https://mfp.example.com \
  -e MCP_OAUTH_PASSCODE="$(python3 -c 'import secrets; print(secrets.token_urlsafe(32))')" \
  ghcr.io/delize/myfitnesspal-mcp-service:latest

CI builds and pushes ghcr.io/delize/myfitnesspal-mcp-service (amd64 + arm64) on pushes to main and v* tags.

Claude Connector Setup

Same flow as garmin-mcp-service:

1. Deploy behind HTTPS (reverse proxy) with MCP_TRANSPORT=streamable-http, MCP_RESOURCE_URL, and MCP_OAUTH_PASSCODE set.
2. In Claude, add a custom connector with URL https://mfp.example.com/mcp. Leave OAuth Client ID/Secret blank - the server supports dynamic client registration (/register), authorization + PKCE (/authorize, /token).
3. Claude redirects you to the /login passcode page once; enter MCP_OAUTH_PASSCODE. After that the client holds and refreshes its own token.

The passcode proves “the caller knows the passcode”, not identity - keep network-level access control (IP allowlist, VPN) in front of any internet-facing deployment. Omitting MCP_OAUTH_PASSCODE/MCP_RESOURCE_URL runs the HTTP server unauthenticated (a warning is logged); only do that on a trusted network.

Behind an MCP Gateway: External OAuth / Okta JWTs (MCP_AUTH_MODE=oauth)

The passcode OAuth server above keeps its issued tokens in memory, so every container restart invalidates every client’s token. When the server sits behind an MCP gateway (e.g. LiteLLM) that obtains its own tokens from an identity provider, use MCP_AUTH_MODE=oauth instead: the server becomes a stateless OAuth 2.0 resource server that only verifies RS256 JWT access tokens issued by an external authorization server (Okta, or any issuer publishing a JWKS). Nothing is stored, so restarts are invisible to clients.

MCP_TRANSPORT=streamable-http
MCP_AUTH_MODE=oauth
MCP_OAUTH_ISSUER=https://your-org.okta.com/oauth2/default   # required
MCP_OAUTH_AUDIENCE=api://default                            # default; comma list allowed
MCP_OAUTH_REQUIRED_SCOPES=mfp.read                          # default; comma list, ALL required
MCP_OAUTH_ALLOWED_CLIENT_IDS=0oaXXXXXXXXXXXXXXXX            # optional; token's `cid` must be listed
# MCP_OAUTH_JWKS_URI=https://your-org.okta.com/oauth2/default/v1/keys   # default: ${issuer}/v1/keys
# MCP_OAUTH_CLOCK_TOLERANCE_SEC=30                          # default 30

Behaviour in oauth mode:

• Only RS256 is accepted (HS*, none etc. are rejected before any key lookup).
• Signing keys are cached for an hour; a token with an unknown kid triggers a refetch (key rotation), rate-limited to one refetch per 10s.
• No Authorization header → 401 with WWW-Authenticate: Bearer realm="mfp-mcp".
• Malformed header, bad signature, wrong iss/aud, expired, unknown kid, or a cid not in the allow-list → 401 with error="invalid_token".
• Valid token missing a required scope → 403 with error="insufficient_scope".
• The JWKS cannot be fetched and no key is cached → 503.
• The built-in OAuth endpoints (/authorize, /token, /register, /revoke, /login, /.well-known/*) are not mounted (404), so there is a single auth path. MCP_OAUTH_PASSCODE/MCP_RESOURCE_URL are ignored.
• Tokens are never logged.

The token’s sub is not used for authorization - the server still acts as the single MyFitnessPal account behind its cookie source - but any token from the configured issuer/audience/client with the required scope is accepted. Per-user tokens (e.g. Okta Cross App Access / ID-JAG, where sub is the user’s email) and machine tokens (client credentials) both work.

Okta setup: in your Okta custom authorization server, add a scope mfp.read and an access policy rule that lets the gateway’s client obtain tokens with it (via Cross App Access for per-user tokens, or the Client Credentials grant for a machine token). Set MCP_OAUTH_ISSUER to that authorization server’s issuer URL, MCP_OAUTH_AUDIENCE to its audience, and MCP_OAUTH_ALLOWED_CLIENT_IDS to the gateway’s client id.

Migrating from passcode OAuth:

1. Set up the Okta scope/policy above and configure the gateway to send Authorization: Bearer to /mcp.
2. On this container set MCP_AUTH_MODE=oauth, MCP_OAUTH_ISSUER, MCP_OAUTH_AUDIENCE and (recommended) MCP_OAUTH_ALLOWED_CLIENT_IDS; remove MCP_OAUTH_PASSCODE/MCP_RESOURCE_URL/MCP_ACCESS_TOKEN_TTL (they are ignored in this mode).
3. Restart and check the logs: a missing or invalid MCP_OAUTH_* setting aborts startup instead of running without auth. Clients that used the passcode flow directly (Claude/ChatGPT connectors) must go through the gateway now.

docker run -d -p 8000:8000 \
  -v ~/.mozilla/firefox/abcd1234.default-release:/profile:ro \
  -e MCP_AUTH_MODE=oauth \
  -e MCP_OAUTH_ISSUER=https://your-org.okta.com/oauth2/default \
  -e MCP_OAUTH_AUDIENCE=api://default \
  -e MCP_OAUTH_ALLOWED_CLIENT_IDS=0oaXXXXXXXXXXXXXXXX \
  ghcr.io/delize/myfitnesspal-mcp-service:latest

Leaving MCP_AUTH_MODE unset keeps the old behaviour exactly. MCP_AUTH_MODE=none is an explicit opt-in to no auth; MCP_AUTH_MODE=passcode_oauth is the passcode server with both variables strictly required.

Local stdio use

For local stdio use (Claude Desktop):

{
  "mcpServers": {
    "myfitnesspal": {
      "command": "python",
      "args": ["-m", "myfitnesspal_mcp.server"],
      "env": {
        "MFP_FIREFOX_PROFILE_DIR": "/home/you/.mozilla/firefox/abcd1234.default-release"
      }
    }
  }
}

Troubleshooting

Tools don’t appear even though the connector shows “Connected”

Problem: The connector authorizes and shows as Connected, but its tools never surface in a conversation - asking the model to use them, or searching for them, turns up nothing. No error is shown.

Cause: This is almost always a client-side tool-budget limit, not a problem with this server. Claude caps how many tools can be active in a single conversation across all connected servers combined. If another connector exposes a very large tool set, it can consume that budget and silently crowd this server’s tools out of the conversation. (Seen in practice with a connector exposing ~170 tools starving this server’s handful.)

Confirm / fix:

1. In a fresh conversation, disable the other large connector(s) and check whether these tools now appear. If they do, it was the budget.
2. Keep high-tool-count connectors in separate conversations, or trim their active tools if the client supports per-tool toggles.
3. This server always returns its full tool list regardless - you can verify independently with an authenticated tools/list call against /mcp. If that returns the tools but the client doesn’t show them, the gap is on the client side, not here.

Attribution

• Tool implementations: AdamWalt/myfitnesspal-mcp-python (MIT, this repo is a fork - full history preserved)
• MyFitnessPal client library: coddingtonbear/python-myfitnesspal
• OAuth/transport skeleton: garmin-mcp-service

License

MIT - see LICENSE (preserves the original copyright).