Skip to main content
Glama

Wellness Project

by ai.wellnessproject
OverviewDiscussionsAdmin

log_meal

Log a meal to the user's food diary. Use when the user mentions eating, describes a meal, or asks to log food.

INFER:

  • date: today, or from context ("yesterday", "last night")

  • meal_type: canonical time mapping (00-05 Snack, 05-10 Breakfast, 10-14 Lunch, 14-17 Snack, 17-22 Dinner, 22-24 Snack); context overrides ("post-workout shake"=Post-Workout)

MACRO SOURCE: strongest evidence wins. Never replace known stored macros with a fresh estimate.

  1. REPEATS: if the user refers to a previously logged item ("same", "another", "more", "again", or equivalent in any language), call list_meals for the referenced date/range first. If one row unambiguously matches, reuse its stored calories/protein_g/fat_g/carbs_g/alcohol_g and scale by the quantity ratio when the row's quantity is known. If the match or quantity is ambiguous, ask instead of re-estimating. If nothing matches, continue below.

  2. SAVED RECIPES: pass recipe_name whenever the food phrase plausibly names one of the user's saved recipes (see the profile's "Saved recipes" list) -- not only when the user literally says "saved" or "usual"; a bare "morning coffee" should try recipe_name if "Morning Coffee" is one of theirs. A resolved recipe is a default for THIS meal, not a binding rule: it supplies stored food and macros, and any detail the user states this turn (e.g. "black" instead of the recipe's usual cream) overrides just that field the normal way, via the matching explicit argument. The recipe itself changes only through the Recipes page, never as a side effect of log_meal. Relay no-match/ambiguous errors instead of guessing. If the recipe reports missing macros, estimate only those fields and retry. If food_items adds food beyond the recipe, pass all four macros as the combined total.

  3. BRAND NAMES: for a branded, restaurant, or specific product, use published macros for the stated size/variant before a generic estimate.

  4. Otherwise estimate calories, protein_g, fat_g, carbs_g from the food description. Never ask the user for macros.

MACROS: food_items plus calories/protein_g/fat_g/carbs_g are required unless recipe_name supplies them. Ask only if food_items are absent and no recipe_name applies. Never call without all four macros populated.

SATURATED FAT / FIBER: saturated_fat_g and fiber_g are optional, unlike the four core macros. Populate them only when you have real evidence (a Nutrition Facts label, a well-known packaged product, or a food you can confidently estimate the composition of) -- never guess just to fill the field, and never send a value equal to fat_g (saturated fat is always a subset of total fat, not the whole of it, except literally pure fats like butter or coconut oil). Omit both entirely when unsure; they are never asked for and never inferred as 0.

FASTING: if the user ate nothing / fasted all day, log one "Fast day" Snack with calories/protein_g/fat_g/carbs_g all 0.

DUPLICATES: if this tool returns a duplicate error, tell the user what's already logged and ask whether this is a separate serving (retry with force=true) or should update the existing entry instead (update_meal with adjusted values).

DRINKS / HYDRATION: this is the single write path for consumed drinks too. When a drink amount is known or reasonably inferable, include it in fluids even when the same drink also contributes calories/macros/alcohol. The server decides whether hydration tracking is enabled; never use a separate hydration write tool. A plain fluid-only intake may omit food_items and macros and send only fluids. For alcoholic drinks, include that drink's alcohol_g in its fluid item; if there is exactly one drink, the top-level alcohol_g can stand in.

CAFFEINE / DRINKS: this is the single assistant write path for caffeine too. When the user consumed a drink and its volume is known or reasonably inferable, include it in fluids so hydration is recorded; if the drink is caffeinated, include caffeine in the same call too. Do not leave a known-volume drink only in food_items. Each caffeine item needs caffeine_mg and may optionally include source_type. The date comes from the intake date. Preserve exact user-provided milligrams; for vague coffee/tea/energy-drink/pre-workout descriptions, estimate caffeine with the same nutrition-estimation judgment used for meal macros. Never use separate hydration or caffeine write tools. A drink-only or caffeine-only intake may omit food_items/macros.

SAVE AS RECIPE: when the user explicitly asks to save the meal they are logging as a reusable recipe, set save_as_recipe=true in this same call. The recipe is copied from the final persisted meal after the log succeeds.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoYYYY-MM-DD. Omit for today (the server resolves it in the user's own timezone, more reliable than guessing). Send explicitly for any past date.
fat_gNoFat in grams. See MACROS above.
forceNoTrue only when the user has explicitly confirmed a separate entry despite a duplicate warning. Bypasses duplicate detection.
fluidsNoOptional drinks consumed in this intake. Omit when no drink amount is known. Hydration is persisted only when the user enabled hydration tracking.
carbs_gNoCarbohydrates in grams. See MACROS above.
fiber_gNoDietary fiber in grams. Optional. See SATURATED FAT / FIBER above.
caffeineNoOptional caffeine doses in this intake. Keep each dose simple: caffeine amount is required and type is optional. The dose date follows the intake/meal date. If the user gave exact milligrams, preserve them exactly; otherwise estimate from the described food or drink.
caloriesNoTotal calories (kcal). See MACROS above.
alcohol_gNoAlcohol in grams (not kcal). Only if alcoholic drinks were consumed; unset takes the saved recipe's value when recipe_name matches. 1 standard drink is about 14g.
meal_typeYesRequired. Infer from time of day or context, even when recipe_name is used (a saved recipe's own stored meal type never fills this in).
protein_gNoProtein in grams. See MACROS above.
food_itemsNoDescription of the food and drinks consumed. See MACROS above; ask the user only if completely absent and no recipe_name applies.
recipe_nameNoName or close phrase for one of the user's saved recipes, e.g. "protein oats", "chicken bowl", or "breakfast" for their saved Breakfast recipe. See SAVED RECIPES above.
save_as_recipeNoTrue only when the user explicitly asks to save this meal as a reusable recipe. The recipe is copied from the final persisted meal. On update_meal, this can be the only requested action; use the real meal id or normal selectors and do not invent an edit.
saturated_fat_gNoSaturated fat in grams. Optional. See SATURATED FAT / FIBER above.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYesHuman-readable result text returned by the tool.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / recipe_multiplier
      Removed value: -{
-  "description": "Positive serving multiplier for recipe_name, e.g. 0.5 for half or 2 for double. Omit for one saved serving.",
-  "type": "number"
-}
  2. Changed1 schema field changed
    • addedInput schema / properties / recipe_multiplier
      Added value: +{
+  "description": "Positive serving multiplier for recipe_name, e.g. 0.5 for half or 2 for double. Omit for one saved serving.",
+  "type": "number"
+}
  3. Changed2 schema fields changed
    • addedInput schema / properties / fiber_g
      Added value: +{
+  "description": "Dietary fiber in grams. Optional. See SATURATED FAT / FIBER above.",
+  "type": "number"
+}
    • addedInput schema / properties / saturated_fat_g
      Added value: +{
+  "description": "Saturated fat in grams. Optional. See SATURATED FAT / FIBER above.",
+  "type": "number"
+}
  4. Changed1 schema field changed
    • addedInput schema / properties / save_as_recipe
      Added value: +{
+  "description": "True only when the user explicitly asks to save this meal as a reusable recipe. The recipe is copied from the final persisted meal. On update_meal, this can be the only requested action; use the real meal id or normal selectors and do not invent an edit.",
+  "type": "boolean"
+}
  5. Changed2 schema fields changed
    • changedInput schema / properties / fluids / items / properties / beverage_type / description
      Previous value: -"Broad drink type. Default water. Use other when the exact drink is not in the enum and preserve its name in beverage_name."New value: +"Broad drink type. Default water. Energy drinks are accepted and stored as other; preserve the exact drink in beverage_name."
    • changedInput schema / properties / fluids / items / properties / beverage_type / enum
      Previous value: -[
-  "water",
-  "electrolyte",
-  "sports_drink",
-  "coffee",
-  "tea",
-  "juice",
-  "milk",
-  "soda",
-  "broth",
-  "other"
-]New value: +[
+  "water",
+  "electrolyte",
+  "sports_drink",
+  "coffee",
+  "tea",
+  "juice",
+  "milk",
+  "soda",
+  "broth",
+  "other",
+  "energy_drink"
+]
  6. Changed10 schema fields changed
    • changedInput schema / properties / caffeine / description
      Previous value: -"Optional caffeine doses in this intake. Every dose must identify the ingested caffeine source. If the user gave exact milligrams, preserve them exactly. If only a food/drink is described, estimate caffeine with the same nutrition-estimation judgment used for meal macros. Each item preserves its consumed time."New value: +"Optional caffeine doses in this intake. Keep each dose simple: caffeine amount is required and type is optional. The dose date follows the intake/meal date. If the user gave exact milligrams, preserve them exactly; otherwise estimate from the described food or drink."
    • changedInput schema / properties / caffeine / items / properties / caffeine_mg / description
      Previous value: -"Caffeine in milligrams. Preserve an explicit user amount exactly; otherwise estimate from the described source."New value: +"Caffeine in milligrams. Preserve an explicit user amount exactly; otherwise estimate from the described intake."
    • removedInput schema / properties / caffeine / items / properties / consumed_at
      Removed value: -{
-  "description": "Alternative ISO 8601 timestamp with offset. Optional.",
-  "type": "string"
-}
    • removedInput schema / properties / caffeine / items / properties / consumed_date
      Removed value: -{
-  "description": "Local date YYYY-MM-DD. Default: the meal date, then today.",
-  "type": "string"
-}
    • removedInput schema / properties / caffeine / items / properties / consumed_time
      Removed value: -{
-  "description": "Local time HH:MM. Default: current local time for today; ask rather than invent a time for historical intake.",
-  "type": "string"
-}
    • removedInput schema / properties / caffeine / items / properties / note
      Removed value: -{
-  "description": "Additional context. Optional.",
-  "type": "string"
-}
    • removedInput schema / properties / caffeine / items / properties / source_name
      Removed value: -{
-  "description": "Specific food, drink, supplement, or product name. Required when source_type is other; optional otherwise.",
-  "type": "string"
-}
    • changedInput schema / properties / caffeine / items / properties / source_type / description
      Previous value: -"Required broad ingested caffeine source. Use other only when source_name identifies the specific food, drink, or supplement."New value: +"Optional broad caffeine type."
    • removedInput schema / properties / caffeine / items / properties / source_type / enumFallback
      Removed value: -{
-  "annotate": "source_name",
-  "value": "other"
-}
    • changedInput schema / properties / caffeine / items / required
      Previous value: -[
-  "caffeine_mg",
-  "source_type"
-]New value: +[
+  "caffeine_mg"
+]
  7. Changed1 schema field changed
    • addedInput schema / properties / caffeine
      Added value: +{
+  "description": "Optional caffeine doses in this intake. Every dose must identify the ingested caffeine source. If the user gave exact milligrams, preserve them exactly. If only a food/drink is described, estimate caffeine with the same nutrition-estimation judgment used for meal macros. Each item preserves its consumed time.",
+  "items": {
+    "properties": {
+      "caffeine_mg": {
+        "description": "Caffeine in milligrams. Preserve an explicit user amount exactly; otherwise estimate from the described source.",
+        "type": "number"
+      },
+      "consumed_at": {
+        "description": "Alternative ISO 8601 timestamp with offset. Optional.",
+        "type": "string"
+      },
+      "consumed_date": {
+        "description": "Local date YYYY-MM-DD. Default: the meal date, then today.",
+        "type": "string"
+      },
+      "consumed_time": {
+        "description": "Local time HH:MM. Default: current local time for today; ask rather than invent a time for historical intake.",
+        "type": "string"
+      },
+      "note": {
+        "description": "Additional context. Optional.",
+        "type": "string"
+      },
+      "source_name": {
+        "description": "Specific food, drink, supplement, or product name. Required when source_type is other; optional otherwise.",
+        "type": "string"
+      },
+      "source_type": {
+        "description": "Required broad ingested caffeine source. Use other only when source_name identifies the specific food, drink, or supplement.",
+        "enum": [
+          "coffee",
+          "espresso",
+          "tea",
+          "energy_drink",
+          "soda",
+          "pre_workout",
+          "supplement",
+          "other"
+        ],
+        "enumFallback": {
+          "annotate": "source_name",
+          "value": "other"
+        },
+        "type": "string"
+      }
+    },
+    "required": [
+      "caffeine_mg",
+      "source_type"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
  8. Changed14 schema fields changed
    • changedInput schema / properties / alcohol_g / description
      Previous value: -"Alcohol in grams (not kcal). Optional — include only if alcoholic drinks were consumed. Reference: 1 standard drink ≈ 14g alcohol."New value: +"Alcohol in grams (not kcal). Only if alcoholic drinks were consumed; unset takes the saved recipe's value when recipe_name matches. 1 standard drink is about 14g."
    • changedInput schema / properties / calories / description
      Previous value: -"Total calories (kcal). Required — estimate from the food description before calling this tool. Never omit."New value: +"Total calories (kcal). See MACROS above."
    • changedInput schema / properties / carbs_g / description
      Previous value: -"Carbohydrates in grams. Required — estimate from the food description before calling this tool. Never omit."New value: +"Carbohydrates in grams. See MACROS above."
    • changedInput schema / properties / date / description
      Previous value: -"Date of the meal. Format: YYYY-MM-DD. Optional — omit for today (the server fills it in from the user's own timezone, which is more reliable than guessing). Send it explicitly for any past date."New value: +"YYYY-MM-DD. Omit for today (the server resolves it in the user's own timezone, more reliable than guessing). Send explicitly for any past date."
    • changedInput schema / properties / fat_g / description
      Previous value: -"Fat in grams. Required — estimate from the food description before calling this tool. Never omit."New value: +"Fat in grams. See MACROS above."
    • addedInput schema / properties / fluids
      Added value: +{
+  "description": "Optional drinks consumed in this intake. Omit when no drink amount is known. Hydration is persisted only when the user enabled hydration tracking.",
+  "items": {
+    "properties": {
+      "alcohol_g": {
+        "description": "Alcohol grams in this specific drink. Required per alcoholic fluid when more than one drink is present.",
+        "type": "number"
+      },
+      "beverage_name": {
+        "description": "Specific drink name when useful, e.g. IPA, vodka soda, latte.",
+        "type": "string"
+      },
+      "beverage_type": {
+        "description": "Broad drink type. Default water. Use other when the exact drink is not in the enum and preserve its name in beverage_name.",
+        "enum": [
+          "water",
+          "electrolyte",
+          "sports_drink",
+          "coffee",
+          "tea",
+          "juice",
+          "milk",
+          "soda",
+          "broth",
+          "other"
+        ],
+        "type": "string"
+      },
+      "unit": {
+        "description": "Volume unit. Default ml.",
+        "enum": [
+          "ml",
+          "fl_oz"
+        ],
+        "type": "string"
+      },
+      "volume": {
+        "description": "Consumed drink volume in the supplied unit.",
+        "type": "number"
+      }
+    },
+    "required": [
+      "volume"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
    • changedInput schema / properties / food_items / description
      Previous value: -"Description of the food and drinks consumed. Required — ask the user if completely absent."New value: +"Description of the food and drinks consumed. See MACROS above; ask the user only if completely absent and no recipe_name applies."
    • changedInput schema / properties / force / description
      Previous value: -"Optional — set true only when the user has explicitly confirmed they want to log a separate entry despite a duplicate warning. Bypasses duplicate detection."New value: +"True only when the user has explicitly confirmed a separate entry despite a duplicate warning. Bypasses duplicate detection."
    • changedInput schema / properties / meal_type / description
      Previous value: -"Type of meal. Required — infer from time of day or context if not stated."New value: +"Required. Infer from time of day or context, even when recipe_name is used (a saved recipe's own stored meal type never fills this in)."
    • changedInput schema / properties / meal_type / enum
      Previous value: -[
-  "Breakfast",
-  "Lunch",
-  "Dinner",
-  "Snack",
-  "Post-Workout"
-]New value: +[
+  "Breakfast",
+  "Lunch",
+  "Dinner",
+  "Snack",
+  "Post-Workout",
+  "Shake",
+  "Other"
+]
    • addedInput schema / properties / meal_type / enumFallback
      Added value: +{
+  "annotate": "food_items",
+  "value": "Other"
+}
    • changedInput schema / properties / protein_g / description
      Previous value: -"Protein in grams. Required — estimate from the food description before calling this tool. Never omit."New value: +"Protein in grams. See MACROS above."
    • addedInput schema / properties / recipe_name
      Added value: +{
+  "description": "Name or close phrase for one of the user's saved recipes, e.g. \"protein oats\", \"chicken bowl\", or \"breakfast\" for their saved Breakfast recipe. See SAVED RECIPES above.",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "meal_type",
-  "food_items",
-  "calories",
-  "protein_g",
-  "fat_g",
-  "carbs_g"
-]New value: +[
+  "meal_type"
+]
  9. First observed

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare it is a non-idempotent write (readOnlyHint=false, idempotentHint=false), but the description goes far beyond: duplicate detection and force=true retry semantics, the rule never to replace stored macros, recipe non-mutation, fasting-day collapse to a zero-macro "Fast day" Snack, and hydration/caffeine persistence behavior. This is unusually rich behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and trigger, then organized into clear headed sections, so structure is strong. It is long, and the DRINKS/HYDRATION and CAFFEINE/DRINKS sections partially restate each other (both repeat "single write path"), which is mild redundancy for an otherwise complex tool that justifies most of its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be explained, and the description covers all the decision logic an agent needs for a 15-parameter write tool: inference, macro sourcing, optional fields, duplicates, fasting, drinks/caffeine, and recipe saving. Nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema: INFER rules for date and meal_type (with time-band mapping and context overrides), the macro-source priority (repeats > saved recipes > brands > estimate), saturated_fat_g/fiber_g evidence rules, and fluids/caffeine/alcohol semantics. Schema fields even defer back to these sections ("See MACROS above"), so the description carries essential semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ("Log a meal to the user's food diary") and immediately scopes the trigger condition. It also distinguishes itself from siblings by naming list_meals, update_meal, and the never-use separate hydration/caffeine write tools. An agent can identify this as the single write path for meal food.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use ("user mentions eating, describes a meal, or asks to log food") plus when to route elsewhere: list_meals first for repeats, update_meal for adjusts, and explicit prohibition of separate hydration/caffeine tools. Covers when-not and alternatives, which is the top bar.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Wellness Project toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources