Kalori

Search the user's own foods (analyzed from photos/text in the app or registered manually) to re-log them by foodId. For "log my usual homemade smoothie": find it here and pass foodId to log_meals to re-log with nutrition and components. Without q, lists them newest first. Subject to the linked account's entitlement.

search_my_foods

Propose clearing a date's custom budgets (one slot or the day's goal override); applies only after the user confirms. With mealSlot, that slot's custom budget is deleted; without it, all of that day's goal overrides are cleared (back to the base goal). Nothing changes until the user presses the button in the confirmation card or opens the returned link. Subject to the linked account's entitlement.

clear_budget

Get the user's weight records for a date or date range (max 90 days), to review weight-loss pace or inform meal advice. Pass date (single day) or startDate+endDate. On supporting hosts a line-chart card renders, and the user can log today's weight from the card's input field. Passing targetWeightKg (from get_profile_and_goals) draws a goal line on the chart. Subject to the linked account's entitlement.

get_weights

Log the user's body weight for a date (one entry per day; logging the same day again overwrites it). Everyday reports like "65.2 kg this morning" can be logged as is. The result card lets the user undo it (restores the previous value). Subject to the linked account's entitlement.

log_weight

Re-fetch exact nutrition for one catalog item by its search_foods id (p_{productId} or g_{dishId}). When numbers need rechecking in a long conversation, use this instead of memory or guesses. nutritionSource official = the chain's published values; partial / estimated include AI estimates, so say they are estimates. Null nutrition means kalori has no data for the item: answer "no data" instead of guessing.

get_food_details

List the shop chains in Kalori (id, name, aliases) to get shop ids for search_foods / suggest_meal_set filters.

list_shops

Execute a proposed change after the user pressed its confirmation card's button; called by the card, not the model. The token exists only in the proposal result's _meta, which the model never sees; never guess one. Runs at most once per proposal (a repeat returns the first result) and only within 1 hour of the proposal.

confirm_change

Get daily nutrition totals vs goals (intake kcal, PFC, exercise burn) for a date or range, with per-slot budgets. Pass date (single day) or startDate+endDate (max 90 days). A single day also returns slots (budget allocation per meal slot such as breakfast/lunch/dinner; source=auto = not logged yet): for "find something for dinner", pass that slot's cal/protein/fat/carbs to search_foods target* as is. detailed=true switches to totals of 27 nutrients (fiber, salt, iron, vitamins, etc.) with recommended intakes, for "am I getting enough X?". On supporting hosts a dashboard card renders, and the user can ask for "a meal that fits this slot" from an unlogged slot's chip. Subject to the linked account's entitlement.

get_nutrition_summary

Render an agreed combination of catalog items as a meal-plan card with server-computed kcal/PFC totals. Totals come from exact catalog values; use this instead of showing numbers you added up yourself. Once the combination is settled with the user, present it with this tool. Items are productId (type=product) or dishId (type=dish) from search_foods / get_favorites results. targetCal etc. add fulfilment bars against the target (pass the matching slot from get_nutrition_summary slots to show how the meal fits that slot). This tool does NOT log: on supporting hosts the user can log from the card's "この献立を記録する" button (logging is reflected in the conversation context); otherwise log with log_meals.

show_meal_plan

