Three tools write and the rest read, which shapes what this is good for: meals and water go in, and goals, weight, exercise, preferences and settings come back as material to reason over but not to change. The water model is the one thing to get right before wiring anything up — an entry is the cumulative total in millilitres for that timestamp, not an increment, so the current value has to be read and added to or the day's count is overwritten. Sign-in is a username and password rather than a token, so the credentials sitting in the client config are the account credentials themselves.
A server over the Yazio food-tracking API — profile, goals, diary entries, water, weight, exercise and the product database.
- Food logged and removed: an entry takes a product ID with an amount, a serving and a serving quantity, and a daytime; removing one takes the entry's own ID
- The product database searched by query and optionally scoped by country, locale and sex, with one product's detail fetched by ID
- A day read back whole — the nutrition summary for a date, and the entries that produced it
- Water tracked cumulatively: an entry carries the running total in millilitres for a timestamp, so the current value is read first and added to
- Context to judge any of it against: nutrition and fitness goals, dietary preferences and restrictions, settings, weight history, and exercise for a date or range
- Product suggestions for the account, filtered by query and limit
YAZIO_USERNAME and YAZIO_PASSWORD for an existing Yazio account. MIT.
One command plus a key — npx yazio-mcp, then supply credentials