Deglaze

Retrieve the user's grocery list with items grouped by category. Returns items with their status (pending/completed), category, and source (manual or from a recipe). By default, only pending items are returned. Set includeCompleted to true to also see completed items.

get_grocery_list

Retrieve the user's meal plan for a date range. Returns planned items with date, meal label (Breakfast/Lunch/Dinner/Snack), recipe info, and notes. Date range behavior: both dates → exact range; only startDate → startDate through startDate+6 days; only endDate → endDate−6 days through endDate; neither → current week (Monday–Sunday). WORKFLOW: After retrieving the meal plan, use get_recipe_details to fetch full recipe content for any recipes the user wants to cook.

get_meal_plan

Retrieve full recipe details by ID. Use this when you have a recipe ID from search results, the meal plan, or the grocery list and need the full recipe content. Returns complete details including ingredients, instructions, prep/cook time, servings, and source info. Ingredients and instructions are arrays of sections — [{ sectionName?, items: [...] }] and [{ sectionName?, steps: [...] }] — matching the format edit_recipe accepts. sectionName is absent for unsectioned recipes, which have a single unnamed section. Each returned recipe carries `recipeType: "library" | "discovery"`. Library recipes also carry a `libraryDetails` object with optional rating, note, and cookCount.

get_recipe_details

IMPORTANT: Call this tool at the start of EVERY conversation before doing anything else. You are flying blind without it. Returns comprehensive user context including: - Profile: name, unit preference (metric/standard) - Preference notes: free-form notes about the user and their household (dietary restrictions, allergies, food preferences, household composition, cooking habits) - Household member preference notes: notes recorded by other household members who have their own Deglaze accounts - Cooking activity summary (last 7/30/365 days) - Recently added recipes (titles + IDs) - Most cooked recipes (titles + IDs) - Recently cooked recipes (titles + IDs) - User's tags with recipe counts (tagsAndCounts) — use these tag names directly in search_recipes tags parameter Use this context to personalize all subsequent interactions: - Respect anything captured in preference notes when suggesting recipes and meal plans - Consider household member notes when meal planning (especially allergies and restrictions) - Use the preferred unit system (metric/standard) when displaying measurements - Reference recently added/cooked recipes to understand current interests and avoid suggesting the same things - Use tagsAndCounts to understand how the user organizes recipes and filter library searches by their tags WORKFLOW GUIDANCE: 1. Always call get_user_context first. 2. Translate preference notes into concrete search parameters when relevant (e.g. an allergy becomes excludeIngredients on search_recipes). 3. If preference notes are empty and the user asks for meal planning or recipe help, naturally ask about dietary restrictions, household composition, and food preferences, then record what you learn with update_user_preferences.

get_user_context

Save a discovery recipe to the user's library when the user explicitly asks to save it (e.g. 'save this', 'add this to my library').

save_discovery_recipe_to_library