Propose setting, changing, or creating the user's goal; it applies only after the user confirms in the card or link. Covers lose/maintain/gain, target weight, pace, activity level, and meal-slot ratios. The input is checked now (missing fields fail here, see below), and the response is a proposal with a preview of the new targets; nothing is saved until the user presses the button in the confirmation card or opens the returned link. Only the fields you pass change and the rest keep the current goal, so requests like "make my target weight 60 kg", "slower", or "lighter breakfast, bigger dinner" can be passed directly. The quantity this goal manages is `pace` (% of body weight to move per week). Target weight only sets how far to go: changing it does not change the daily calorie target, only the estimated days to reach it. For "too fast / too hard" or "I want to lose faster", change pace. Calorie and PFC target numbers themselves CANNOT be set: the server derives them from the user's observed metabolism (metabolism in get_profile_and_goals). This lets the goal track reality as logs accumulate; fixing numbers directly would stop that tracking, so it is blocked on purpose. For a one-day number like "I want 1800 kcal today", use set_day_budget. Explain the proposed change with its basis using previous and derivation in the preview (baseTdeeKcal = the expenditure used as the base; baseTdeeSource: observed = back-calculated from the user's logs, mifflin = formula estimate from height/weight/age; dailyDeficitKcal = daily deficit), like "1,900 → 1,750 kcal: a 400 kcal/day deficit from an observed metabolism of 2,150 kcal". manualPreserved=true means the goal is manually fixed in the app: the intent (target weight, ratios, etc.) would be saved but the numbers stay fixed; tell the user (only the app's 「自動計算に戻す」 unfixes it; switchedFromManual is legacy and always false). Users with no goal yet (goal=null in get_profile_and_goals) can create one here (preview created=true, previous=null). Creating requires goalType and activityLevel, plus height, weight, date of birth, and sex for the calculation (heightCm / weightKg / dateOfBirth / gender). If any are missing, a 400 lists the field names in missing: ask the user for all of them at once, tell them they are used only to calculate the calorie target, then call again with them in the same call (never fill them in by guessing). Do not ask again for items already saved. The formula is binary, so let the user choose whether to calculate as male or female. heightCm etc. can also be passed when the user wants to correct them (on confirmation, overwrites the profile and recalculates the goal). Daily weight logging is log_weight. Subject to the linked account's entitlement.

set_goal

Undo a direct write (meals, meal edit, exercise, weight, or day note) after the user pressed the card's undo button. Called by the card only; the token exists only in the write result's _meta, which the model never sees. Deletes what the write added, or restores the previous meal, weight, or note (refused if it changed since). Valid for 24 hours, once.

undo_change

Log an exercise session with its burned kcal (past dates allowed via exerciseDate). A report like "ran 30 minutes, about 300 kcal" can be logged as is. Subject to the linked account's entitlement.

log_exercise

Propose deleting one exercise record; nothing is deleted until the user confirms in the card or at the returned link. HealthKit-sourced rows cannot be deleted. Ids come from log_exercise / get_exercises results. Subject to the linked account's entitlement.

delete_exercise

Get the user's exercise records and total burned kcal for a date (also to find ids for delete_exercise). Subject to the linked account's entitlement.

get_exercises

Save the user's personal taste rating (1–9) for a logged meal; rating again overwrites it. Scale: 1 = meh … 9 = best. Omitting note keeps the previous note. Lets "that ramen earlier was a 7" be saved as is, and feeds "ベスト食事" in the app's "気づき" tab. Subject to the linked account's entitlement.

rate_meal

Analyze a meal photo or free text with Kalori's nutrition engine, saving it as an own food and logging it in one step. Besides kcal/PFC it estimates and saves 27 detailed nutrients (iron, fiber, vitamins, etc.) that feed get_nutrition_summary detailed; manual values in log_meals get no detailed nutrients, which is how to choose between them. For a photo: observe it yourself and write a detailed Japanese description in query: items and counts, portion estimates (like ご飯茶碗1杯, 唐揚げ5個), cooking method, and any numbers on a visible nutrition label. If it is identifiable as a chain product, search_foods → productId logging comes first (official values). catalogMatches in the response are catalog candidates (official values); switching to one is log_meals + delete_meal. To correct a meal just logged ("that was actually X"), pass its id as `replaceMealId` instead of delete_meal and re-logging. Deleting and re-creating changes the id, which loses the taste rating, actual photo, and log date (used for streaks), and holding the old id leads to failed double deletes. replaceMealId keeps the log date and meal slot; do not pass mealDate / mealType with it (moving date or slot is update_meal). With replaceMealId the redo is only proposed, because it overwrites the record: nothing changes and no analysis runs until the user confirms in the card or at the returned link. Without it, the meal is logged directly and the result card lets the user undo it. Response cal/protein/fat/carbs are the logged values and equal the sum of components (each an absolute value for its amount, with the amount in the name, like 唐揚げ 5個 or コーラ 1缶（約350g）). The engine's amount misreadings show in those names; state the amount explicitly and re-analyze with replaceMealId. Subject to the linked account's entitlement.

