IZeat

Reads the connected account and tells you the next onboarding step. It never records or changes anything. Use it after get_connected_account when onboarding is not complete, or when the customer asks to resume setup. Follow the welcome and exact progression in the returned statement, one step per message. Ask only for the fields named in next_step, in the customer's language; do not calculate nutrition targets. After the customer answers, store their answer and the appropriate onboarding_status with update_profile, then call get_setup_step again. If the customer wants to continue later, store onboarding_status 'skipped' with update_profile. When setup is complete, briefly present the full range in starter_requests. Distinguish a nutrition-label photo plus the amount eaten from a plate photo for which you guide the customer through portions and preparation before estimating. Include corrections, day and period reviews, and finding IZeat catalogue recipes that fit the remaining targets, with guidance through their preparation. Do not reduce this to one example and never mention tool names. Example: get_setup_step {} with a missing target → ask for the daily calorie and macro targets the customer already uses. statement is the customer-facing IZeat message. It begins with "IZeat ·" so customers can distinguish information returned by IZeat from the assistant's own response. For write operations, it also states whether the requested change was recorded in their IZeat account. Account: Sam ([email protected])

get_setup_step

Returns the daily summary: everything recorded for one date — each meal with its items (quantity, calories, macros, source per item), the day's totals, the target in force that day, and the signed difference (target − total) per nutrient. Use it for any single day — today's summary, yesterday's, one date: when the customer asks for their daily summary, their day, their balance for the day, what they ate, where they stand, or how much is left. Omit date for today; otherwise pass their word (yesterday, 3 days ago, Tuesday) or YYYY-MM-DD only when they said the full date — never compute one yourself. Reads one day only. For several days or a period ('last four weeks', 'this month', 'day by day'), use period_summary. Totals are computed from recorded meals. Each meal says whether its values came from a label, the customer, or an estimate; only llm_estimate is estimated. Relay over and under neutrally. When interactive reports are enabled for the account, the result is accompanied by a complete IZeat day component containing totals, macros, every meal and its items. Text-only clients receive the same typed nutrition data. A narrow question does not require the complete report unless the customer requests it. Returns a typed public day report without storage identifiers. Example: day_summary { "date": "2026-09-03" }. statement is the customer-facing IZeat message. It begins with "IZeat ·" so customers can distinguish information returned by IZeat from the assistant's own response. For write operations, it also states whether the requested change was recorded in their IZeat account. Account: Sam ([email protected])

day_summary

Deletes one specific recorded meal, identified by the customer's local date and meal type, even when it was not the latest change. Always use two steps. First call without confirm to review the exact meal, changing nothing. After the customer explicitly confirms, call again with confirm true within ten minutes. Nothing else is needed: IZeat remembers what it showed. There is no age limit. The meal remains in IZeat's private history but no longer counts in the active day. Use undo_last_change instead when the customer simply asks to undo the latest action. Example: "Delete yesterday's dinner" → review that dated dinner, ask for confirmation, then delete it. statement is the customer-facing IZeat message. It begins with "IZeat ·" so customers can distinguish information returned by IZeat from the assistant's own response. For write operations, it also states whether the requested change was recorded in their IZeat account. Account: Sam ([email protected])

delete_meal

