foodvisor-mcp

Un servidor remoto del Model Context Protocol que expone la API de nutrición de Foodvisor a agentes LLM (Claude, Cursor, …). Busca alimentos, registra comidas, obtén el progreso y los macros, todo desde tu asistente.

Aviso legal. Este proyecto es no oficial. Utiliza la API móvil privada de Foodvisor mediante ingeniería inversa de sus peticiones y no cuenta con el respaldo de Foodvisor. Úsalo bajo tu propia responsabilidad; los endpoints pueden cambiar sin previo aviso.

Características

• 🥗 Búsqueda en el catálogo con calorías, macros, marca, imagen y Nutriscore.

• 📒 Registro de comidas (desayuno/almuerzo/cena/snack/personalizado_*) con cantidades y multiplicadores de porción.

• 📊 Resumen diario — agregación en el servidor de calorías y macros frente a tus objetivos.

• 📈 Progreso — historial diario de calorías, peso y calificación (≈90 días).

• 🔥 Racha — días consecutivos de registro actuales y congelaciones disponibles.

• 💧 Registro de hidratación.

• 👤 Perfil y objetivos nutricionales — objetivos de calorías/macros por día de la semana.

• 🔐 OAuth 2.1 + PKCE con registro dinámico de clientes — funciona como un conector de un solo clic para Claude.

• 🔄 Multiusuario sin estado: los tokens son autónomos (sin base de datos). Los tokens de actualización de Foodvisor están cifrados (AES-256-GCM) dentro del JWT emitido por OAuth.

• ♻️ Actualización automática del token de acceso con caché en memoria y protección contra avalanchas de peticiones.

Herramientas MCP disponibles

Inicio rápido con Docker

git clone https://github.com/cldt-fr/foodvisor-mcp.git
cd foodvisor-mcp
docker compose up -d

El servidor ahora escucha en http://localhost:3000/mcp. Sonda de salud en /health.

Para ejecutarlo detrás de un proxy inverso (Caddy, Traefik, nginx) en un dominio público, simplemente termina el TLS frente al puerto 3000.

Autenticación

foodvisor-mcp admite dos formas de autenticarse, ambas respaldadas por la misma credencial subyacente: tu token de actualización de Foodvisor:

1. OAuth 2.1 (recomendado) — el servidor es un servidor de autorización OAuth completo con registro dinámico de clientes y PKCE. Los clientes MCP compatibles (Claude, Cursor, …) gestionan el flujo automáticamente: descubren los endpoints de autenticación, se registran y abren una página de inicio de sesión donde pegas tu token de actualización de Foodvisor una vez. El servidor emite entonces su propio JWT con tu token de actualización cifrado con AES-256-GCM en su interior.

2. Bearer directo (usuario avanzado) — pasa tu JWT de actualización de Foodvisor directamente como Authorization: Bearer …. Útil para scripts o pruebas rápidas. El servidor detecta el formato del token y actúa como proxy como antes.

De cualquier manera, no se almacena estado por usuario en el servidor: el JWT emitido por OAuth es autónomo y el modo heredado es puramente de paso.

Obtención de tu token de actualización de Foodvisor

Foodvisor solo se autentica mediante Apple Sign-In en iOS; no hay un endpoint público de OAuth o contraseña. Captura la respuesta POST /user/auth/ en un iPhone real con Charles Proxy (o Proxyman, mitmproxy, …) configurado como un intermediario HTTPS:

1. Instala el certificado raíz de Charles en tu iPhone y habilita la confianza total.

2. Cierra forzosamente y vuelve a abrir la aplicación Foodvisor, luego inicia sesión.

3. Busca una petición POST https://api.foodvisor.io/api/6.0/ios/FR/fr_FR/user/auth/. La respuesta JSON contiene tokens.refresh: esa es tu credencial de larga duración (≈ 6 meses).

Los tokens de actualización dan acceso total a tu historial nutricional. Trátalos como contraseñas.

Configuración de un cliente MCP

Claude (web / Escritorio / Código) — OAuth