Search for recipes. Returns results from both the user's personal library (libraryRecipes, when authenticated) and the Deglaze discovery database (discoveryRecipes). Discovery results are deduped against the library — recipes the user has already saved only appear under libraryRecipes. LIBRARY vs DISCOVERY: Prefer libraryRecipes — the user already curated their library and signals like userRating and cookCount are strong. Fall back to discoveryRecipes when the library lacks good matches, or when the user is explicitly looking for something new (e.g. 'find me a new recipe', 'show me something I haven't tried'). After you've picked the results that match the user's intent, call display_recipes with those recipe IDs to show them as visual cards. QUERY vs VIBE: - 'query' is text matching. Use keywords likely to appear in a recipe (ingredient names, dish names, techniques). Stopwords add noise. - 'vibeQuery' is semantic/vector search over recipe content — describe the recipe (mood, occasion, season, flavor, technique), not the user. Strip user-relative phrases like 'something I haven't made' or 'something new'; they don't appear in recipe content and just add noise. - When both apply, use 'query' for the keyword signal and 'vibeQuery' for the full intent. TAGS: - Use tags when they obviously apply (e.g. dinner → system:course:main, pasta → system:type:pasta_noodles, vegetarian → system:dietary:vegetarian). - When a term is covered by a tag, drop it from 'query' (it can stay in 'vibeQuery'). - User tags (e.g. 'Weeknight', 'Italian') come from get_user_context's tagsAndCounts and can be passed as plain strings alongside system tags. - Filtering by a user tag scopes results to the library — discoveryRecipes is skipped, since discovery recipes don't carry user tags. PREFERENCES: Always translate the user's preference notes (from get_user_context) into concrete params. For example, allergies and strong dislikes become entries in 'excludeIngredients' (e.g. 'shellfish allergy' → ['shrimp', 'shellfish', 'crab', 'lobster', 'prawn']). EXAMPLES: - 'chicken appetizers' → query='chicken', tags=['system:course:appetizer'] - 'vegan soup' → query='soup', tags=['system:dietary:vegan'] - 'pasta with shrimp and garlic' → query='pasta shrimp garlic', returnIngredients=true - 'nut-free desserts' → query='', tags=['system:course:dessert'], excludeIngredients=['nuts', 'peanuts', 'almonds'] ('desserts' is covered by the tag and 'nut-free' goes to excludeIngredients — nothing left to keyword-match) - 'quick weeknight dinner' → query='', vibeQuery='quick weeknight dinner', tags=['system:course:main'] ('dinner' is covered by the tag; 'quick' and 'weeknight' are vibe-y modifiers unlikely to appear in recipe text — vibeQuery carries the intent) - 'something cozy for a rainy day' → query='stew braise', vibeQuery='something cozy for a rainy day' - 'spring dinner I haven't made in a while' → query='spring asparagus peas ramps rhubarb', vibeQuery='spring dinner', tags=['system:course:main'], count=30 ('spring' kept and expanded into seasonal ingredients; 'haven't made' isn't recipe content — pull a wider set (count=30) and post-filter libraryRecipes by libraryDetails.lastCooked: prefer recipes never cooked, or last cooked many months ago) SYSTEM TAGS: system:course:main, system:course:side, system:course:appetizer, system:course:dessert, system:course:breakfast, system:type:salad, system:type:pasta_noodles, system:type:rice, system:type:soup, system:type:beans_lentils, system:type:seafood, system:type:baked_goods, system:type:beverage, system:dietary:vegan, system:dietary:vegetarian

search_recipes

Update an existing meal plan item. Can change the date, label, note, or leftovers flag. Requires the item's version number for concurrency control. If a version conflict occurs, the response includes the current item state with the latest version — retry with the new version.

update_meal_plan_item

Record notes about the user and their household that will help you make better recommendations in this and every future conversation. This tool records culinary preferences and household cooking context for recipe filtering and meal planning only. It may include food allergies, user-stated health conditions that affect meal selection, dietary restrictions, ingredient dislikes, cuisine preferences, serving-size habits, and cooking constraints. It must not be used to diagnose conditions, recommend treatment, prescribe diets, or make nutrition claims. CRITICAL: These notes are your only memory of this user across sessions. Every allergy, household detail, or strong preference you fail to record is one the user has to re-explain next time — and one that could lead you to suggest an unsafe or unwanted recipe. Treat updating notes as core to doing this job well, not optional housekeeping. When in doubt, call this tool. Capture recipe-relevant household context in plain English: food allergies, dietary restrictions, ingredient dislikes, cuisine likes/dislikes, household composition, typical serving sizes, cooking habits, and constraints. These notes are used only to personalize recipe search, meal planning, and grocery-list behavior. MODES: - 'append' — add a new observation to the existing notes. Use this when you learn something new that does not contradict prior notes. - 'replace' — rewrite the notes entirely. Use this when consolidating, correcting something wrong, or when the user asks you to forget or restate something. When to call: - The user tells you about an allergy, dietary choice, or strong preference. - The user mentions someone else they cook for (partner, kids, roommates) along with their needs. - The user reveals a cooking habit, serving count, or constraint worth remembering. - You notice the current notes are stale, contradicted, or cluttered — use 'replace' to consolidate. Write in natural prose. Keep notes concise and factual. Preserve conditional nuance (e.g. 'User's spouse has a shellfish allergy; user eats shellfish only when cooking alone').

update_user_preferences