My doctor asked me to keep a food diary. Simple enough, right? I downloaded MyFitnessPal. Then Lifesum. Then a couple more. They all did the job of logging meals, but when I needed to actually use the data — export a summary for a specific period to show my doctor — things fell apart. MyFitnessPal has some export features on desktop, but it's clunky. Lifesum doesn't really let you export at all. None of them felt comfortable with what should be a straightforward task: log what I eat, then share a summary with my doctor. use My next thought was to build something on top of these apps. Maybe connect to their APIs and pull my data out. But they all have closed APIs — so that wasn't an option either. The Idea I was talking to Claude about this problem, and something clicked. Current LLMs are capable enough to analyze nutrition from a photo of food, look up a barcode, or estimate macros from a brief description and portion size. I don't need a dedicated nutrition database with millions of entries and a complex UI. I just need a place to store the data and a smart interface to put it there. That interface already exists. It's the conversation. What I Built I built a remote MCP (Model Context Protocol) server that connects to any MCP-compatible AI assistant: Claude, ChatGPT, Mistral, or any other client that supports MCP. It's a simple backend: a database for meals, authentication so each user's data is private, and a set of tools the AI can call: log a meal, get today's meals, get a nutrition summary for a date range, update or delete entries. The workflow is dead simple: I take a photo of my food, send it to Claude, and say, "log this." Claude analyzes the photo, estimates the calories and macros, and stores everything in the database. If I eat a packaged product, I can snap the barcode or the nutrition label — same result. No manual entry, no scrolling through food databases, no guessing serving sizes from dropdown menus. And when I need to show my doctor? I can ask Claude to generate a summary for any date range as a table, as an Excel file, or just as a conversation. I could literally hand my phone to my doctor and let them ask whatever they want about my nutrition. One Evening of Vibe Coding The whole thing took me one evening and one morning to build. I used Claude Code to vibe code the entire server: the MCP tools, OAuth authentication, Supabase database integration, everything. The tech stack is Bun, Hono, and Supabase, deployed as a Docker container. I didn't write the code line by line. I described what I wanted, iterated with Claude Code, and had a fully functional, deployed MCP server with user registration and persistent data storage in about 12 hours of actual work. Using it Daily I've been using it every day since. The experience on my phone is exactly what I wanted: open Claude, describe or photograph my meal, done. No app to switch to, no UI to navigate. Just a message in a conversation I'm probably already having. The best part is how it complements other tools. I also built a Withings MCP server that provides data about my physical activity: steps, weight, and sleep. Because both are MCP servers connected to the same assistant, I can ask things like, "How did my calorie intake compare to my activity level this week?" and get an answer that pulls from both sources. No integration work needed — the AI just uses both tools. Withings MCP server Why MCP Matters Here MCP turns AI assistants into a universal interface. I built a thin backend and let the AI handle the UI, the export, and the integration layer. No dedicated nutrition app, no custom export features, no glue code to connect systems that don't talk to each other. This pattern works for anything where you need to store personal data and interact with it flexibly. Nutrition tracking just happened to be my use case, but the idea applies broadly: give the AI tools to read and write your data, and the interface takes care of itself. Under the Hood The architecture is intentionally simple: four layers, no frontend framework, no mobile app. HTTP Layer A Hono server running on Bun. It handles routing, CORS, security headers, and body size limits. The MCP endpoint lives at POST/mcp, protected by Bearer token middleware. Hono Bun POST/mcp OAuth 2.0 The server implements the full authorization code flow with PKCE — the same flow Claude.ai and other MCP clients expect. When you connect for the first time, it opens a login page in the browser, you enter an email and password, and the server exchanges that for a long-lived access token. Sessions are in-memory with a 10-minute TTL; tokens persist for 365 days in the database. MCP Server Each client session gets its own MCP server instance using the StreamableHTTP transport. Tools are registered per user — every query is scoped to the authenticated user's ID, so there's no way to access someone else's data. The server exposes seven tools: StreamableHTTP log_meal — log a meal with description, calories, macros, and notes get_meals_today — get all meals logged today get_meals_by_date — get meals for a specific date get_nutrition_summary — daily nutrition totals for a date range update_meal — update any fields of an existing meal delete_meal — delete a meal by ID delete_account — permanently delete your account and all data log_meal — log a meal with description, calories, macros, and notes log_meal get_meals_today — get all meals logged today get_meals_today get_meals_by_date — get meals for a specific date get_meals_by_date get_nutrition_summary — daily nutrition totals for a date range get_nutrition_summary update_meal — update any fields of an existing meal update_meal delete_meal — delete a meal by ID delete_meal delete_account — permanently delete your account and all data delete_account Database Supabase handles both authentication (email/password sign-up and sign-in) and data storage (PostgreSQL). Four tables: meals for nutrition entries, oauth_tokens and refresh_tokens for session management, and auth_codes for the OAuth flow. Row Level Security is enabled on all tables. Supabase meals oauth_tokens refresh_tokens auth_codes The whole request flow: your MCP client sends a tool call, the Bearer token is validated, the user ID is resolved, the tool handler queries Supabase scoped to that user, and the response goes back through the MCP protocol. No frontend, no state management, no React — just a database and a conversation. Try It The server is hosted and ready to use at nutrition-mcp.com. Setup takes under a minute: nutrition-mcp.com Claude Desktop App or Claude.ai: Go to Customize → Connectors → + Choose Add custom connector Set the Remote MCP Server URL to https://nutrition-mcp.com/mcp Click Connect Go to Customize → Connectors → + Customize → Connectors → + Choose Add custom connector Add custom connector Set the Remote MCP Server URL to https://nutrition-mcp.com/mcp https://nutrition-mcp.com/mcp Click Connect Connect Once connected on the desktop, it automatically syncs to Claude on iOS and Android. Other MCP Clients: Add this to your client's MCP config (the client must support OAuth 2.0 with PKCE): { "mcpServers": { "nutrition": { "url": "https://nutrition-mcp.com/mcp" } } } { "mcpServers": { "nutrition": { "url": "https://nutrition-mcp.com/mcp" } } } On first connect, a browser window opens where you enter an email and password to create an account. That's it — your meals are linked to this account, and you sign in with the same credentials if you reconnect later. The source code is open: github.com/akutishevsky/nutrition-mcp github.com/akutishevsky/nutrition-mcp
