wger MCP server

[!IMPORTANT] This is still a WIP, not all things might work correctly yet

An MCP server that exposes the wger (>= 2.7) fitness/nutrition REST API as tools (routines, workout logging, exercise & ingredient catalog, nutrition plans + meals + recipes, diary, body-weight tracking, gym equipment, body measurements, volume/PR analytics, daily calorie calculator, …) so that AI assistants can read and write your wger data.

It talks to a wger instance over its public REST API — it is a separate service and requires no changes to wger itself.

• Transport: stdio for a local server your MCP client spawns, or Streamable HTTP (FastMCP) for a shared deployment. Pick with --transport.
• Auth: multi-user — every request acts as the calling user’s own wger account. wger is itself the OAuth2/OIDC provider, so nothing else is needed (MCP_AUTH=wger_oidc); behind an existing SSO, an external OIDC IdP does the same job with a token exchange (MCP_AUTH=oidc). For single-user self-hosting, MCP_AUTH=static_token takes a shared secret plus your wger API key instead.
• Requires: wger >= 2.7, Python >= 3.11. The server reads wger’s version once at startup and warns if it is older than the API client expects (the major and minor of the installed wger-api-client), naming both. It warns rather than refuses: the exercise and ingredient catalogs are stable across releases and keep working, while the tools built on newer endpoints fail visibly when called.

How auth works

This section describes the HTTP deployment, where several people share one server. Running locally over stdio? None of it applies — skip to Quick start — local, over stdio, where a wger API key is the only credential.

Every request acts as the calling user’s own wger account, so the server needs a per-user wger credential. Where that comes from is the one real choice, and wger 2.7 changed the answer.

On wger >= 2.7 — MCP_AUTH=wger_oidc, the short path. wger is itself an OAuth2/OIDC provider and its REST API accepts the access tokens it issues. There is nothing to broker: the caller’s token goes back out unchanged.

client → MCP    Authorization: Bearer    (via MCP-native OAuth)
MCP → wger      Authorization: Bearer   on /api/v2/*

No identity provider, no client credentials, no exchange — WGER_BASE_URL is the entire configuration. Because the login runs in the user’s browser through wger’s own login page, MFA enrolled in wger simply works. The tokens are opaque, so this server does not validate them: wger decides on every call whether a token is live and which scopes it carries. See docs/adr/0005-native-wger-oidc.md.