Añade el servidor como un conector con su URL pública /mcp (p. ej., https://foodvisor-mcp.example.com/mcp). Claude hará lo siguiente:

1. Descubrirá los metadatos de OAuth en /.well-known/oauth-protected-resource y /.well-known/oauth-authorization-server.

2. Se registrará a través de POST /register.

3. Abrirá la página /authorize en tu navegador. Pega tu token de actualización de Foodvisor en el formulario y envíalo.

4. Intercambiará el código devuelto por un token de acceso de larga duración (30 días por defecto).

Después de eso, puedes usar las herramientas directamente desde Claude. Cuando el token de acceso caduque, Claude volverá a ejecutar el flujo.

Bearer directo (cualquier cliente MCP que admita HTTP transmitible)

{
  "mcpServers": {
    "foodvisor": {
      "url": "https://foodvisor-mcp.example.com/mcp",
      "headers": {
        "Authorization": "Bearer <YOUR_FOODVISOR_REFRESH_TOKEN>"
      }
    }
  }
}

Desarrollo local

Requiere Node ≥ 22.

npm install
npm run dev      # tsx watch on $PORT (default 3000)
npm run typecheck
npm run build && npm start

Estructura del proyecto

src/
├── index.ts                  # Node http server + per-request MCP transport + OAuth routes
├── env.ts                    # zod-validated env vars
├── auth/
│   ├── extract.ts            # Bearer parsing — accepts OAuth JWT and legacy Foodvisor refresh
│   └── token-cache.ts        # Foodvisor access-token cache + refresh
├── oauth/
│   ├── jwt.ts                # HS256 sign/verify + AES-256-GCM encrypt/decrypt
│   ├── store.ts              # in-memory clients + auth codes (TTL)
│   ├── login.ts              # HTML login page (paste refresh token)
│   ├── handlers.ts           # /register, /authorize, /token handlers
│   └── metadata.ts           # /.well-known/* metadata builders
├── foodvisor/
│   ├── client.ts             # fetch wrapper with 401 retry
│   ├── endpoints.ts          # typed endpoint helpers
│   └── types.ts              # response shapes
└── mcp/
    ├── server.ts             # createMcpServer(ctx)
    └── tools/                # one file per tool group
        ├── food.ts
        ├── meal.ts
        ├── progress.ts
        ├── trackers.ts
        └── profile.ts

El servidor HTTP es intencionalmente mínimo (sin Express/Hono): cada POST /mcp inicia un nuevo McpServer vinculado al userId/refreshToken del llamante y a un StreamableHTTPServerTransport sin estado.

Variables de entorno

Genera un secreto estable con:

openssl rand -base64 48

Notas de seguridad

• El servidor es un proxy de confianza para Foodvisor: cualquiera que posea un token de actualización de Foodvisor válido puede usarlo para leer y escribir los datos nutricionales de ese usuario. Protege el endpoint /mcp con HTTPS en producción y considera listas blancas de IP si se expone públicamente.

• Los tokens se mantienen solo en la memoria del proceso. Nunca se guardan en el disco.

• La caché de tokens se indexa por el user_id del JWT, por lo que las peticiones concurrentes del mismo usuario comparten un único token de acceso; los intentos de actualización concurrentes se fusionan mediante un mapa de peticiones en curso.

Hoja de ruta

• Reconocimiento de comidas basado en fotos (la función estrella de Foodvisor) una vez que se realice la ingeniería inversa del endpoint de carga.

• Registro de actividades, pesajes, recetas personalizadas y favoritos.

• Almacén de tokens persistente opcional para mayor resiliencia ante reinicios.

Contribución

Las incidencias y PR son bienvenidas en https://github.com/cldt-fr/foodvisor-mcp. Por favor, no abras incidencias pidiendo ayuda para realizar ingeniería inversa de los endpoints de Foodvisor; captúralos tú mismo con Charles/Proxyman y contribuye con un envoltorio tipado.

Licencia

MIT — ver LICENSE.