Returns up to three recipes per time band from the IZeat catalogue that fit what is left of the customer's day, each served at the customer's usual plate for that meal. Use it only when the customer asks what they could eat or cook, or wants a recipe idea for a meal. Never call it to tell them what they should eat. Each new request for ideas is a new call, even later in the same conversation: what is left changes as the day goes on, and the card is where the customer chooses. meal_type is required: breakfast, morning_snack, lunch, afternoon_snack, dinner or evening; ask if it is unclear. The plate is the customer's usual weight for that meal, which IZeat reads from their last weighed meals of the same type. With too few, pass sex if the customer already said it in this conversation (never ask only for this, never guess it) and IZeat uses a provisional default for breakfast, lunch and dinner; otherwise it asks you for plate_g: ask the customer roughly how much they usually eat at that meal and convert it to grams. A plate that would hold more than what is left is made smaller and says so. kcal_for_meal only when the customer gave their own figure for this meal ('I have 600 kcal for dinner'); otherwise what is left of the day is the limit. query only with the customer's own words: an ingredient, 'vegetarian'. ready_within only when the customer said how long they have until they eat ('I have 20 minutes'). Omit date for today, as on day_summary. The recipes come by total time, until the plate is served: up to three ready in 20 minutes, three in 40, three that take longer; each also says its active time, the minutes with hands in the recipe. For lunch and dinner, up to three desserts come too, at one serving each, and each dish says its smaller plate beside each dessert, so dish and dessert together make the usual plate. The choice weighs what is left in protein, carbohydrate and fat: far from the protein target, the protein-rich dishes come first; close to it, lighter ones. Equal fits are ordered by the IZeat score (0 to 100, how well a dish keeps hunger away for two to three hours, per calorie). Each recipe comes with its plate in grams and its figures, its times, the ingredients scaled to that plate, its creator and its page. These are options, never a prescription: relay them neutrally and never comment on how much. Records a view for every proposed recipe, at most once per account, recipe and UTC day; a proposal is not a recipe use and does not earn creator royalties. When interactive cards are enabled for the account, the recipes also appear as an IZeat card with their photos, figures and ingredients; text-only clients receive the same data. When the customer chooses one to cook, call get_recipe with its reference and plate for the whole method. If the customer cooks one, log what they actually cooked and ate with log_meal, with their own quantities and changes, and pass its reference in log_meal recipes. Saying they will cook a recipe is not a meal: log nothing until they say what they ate. Example: find_recipes { "meal_type": "dinner" }. statement is the customer-facing IZeat message. It begins with "IZeat ·" so customers can distinguish information returned by IZeat from the assistant's own response. For write operations, it also states whether the requested change was recorded in their IZeat account. Account: Sam ([email protected])

find_recipes

Returns the customer's name and the target in force on a date (the latest target set on or before it). Use it when the customer asks directly about their profile or target. day_summary already includes the target for a day, so do not call both for a day comparison. Pass date (The customer's day as they said it — today, yesterday, 3 days ago, a weekday — or YYYY-MM-DD) to get that day's target; omit it for the latest one. Returns { first_name, last_name, target: { valid_from, kcal, protein_g, carb_g, fat_g } | null, target_history_count }. Example: get_profile { "date": "2026-09-03" } → target 2000 kcal since 2026-09-01 → tell them in one line. statement is the customer-facing IZeat message. It begins with "IZeat ·" so customers can distinguish information returned by IZeat from the assistant's own response. For write operations, it also states whether the requested change was recorded in their IZeat account. Account: Sam ([email protected])

get_profile

