Kalori

Change one registered supplement: correct its label, change its daily amount or slot, or stop taking it. Use one of three ways per call: (1) correct its name / unit / basisAmount / label nutrients (also fixes past days); (2) change the daily amount and slot from a date with amount + slot (+ from; also resumes a stopped one); (3) stop taking it with stop: true (+ lastDay, the last day taken). Ids come from get_supplements. The result card lets the user undo it. Subject to the linked account's entitlement.

update_supplement

Register a supplement the user takes daily (vitamins, protein powder, creatine) instead of logging it as a meal. Its nutrients then count toward every day from startedOn until it is stopped, without counting as a meal. Copy the label: basisAmount is how many units the label values are for ("per 2 tablets" = 2), amount is how many units the user takes a day. Check get_supplements first so you do not register the same one twice. The result card lets the user undo it. Subject to the linked account's entitlement.

add_supplement

Mark whether the user took a registered supplement on a given day (taken=false = skipped that day). A skipped day's nutrients stop counting; taken=true clears the mark. Every day in the supplement's period counts as taken by default, so call this only for exceptions like "forgot my vitamins today". Today or past days only. The result card lets the user undo it. Subject to the linked account's entitlement.

set_supplement_taken

List the user's registered supplements with label nutrients, daily amount, time slot, and start/stop dates. These are what the user takes regularly (vitamins, protein powder). Use it before adding one (to avoid duplicates) and to find ids for update_supplement / set_supplement_taken. Subject to the linked account's entitlement.

get_supplements

Get the connected account's current entitlement, API quota, and any available profile, goals, and observed metabolism. Available data can include profile, goal PFC, weight goal, meal-slot allocation ratios, and observed metabolism (metabolism). When metabolism has trusted=false it is still being estimated, so do not state it as certain; null means insufficient logs. goal.source=manual is a goal the user fixed, and it does not track automatically. Do not assert that fields withheld by the entitlement are unset; say they are currently unavailable. This tool does not change the account's entitlement.

get_profile_and_goals

Save a new meal set: a named combination the user eats often, so it can be logged in one step later. Example name: いつもの朝ごはん; the set also appears in the app. Items use productId / dishId from search_foods or foodId from search_my_foods, with quantity. Editing or deleting sets is done in the app. The result card lets the user undo it. Subject to the linked account's entitlement.

save_meal_set

Get the user's saved meal sets (named combinations like "my usual breakfast") with each item's current nutrition. To log a set, pass its items to log_meals as is (productId / dishId / foodId + quantity) and add mealSetId to every item; skip items with available=false and tell the user. Not the same as suggest_meal_set (shop combinations). Subject to the linked account's entitlement.

get_meal_sets

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. On Free, only today and the previous 6 days can be read; older dates return 403 with the readable range (freeReadWindow).

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

Log past meals again exactly as recorded (same name, amount, breakdown, and nutrition). Use it for "same as yesterday" or "my usual". Pass meal ids from get_meals, or lastMealId from get_usual_meals; repeat an id to log it twice. Prefer this over re-typing values into log_meals, which drops corrections made to the original. mealDate / mealType default to today and the current main meal. The result card lets the user undo it. Subject to the linked account's entitlement.

repeat_meals

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. servingLabel says what amount the values are for (e.g. 1個（11g）当たり); never treat a per-piece or per-100g value as the whole package. 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

Get the user's daily resting heart rate and heart rate variability (HRV) for a date or date range. These are summaries the user chose to import from Apple Health. Use it as general wellness context for recovery trends alongside meals and workouts. Pass date (single day) or startDate+endDate (max 90 days). restingHrBpm is beats per minute; hrvSdnnMs is HRV (SDNN) in milliseconds. Data exists only if the user turned on heart import in the Kalori iPhone app (Android: Health Connect), so an empty result usually means import is off or there is no data for those days. Read-only daily summaries; they do not change calorie targets. Do not use them to diagnose conditions or give medical advice. On Free, only today and the previous 6 days can be read; older dates return 403 with the readable range (freeReadWindow).

get_heart_rate_summary

Find the catalog product matching a packaged food's nutrition label, to log it with official data. Use it before typing label numbers into log_meals. Pass the company in the label's 製造者 / 販売者 field as maker and the label's kcal/protein/fat/carbs (salt optional; per=100 when the label is per 100 g). On a match, log it with log_meals productId (quantity scales the product's serving). shop null means the maker is not in the catalog; an empty list means no product matched. In both cases log it manually with the label values (detailedNutrition for salt and the rest).

match_nutrition_label

Save the key points of a review or advice you gave the user to their Kalori account, for later chats to continue from. After reviewing the user's records over a period (for example a weekly review), offer once to keep the key points; save only when the user asks or agrees. Write a few sentences of takeaways in the user's language (the numbers that matter, the pattern you found, what to try next); never paste the conversation or include anything the user did not want kept. Each call adds one note and never overwrites; the result card lets the user undo it. Notes are not shown in the Kalori app; read them back with get_review_notes. Available regardless of the current entitlement, up to 20 per 24 hours.

save_review_note

Get the review notes the user kept from earlier chats (key points of past analyses and advice), newest first. Read them before reviewing the user's progress or giving advice, to continue from the last review instead of starting over (for example, check whether what was planned last time happened). On Free, only notes saved in the recent days are returned (older notes are kept, not deleted).

get_review_notes

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. For today, when the connected account has full access, it also returns shelf: the user's likely picks for the next meal (lastMealId for repeat_meals); offer them first when the user is deciding what to eat. 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. On Free, only today and the previous 6 days can be read; older dates return 403 with the readable range (freeReadWindow).

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

Get the user's daily sleep imported from Apple Health (time asleep, in bed, stages, awake) for a date or date range. Use it to relate short sleep to appetite or meal choices. Pass date (single day) or startDate+endDate (max 90 days). Values are minutes; sleep belongs to the date the user woke up. Deep/REM/core minutes exist only for devices that track stages, such as Apple Watch. Data exists only if the user turned on importing this category from Apple Health in the Kalori iPhone app (Android: Health Connect), so an empty result usually means it is not enabled or there is no data, not that the user did not sleep or has no heart data. Record-only: these values do not change calorie targets. Not for medical judgments. On Free, only today and the previous 6 days can be read; older dates return 403 with the readable range (freeReadWindow).

get_sleep

Get the user's detailed workout sessions (exercises, sets, weights, reps) for a date or date range. Use it to review progress or suggest the next session's loads; each session also has its estimated burn. Pass date or startDate+endDate (up to 90 days). Burn-only entries without sets are in get_exercises. Subject to the linked account's entitlement. On Free, only today and the previous 6 days can be read; older dates return 403 with the readable range (freeReadWindow).

get_workouts

Log a workout session with its exercises and sets (weight, reps, duration) so the user can track strength progress. Use exerciseId from search_workout_exercises, or customName for an exercise not in the catalog. durationMin is the whole session including rest. Burned kcal is estimated server-side from the session's MET, the user's latest weight, and the duration (energyMode estimate, the default); pass energyMode manual + manualKcal when a device shows the burn, or none to log without counting it. For a burn-only entry with no sets ("ran 30 minutes, about 300 kcal"), use log_exercise instead. The result card lets the user undo it; editing a saved workout is done in the app. Subject to the linked account's entitlement.

log_workout

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

Search the exercise catalog (strength, cardio, sports, mobility) for exerciseId values to use in log_workout. Search in Japanese or English (e.g. ベンチプレス, squat, 胸). Returns up to 20 items with tracking (reps / duration / distance) and energy profiles. Subject to the linked account's entitlement.

search_workout_exercises

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 or date range (also to find ids for delete_exercise). Pass date (single day) or startDate+endDate (up to 31 days) to review a week or month of training. Subject to the linked account's entitlement. On Free, only today and the previous 6 days can be read; older dates return 403 with the readable range (freeReadWindow).

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. The result card lets the user undo it. 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. Catalog first: when the user ate a packaged food, convenience-store item or chain-restaurant item (from a photo or a message), call search_foods and log its productId (official nutrition; the shop is recorded); use analyze_and_log_meal for dishes you cannot identify. Use manual values (mealName+cal) only for items not in the catalog (home cooking, local shops) when the user states the numbers, and never log a catalog product for a different item; for a packaged food's nutrition label, also pass salt and the other listed nutrients in detailedNutrition. 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. If a manual item looks like a catalog product, the result includes catalogSuggestions: when the user actually ate that product, log it with that productId next time. Catalog products (method 1) can be logged on any plan. Other methods: 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, name, components, or shop). It applies immediately, and the result card lets the user undo it for 24 hours. Rename with mealName when only the name was wrong ("it was the ume onigiri, not salmon"); the nutrition stays, so fix the numbers too if they differ. 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. On Free, only today and the previous 6 days can be read; older dates return 403 with the readable range (freeReadWindow).

get_meals