Prospre MCP Server

Returns average and total nutrition per day, how those averages compare with the targets that applied on each day, how many days they actually logged, and a weekday-by-weekday breakdown.

Use this for any question about a period rather than a day — averages, consistency, whether weekends differ, whether they are hitting protein. It does the arithmetic here and returns a few dozen numbers, where reading the same period through get_food_log would return thousands. Reach for get_food_log when you need the actual foods.

Averages are over days that were logged, not over calendar days, and days_logged tells you which denominator was used — someone who logged four days of a fortnight has an average over four. dates_not_logged lists the rest, and days_by_meals_logged shows how many meals each logged day actually contained. Neither is discounted for you: a day with nothing logged is not evidence of a day with nothing eaten, and a one-meal day may be a real one-meal day. Weigh them yourself, but say so when the record is thin rather than reporting an average as though it were complete.

Adherence compares eaten intake against the target in force on each day, including weekday variants, and uses EATEN figures only — a future or planned day contributes ~zero eaten, so a range that reaches into the meal plan will read as under-eating. days_nothing_eaten counts such days; check the current date (get_app_settings) before treating low eaten figures as a real shortfall. Water is reported separately from the nutrients, since it is recorded on the day rather than on the foods, and carries its own target. A day with an unresolvable food keeps its resolvable figures and is counted in days_partial (at-least, not exact); a day where nothing resolves is listed in dates_unresolved and excluded — never reported as unlogged.

Dates are YYYYMMDD in the user's own timezone; this tool has no notion of "today". Read-only; at most 366 days per call.

Returns measurement units (imperial or metric), how food amounts are displayed, whether carbohydrates are shown as net or total, onboarding progress, which fitness apps are synced, the user's timezone offset, and their reminders.

Call this before reporting any weight or nutrition figure. It is what tells you whether to say pounds or kilograms, and whether "carbs" means net or total for this user.

current_time gives the server's UTC time and the user's derived local date and time. It is information, not authority: it derives from a stored timezone offset that can be stale, so if you already know the current date from the user or your client, prefer that. The dated tools always require an explicit date either way. Read-only.

Future dates are the user's meal plan — planned days live in the same diary, so reading ahead of today shows what they intend to eat.

Totals come in two forms. planned counts everything logged; eaten counts only what the user actually ticked off. A day can be fully planned and barely eaten, so do not read planned as consumed. totals.complete is false when some foods could not be looked up, and planned/eaten are null when none could — treat null as "unknown", never as zero, and say the day could not be totalled rather than reporting it as empty.

detail trades size for depth: "totals" gives day and meal totals with no item list; "names" lists foods and amounts without nutrition; "basic" (the default) adds the ~17 nutrients the app itself displays and is right for almost every question; "full" returns all ~150 stored nutrients per food and is large — use it only when you need a specific micronutrient.

Pass either date for one day, or start_date and end_date for a range, as YYYYMMDD in the user's own timezone. This tool has no notion of "today" and will not guess one — work out the user's current date yourself, or ask them, rather than omitting it. Pair with get_nutrient_targets to judge a day against what they were aiming for. Read-only; at most 31 days per call.

Check allergies before suggesting or endorsing any food. It is a list of allergen codes such as MILK, EGGS, NUTS, PEANUTS, SHELLFISH, WHEAT, GLUTEN, SOY, FISH, SESAME. Nothing else in this toolset will warn you: food search will happily return something the user is allergic to, and their own diary may contain foods from before a diagnosis.

diet_type is one of NORMAL, VEGETARIAN or VEGAN. disliked_ingredients is free text the user typed. liked_recipes and disliked_recipes are recipe IDs comparable with the ones get_saved_recipes returns, so you can filter suggestions without a second lookup. recurring_meals are meals the user has fixed to particular weekdays.

This reads the list exactly as it stands in the app. The app generates it from the meal plan when the user asks; it is not recomputed here, so diary changes made after that generation are not reflected in it. start_date/end_date say which days it was built for. A grocery list is a shopping artifact — it carries no nutrition; questions about how the user will eat belong to get_food_log and analyze_range. Each item carries its food id, so any of them can be looked up further. Read-only.

Targets change over time, and they can also differ by weekday. This returns the ones that actually applied on that date rather than the current ones, so it is the right way to judge a past day against what the user was really aiming for at the time. day_target_applied names the weekday variant when one applied.

Pair with get_food_log to compare intake against target. Pass the date as YYYYMMDD in the user's own timezone — this tool has no notion of "today" and will not guess one. Read-only.

