Log or plan meal
create_mealSave a meal the person asked to log or plan. Find each food with list_foods first and pass a match as food (its library and key); use newFood only when nothing matches, never for a product the catalogue has. If the food or portion is unclear, ask one short question first (for example: chicken or bean burrito, and one or two?), without asking again for what the person already said. Use state logged for food eaten, and planned only for a plan the person asked to save, since suggestions alone are not a request. To log a meal that was planned, use update_meal instead of creating another. For planning, read get_targets first and respect the diet, dislikes and allergies the person mentions. Pass photos the person attached as photos. Say the meal is saved only after this returns its id; after an error or timeout, check list_meals for that day before trying again.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | A name for the meal as a whole, such as Sunday brunch | |
| items | Yes | The foods in the meal, each with its portion | |
| notes | No | Notes the person wants kept with the meal | |
| state | No | logged for food eaten; planned only for a plan the person asked to save | logged |
| images | No | Photos already saved on this record to keep, or public https image links. New photos from the conversation go in photos, never here. | |
| photos | No | Photos the person attached in this conversation to keep with this record: pass the attachments themselves, never file paths | |
| eatenAt | Yes | When it was eaten, or for a plan when it will be, with its UTC offset | |
| timezone | Yes | The IANA timezone where the meal is eaten, such as America/New_York |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| day | Yes | ||
| name | Yes | ||
| items | Yes | ||
| notes | Yes | ||
| state | Yes | ||
| images | Yes | ||
| eatenAt | Yes | ||
| category | Yes | ||
| timezone | Yes | ||
| nutrition | Yes |