plan-to-eat-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PLAN_TO_EAT_PASSWORD | Yes | Plan to Eat account password. | |
| PLAN_TO_EAT_USERNAME | Yes | Plan to Eat account username/email. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_recipesA | List the user's whole recipe book (own + saved + queued + friend recipes), optionally filtered by title words, course, or ownership. Narrow with a filter when you can: the unfiltered book can run to well over a thousand rows. Each row has id, title, owned, and whichever of course_title, cuisine_title, main_ingredient_title, tag_titles, total_time (minutes) and rating are set — empty ones are left out. Rows carry no ingredients, directions, description, servings or nutrition — call get_recipe on an id for those. Inactive, removed and hidden recipes are left out. |
| get_recipeA | Get a single recipe by id, including directions, ingredients, tags, prep_notes, comments. |
| create_recipeB | Create a new recipe. Only |
| update_recipeB | Update an existing recipe. Pass only the fields you want to change. To remove an ingredient include {id, _destroy: true} in ingredients. |
| delete_recipeB | Delete a recipe by id. |
| list_coursesA | List all courses (Appetizers, Main Course, etc.). |
| list_cuisinesA | List all cuisines. |
| list_main_ingredientsA | List all main-ingredient categories. |
| list_tagsB | List all tags. |
| list_storesA | List the user's grocery stores. Use the ids as |
| list_grocery_categoriesA | List the user's grocery aisles (Produce, Dairy, ...). Use the ids as |
| list_planner_eventsA | List all planner (calendar) events. Each entry: { date, recipe_id, section, servings, ... }. |
| get_planner_weekA | Fetch all planner events between start_date and end_date (inclusive, YYYY-MM-DD). end_date defaults to start_date + 6 days. Recipe events are enriched with |
| find_planned_datesA | Find planner events for a given recipe, optionally constrained to a date range. Useful for "is this recipe already planned this week?" checks before scheduling. |
| add_planner_recipeB | Add a recipe to a meal slot on the planner. Returns the newly created event (id, date, section, servings, ...). |
| add_planner_ingredientA | Add a freeform "ingredient" entry to a meal slot (e.g. "2 lbs ground beef" attached to Wednesday dinner). |
| add_planner_noteB | Add a freeform "note" entry to a meal slot (e.g. "Defrost chicken" on Tuesday breakfast). |
| add_leftover_mealA | Schedule a leftover meal derived from a previously planned recipe event. Duplicates the source event with |
| move_planner_eventA | Move an existing planner event to a different date and/or section. Works for recipe, note, and ingredient events. |
| reorder_planner_eventsB | Reorder events within a section. Pass |
| update_planner_entry_textA | Update the text of a note or ingredient planner entry. Note: uses the |
| set_planner_servingsC | Set the servings count on a recipe planner event. |
| duplicate_planner_eventA | Duplicate a planner event. Set plan_leftover=true to mark the copy as a leftover. |
| delete_planner_eventB | Delete a planner event by id. |
| update_planner_optionsA | Update planner display/behaviour preferences (time_zone, planner_start_day, calendar_settings.show_calories, etc). Use Rails-style nested keys like |
| list_frozen_recipesA | List what's in the freezer. Each entry: { id, recipe_id, count, servings, frozen_on }. By default only returns active entries (count > 0); pass include_consumed=true to also see history (the API soft-deletes by zeroing the count rather than removing the row). |
| freeze_recipe_portionsA | Mark N portions of a previously cooked recipe as frozen. |
| delete_frozen_recipeA | Mark a frozen entry as consumed (the portion was eaten or thrown out). Soft-delete: API sets count to 0; the entry persists as history. |
| get_shopping_listA | Read the shopping list. Each line gives what to buy plus the store it's assigned to ( |
| add_shopping_list_itemsA | Add items to the shopping list. Only |
| update_shopping_list_itemsA | Change shopping list lines. Pass |
| remove_shopping_list_itemsA | Remove lines from the shopping list. This is a soft delete, the same one the app does, and restore_shopping_list_items undoes it — but nothing can list removed lines, so keep the item_ids around if the removal might need undoing. |
| restore_shopping_list_itemsA | Put previously removed shopping list lines back on the list. Takes the item_ids the line had before it was removed. |
| list_menusB | List saved menus. |
| list_friendsA | List friends. |
| get_countsA | Get recipe-book counts: { friends, queued, frozen }. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 36 tools
Most tools have clearly distinct resource/action targets across recipes, planner events, shopping list, and freezer. A few planner tools overlap meaningfully: add_leftover_meal largely duplicates duplicate_planner_event with plan_leftover=true, and list_planner_events/get_planner_week/find_planned_dates serve similar lookup needs. Still, descriptions generally help an agent choose correctly.
Almost every tool follows a predictable snake_case verb_noun convention: get_recipe, create_recipe, list_recipes, add_planner_recipe, move_planner_event, update_shopping_list_items. Minor names like get_counts and find_planned_dates are still readable and consistent enough. There is no mixed casing or chaotic verb style.
36 tools is heavy for the apparent domain and exceeds the typical well-scoped range. Many planner operations are highly granular (add_note, add_ingredient, set_servings, reorder, update_entry_text, update_options), which could likely be consolidated. The large surface increases selection burden even though the domain is broad.
Core lifecycles are covered: recipes have CRUD, planner events have create/list/move/reorder/duplicate/delete, shopping list has read/add/update/remove/restore, and freezer entries have list/freeze/consume. Minor gaps exist, such as menus only being listable with no create/update/delete, and stores/grocery categories only being listable. These are workable omissions rather than severe dead ends.