This is what makes advice specific to the person rather than generic. Without it you cannot estimate maintenance calories or say whether a protein target suits their body. activity_level includes the multiplier the app itself applies over BMR, so use that rather than a textbook figure if you want a number consistent with what the app shows.

Height is stored in centimetres and returned in both centimetres and feet/inches. Note that weight, from get_weight_history, is stored in POUNDS — the two are in different systems, so convert deliberately when combining them. Date of birth is returned as-is rather than an age, because working out an age needs today's date, which this server cannot know.

This is the quickest read on what someone eats day to day and what they are most likely to log next. Prefer it over searching the food database when you want the specific version of a food this user actually logs. Read-only.

Takes any recipe id — from search_recipes, the diary, or get_saved_recipes — so this is how to answer "what's in it and how do I make it" for a recipe the user has not saved. Works for a plain food id too, which returns that food's record without ingredients. Read-only.

Use this to learn what someone habitually eats rather than inferring it from a single day, and to refer to a meal by the name they know it by. detail: "totals" gives each meal's name and nutrition without its ingredient list, which is usually enough to choose one. A meal whose foods cannot all be looked up reports nutrition: null with the reason — never a sum that is secretly missing an item. Read-only.

Prefer suggesting from these over recipes the user has never seen — a saved recipe is one they already chose to keep. Set include_ingredients to also get what goes into each and how to make it.

Goals are stored per start date, so this returns the one that was in force on the date asked for rather than the newest — the right way to judge a past period against what the user was actually working towards then. Weights come in both pounds and kilograms; the app stores pounds regardless of display units. Pass the date as YYYYMMDD in the user's own timezone; this tool has no notion of "today". Read-only.

Every weight is returned in both pounds and kilograms, because the app stores pounds no matter which units the user has chosen to see — check get_app_settings for which to speak in. Weigh-ins are sporadic: a user may record once a week or skip a month, so the number of readings is not the number of days. Pass dates as YYYYMMDD in the user's own timezone; this tool has no notion of "today". Read-only; at most 366 days per call.

An empty result for a barcode means it is not in the database — if the user has the package, the label's figures can be used to add it as a custom food.

source controls the scope: "all" (the default) searches Prospre's verified food database, community-shared custom foods and the user's own; "verified" searches only foods with reviewed nutrition data — use it when accuracy matters more than coverage; "own" searches only the custom foods this user created themselves, so an empty result means the user has no such food.

Read-only. Result IDs are prefixed LI (a user-created food) or RI (a reference food); Own is true for the caller's own entries. Results are summary cards: name, brand and Calories only, where the Calories describe one serving of the food as it is stored. For full nutrition or the serving definition, look the food up (the diary and detail tools return it) rather than inferring from a card.