Records one meal — the whole meal in one call — as the list of what was eaten, one item per food with its quantity, calories, macros and source. Use it when the customer says what they ate. Ask before calling if the day or the meal type is unclear: never assume either. When quantities or a homemade or restaurant dish are too vague for a useful estimate, ask one concise bundled follow-up for the missing portions and any known label, recipe, batch or calorie values before recording. For a plate photo, guide the customer to one easy portion cue suited to the food: weight; otherwise spoonfuls or ladles, a fraction of the plate or batch, or a known container size. Offer only one likely alternative at a time. If no cue is available, ask for top and side photos with a ruler, a utensil of roughly known length, or their hand beside the food. Never infer a container's capacity or exact weight from appearance alone. If the customer accepts an estimate, give a range and record its stated midpoint as llm_estimate. Never silently use normal portions. Omit date for today's meal — the usual case. Name a day only when the customer did: pass their word (yesterday, 3 days ago, Tuesday) and IZeat resolves it in their time zone; pass YYYY-MM-DD only when they said the full date. Never compute a date yourself. meal_type is one of breakfast, morning_snack, lunch, afternoon_snack, dinner, evening — pick the nearest and say so if none fits. One meal of each type per day: when that day's dinner is already recorded, a second one is refused — use update_meal for additions or corrections, and another meal type for something eaten at another time. items: one entry per food, in the order the customer said them. Quantities are grams or millilitres, nothing else: convert what they said — cups, ounces, spoons, 'a banana' — with your own knowledge of that food, keep their words in as_said, and say in your reply that you converted. Figures may carry decimals; IZeat rounds once. Each item has its own source: 'label' when read from packaging or a nutrition label (photo or text); 'user' when the customer gave the numbers themselves; 'reference' for a plain, unmixed food — a vegetable, a fruit, rice, a chicken breast — whose weight the customer gave and whose values you quote from a standard composition table; 'llm_estimate' when you deduced anything: a mixed or homemade dish, or a portion you had to guess. A weighed steak next to an estimated sauce keeps its source; only the sauce is an estimate. Ask only what would change a figure by more than a third, in one short bundled question, and only when the customer's words leave it open: the fat something was cooked or dressed in; raw or cooked weight for what absorbs water — pasta, rice, grains, pulses, oats — where cooked weighs two to three times more; which variant when a family spans a factor of two (whole or skimmed milk, plain or sweetened yoghurt, which cheese, tuna in oil or in water). Everything else, take the likely reading and say it in your reply so the customer can correct it in a word: meat and fish weighed cooked, fruit without peel or stone, a medium egg, a 30 g handful of nuts, a 33 cl beer, a 12 cl glass of wine, 15 g of jam. Never ask how a vegetable was cooked when no fat was involved. setting only when the customer said where they ate (home, restaurant, friends, takeaway); never ask for it. idempotency_key: a random string you generate per meal, reused only if you retry this same call; the same key never creates a second meal. recipes: only when the customer cooked a dish from an IZeat catalogue recipe (find_recipes gives its reference). Record what they actually cooked and ate, with their own quantities and changes; recipes only says which rows are that dish: { "recipe": "aubergine-lasagne", "items": [1] } when the dish is one row, [1, 2, 3] when you listed its ingredients. Never add it for a dish that did not come from the catalogue. This link preserves journal facts; it does not count another recipe use for creator royalties. Returns only the customer-facing meal facts — every item with both measures — and the day so far against that day's target; internal IDs and timestamps are never returned. The returned meal facts include the complete recorded foods and quantities, totals, provenance or assumptions, and day balance. Never comment on how much it is. Example: log_meal { "meal_type": "lunch", "items": [ { "description": "grilled chicken breast", "amount": 180, "unit": "g", "kcal": 297, "protein_g": 56, "carb_g": 0, "fat_g": 6.5, "source": "reference" }, { "description": "steamed sweet potato", "amount": 80, "unit": "g", "kcal": 68, "protein_g": 1.3, "carb_g": 16, "fat_g": 0.1, "source": "reference" }, { "description": "homemade sauce", "amount": 40, "unit": "g", "kcal": 90, "protein_g": 1, "carb_g": 4, "fat_g": 8, "source": "llm_estimate" } ], "idempotency_key": "a3f9c1" }. statement is the customer-facing IZeat message. It begins with "IZeat ·" so customers can distinguish information returned by IZeat from the assistant's own response. For write operations, it also states whether the requested change was recorded in their IZeat account. Account: Sam ([email protected])

log_meal

Returns what was recorded between two dates, inclusive: coverage, totals, the average per recorded day, the target timeline, and public day, week, month or meal rows. Use it when the customer asks about more than one day: a week, a month, 'the last four weeks', 'day by day', 'what did I eat last week'. from and to are their local dates (YYYY-MM-DD). Never for a single day: if from would equal to — today, yesterday, one date — call day_summary instead. It returns each meal and its items, which this tool does not, and this tool refuses the call. granularity: 'total' for an overall answer; 'days' (default) for daily values through 31 days; 'meals' for every meal through 31 days. Longer visual ranges use weekly averages through one year and monthly averages after that. Every aggregate is per recorded day. Missing days have null values, never zero. At most the latest two years are returned in one answer; requested_range and effective_range make that limit explicit. history_available_from is the first available IZeat history, not necessarily the account creation date. When interactive reports are enabled for the account, the result is accompanied by a complete IZeat period component containing coverage, averages and the appropriate time series. Text-only clients receive the same typed nutrition data. Do not rank days unless the customer asks. Returns a typed public period report without storage identifiers. Example: period_summary { "from": "2026-08-08", "to": "2026-09-04" }. statement is the customer-facing IZeat message. It begins with "IZeat ·" so customers can distinguish information returned by IZeat from the assistant's own response. For write operations, it also states whether the requested change was recorded in their IZeat account. Account: Sam ([email protected])