analyze_and_log_meal

Log meals to Kalori, up to 10 per call (batch preferred): catalog item, generic dish, own food, or manual values. When logging from a photo, log anything identifiable as a chain product via search_foods → productId first (official nutrition); use analyze_and_log_meal for dishes you cannot identify. Use manual values (mealName+cal) here when the user states the numbers. Four methods: (1) catalog product = productId from a search_foods type=product result (official nutrition; shop attached automatically); (2) generic dish = dishId from a search_foods type=dish result (standard nutrition + components added; for home cooking and non-chain eating out); (3) own food = foodId from search_my_foods (re-logs the user's own food); (4) manual = mealName + cal. Give exactly one method per item; never mix a reference id with manual PFC or components. Manual components must each have kcal/P/F/C. All manual numbers are absolute amounts for what was actually eaten, with no multiplier: for "サラダチキン40g", put the amount in the name and pass kcal/P/F/C for 40 g (components have no quantity or unit). mealDate accepts past dates (moving records) and future dates (meal planning): for "plan tomorrow's dinner and add it", batch-log with a future mealDate and it appears in the app's plan grid. A meal totaling over 10,000 kcal is rejected. The result card lets the user undo the log. Subject to the linked account's entitlement.

log_meals

Propose a custom kcal/PFC budget for one meal slot on a date; it applies only after the user confirms. Nothing changes until the user presses the button in the confirmation card or opens the returned link (setting a slot again overwrites it). For requests like "leave 800 kcal for dinner tomorrow, I have a dinner party" or "keep lunch to 500 kcal". It shows in the app's plan grid and immediately affects get_nutrition_summary slots (source=custom) and search targets. Subject to the linked account's entitlement.

set_slot_budget

Suggest product sets (like staple + side) at one specific shop that fit a kcal/PFC target, to answer what to buy there. shopId is REQUIRED; if unknown, call list_shops first. On supporting hosts, the candidate sets render as cards and the user can log a whole set with "このセットを記録". Subject to the linked account's entitlement.

suggest_meal_set

Edit a logged meal (amount, slot, date, components, or shop). It applies immediately, and the result card lets the user undo it for 24 hours. The amount is one quantity multiplier ("left half" → 0.5, "it was 2 servings" → 2, "ate 1.5×" → 1.5); attach a shop afterwards ("that was from Seven-Eleven" → shopId). Nutrition is recalculated server-side. Component values are each component's absolute amount for its portion, with the amount in the name (same as manual log_meals; no multiplier). Components from get_meals detail / analyze_and_log_meal have the same shape: change only the rows to fix and send all rows. Meal kcal = sum of components × quantity. Updates that push a meal's total above 10,000 kcal are rejected. Subject to the linked account's entitlement.

update_meal

Propose deleting one logged meal; nothing is deleted until the user confirms in the card or at the returned link. Id from get_meals / log_meals results. The meal is checked now (a wrong id fails here), then the user decides. Subject to the linked account's entitlement.

delete_meal

Get the user's logged meals for a date or date range (max 14 days), or search all history by meal name with q. Pass date (single day) or startDate+endDate. detail=true adds components, shop, portion adjustments, and whether a photo exists (use before reviewing or editing). q searches the whole history by meal name instead of by date, with no range limit (for "when did I have that pork miso soup last week?" or "log my usual breakfast again"). On supporting hosts, meals render as a card where the user can add a taste rating (1–9) by tapping a row. Subject to the linked account's entitlement.

get_meals