Result IDs are prefixed RR (Prospre recipe) or LR (the user's own), and can be logged with log_food or passed to get_saved_recipes-style lookups.

Use this to suggest something new. get_saved_recipes only returns recipes the user has already kept, so it cannot answer "what else could I make". Results are summary cards: name, brand and Calories only, where the Calories describe one serving of the food as it is stored. For full nutrition or the serving definition, look the food up (the diary and detail tools return it) rather than inferring from a card.

Use this only when a food genuinely is not in the database — search first with search_foods (by name or barcode). Home cooking, a local product, or something from a nutrition label the user is reading out.

The nutrition figures are per serving, where the serving is serving_amount of serving_unit — so for a label reading "per 100g: 380 kcal", pass serving_amount 100, serving_unit "g", Calories 380. Getting that wrong scales everything the user logs against it, so confirm the serving size with them rather than assuming.

Returns the new food id, which log_food accepts directly.

Find ingredient ids with search_foods or reuse them from the diary. Pass amounts for the whole batch and set servings to the number of portions it makes. Units follow log_food; an unsupported unit is refused with the accepted list. Ingredients must be foods (RI…/LI…), not recipes; use a recipe’s ingredients instead.

Returns the new recipe id for get_recipe or log_food (unit "Serving"). Creating it does not change existing diary entries. It is added to saved recipes and has no image until the user adds one in the app.

Takes the entry's uuid, which get_food_log returns for every item. Entries are addressed by uuid rather than position because positions shift as a day is edited. Read the day first if you do not already have it.

Days where the meal was already logged are untouched — the diary stores copies, not references. Any recurring meal that pointed at it is removed too, as the app itself does.

This deletes the reading the way the app does when a weight is cleared. To change a reading rather than remove it, use log_weight — it replaces the day's value.

Takes the entry's uuid from get_food_log. Pass only what you want to change; anything omitted is left as it is. Changing the amount or unit re-derives the nutrition, so use a unit the food accepts — an unrecognised one is refused rather than guessed at.

Takes the saved meal id from get_saved_meals. items REPLACES the whole list — read the meal first and send everything it should contain, not just the additions. Amounts and units follow the same rules as log_food: use a unit the food accepts, and an unaccepted one is refused with the accepted list.

Find the food first with search_foods, or reuse an id from get_recent_foods, and pass its id here. amount and unit are in the food's own terms. Which units a food accepts follows from its record: a food stored by weight (Stored Unit g or oz) accepts any weight unit, one stored by volume any volume unit, and every food additionally accepts the units in its own Serving Sizes. An unaccepted unit is refused rather than guessed at, and the refusal lists the exact units this food takes.

The date is required and is the day in the user's own timezone; this tool has no notion of "today". eaten defaults to true — pass false to plan a meal the user has not eaten yet, which is the distinction get_food_log reports as planned versus eaten.

Returns the entry as stored and which meal it landed in. If the write is refused, nothing changes and the reason is returned.

Takes a saved meal id from get_saved_meals. This is the fast path for "log my usual breakfast" — logging the same foods one at a time works but is slower and easier to get wrong. The amounts come from the saved meal as the user defined them. A day with no diary entries yet is fine — the day is created.

One reading per day — logging again for a day replaces that day's reading rather than adding a second. Give the weight in whichever unit the user spoke in and say which; kilograms are converted, since the app stores pounds. Check get_app_settings for the units they expect to hear back.

Takes the entry's uuid from get_food_log and the replacement food's id, amount and unit. The replacement lands in the same position in the same meal. Like the app's own swap, the new entry starts as not eaten (planned) unless you pass eaten: true — replacing a planned item does not mean the user ate the new one.

This is the tool for editing a meal plan: future diary dates are the plan, so "swap Tuesday's lunch for salmon" is this tool on a future date. Removing and re-adding would work but takes two writes and loses the position.

Takes the foods from a meal already in the diary — pass the date and meal, and what is in it is saved under the name you give. Use this when a user says something like "save that as my usual breakfast". get_saved_meals lists them; log_saved_meal logs one.

Use it when the user wants to keep something you found with search_recipes. Saving what they ask to keep is how their collection stays meaningful, so save on request rather than on your own initiative.

Pass only what you want to change; anything omitted is left alone. Each list replaces the existing one rather than adding to it, so read get_food_preferences first and send the full list.

Allergies are safety-critical, so removing one takes proof you have read the current list: any change that would drop a stored allergy must include previous_allergies matching what is stored, or it is refused with the stored list. Adding is frictionless. Diet and cuisine values are the app's own vocabularies (enforced); disliked ingredients are free text. An account with no preferences yet gets them created from the app's empty defaults.

Takes food ids from get_grocery_list. Use it as the user shops. Items not mentioned are left as they are.

Use this when a user confirms they ate what was planned, rather than editing each entry. get_food_log reports the difference as planned versus eaten. The app only marks food eaten on today or earlier — a future day is a plan, so leave it planned.

Targets are stored per change-date: setting one on a date leaves earlier targets intact, so past days are still judged against what applied then, but every target dated after it is deleted, matching what the app does. Say so before changing a date in the past.

Pass only the figures you want to change; anything omitted keeps its current value. Macros are grams, calories are kcal, water is millilitres. If the user has weekday-varying targets this sets the base, not the variants. On an account with no targets yet, the omitted figures start from the app's own defaults.

Pass only what you want to change; anything omitted is left as it is. Height is in CENTIMETRES — convert from feet and inches yourself before calling. These details are what get_personal_info reads and what makes advice specific to the person, so this is how an account that has never opened the app gets a real profile.

Disliked recipes are what the app already uses to filter suggestions — get_food_preferences returns both lists, so check them before recommending. A recipe is never on both lists: liking removes a dislike and vice versa. Note the app itself currently only acts on dislikes; likes are stored for the user and for future recommendation features.

This sets the total for the day rather than adding to it, so read the current figure from get_food_log first if the user is topping up rather than correcting. Water is stored in millilitres. A day with no diary entries yet is fine — the day is created.

Goals are stored per start date, so setting one starting today leaves earlier goals in place for judging earlier periods. Read get_weight_history first if you need a sensible starting weight rather than one the user guessed at.

The recipe itself still exists and can be found again with search_recipes; only the user's bookmark is removed.