period_summary

Returns one IZeat catalogue recipe in full, to cook it with the customer: the ingredients scaled to their plate, the seasonings and the whole method. The ingredients are scaled to the customer's plate, but steps are the original method for the whole recipe: quantities written inside them are not scaled. Make this distinction clear; use the scaled ingredient list for plate quantities and do not present whole-recipe quantities as plate quantities. Use it when the customer chooses a recipe from find_recipes to cook, or asks for the method of an IZeat recipe. recipe is the reference find_recipes gave; plate_g the plate it showed, unless the customer wants another size. Call it for each new explicit request for a complete recipe, even if that recipe appeared earlier in the conversation. Show it with your own recipe view when your app has one (the ingredients, then the steps, with its step-by-step cooking mode), one serving being this plate and every quantity the one IZeat gives; otherwise list the ingredients and guide them through the method one step at a time, waiting for them before the next step. Answer their questions about the dish. Log nothing while they cook. A successful request for the complete method records one recipe use, at most once per account, recipe and UTC day. Eligible uses determine creator royalties; a later meal log does not count another use. Requesting the method does not prove that the customer cooked or ate it. When they have eaten, ask what they actually ate and how much, then log it with log_meal, with their own quantities and changes, and pass this recipe's reference in log_meal recipes. Example: get_recipe { "recipe": "mac-beef", "plate_g": 550 }. statement is the customer-facing IZeat message. It begins with "IZeat ·" so customers can distinguish information returned by IZeat from the assistant's own response. For write operations, it also states whether the requested change was recorded in their IZeat account. Account: Sam ([email protected])

get_recipe

Returns one recorded meal exactly as it is stored: its rows in order (position, description, quantity, calories, macros, source), the meal's totals, and whether it was already corrected. Use it before update_meal action 'revise', to copy the untouched rows exactly, and whenever the customer asks what one meal contains. It draws nothing: for the whole day with its card, use day_summary instead. Identify the meal by its meal type and day — omit date for today, otherwise pass the customer's word (yesterday, 3 days ago, Tuesday) or YYYY-MM-DD only when they said the full date; never compute one yourself. When no meal of that type is recorded that day, the reply says so and names the meal types that day does have, so ask the customer which one they mean rather than reading the day again. Returns typed public meal facts without storage identifiers. Example: get_meal { "meal_type": "lunch" } for today's lunch; get_meal { "date": "yesterday", "meal_type": "dinner" }. statement is the customer-facing IZeat message. It begins with "IZeat ·" so customers can distinguish information returned by IZeat from the assistant's own response. For write operations, it also states whether the requested change was recorded in their IZeat account. Account: Sam ([email protected])

get_meal

Restores the latest meal change undone with undo_last_change when the customer says the undo was a mistake. Always use two steps: first call without confirm to review what would return, changing nothing; after the customer confirms, call again with confirm true within ten minutes. Nothing else is needed: IZeat remembers what it showed. Only something undone in the last 48 hours can be restored. Returns the restored customer-facing meal and the recomputed day. Example: "That undo was a mistake" → review the latest undone change, ask for confirmation, then restore it. statement is the customer-facing IZeat message. It begins with "IZeat ·" so customers can distinguish information returned by IZeat from the assistant's own response. For write operations, it also states whether the requested change was recorded in their IZeat account. Account: Sam ([email protected])

restore_last_change