Real shopping lists and a home pantry, turned into products you can order for pickup or delivery.
Scored across 25 tools
The tool set has several intentionally differentiated item-handling tools (check_off_item, remove_item, consume_items, out_of_item, have_items), and descriptions explicitly explain their boundaries. Some overlap remains between pantry-affecting tools and between add_items/add_recipe_gap_to_list, but most selections are clearly guided.
Most tools follow a predictable verb_noun snake_case pattern (add_items, create_list, search_recipes, build_plan). A few deviations like my_recipes, recipe_needs, and out_of_item are readable but break the otherwise consistent convention.
At 25 tools, the surface is at the heavy end and requires users or agents to navigate several subdomains: lists, pantry, recipes, planning, and sharing. Most tools earn their place, but the count is borderline for a single MCP server.
Core lifecycle coverage is strong across lists, recipes, pantry, and planning, with creation, retrieval, mutation, and sharing flows represented. Minor gaps exist, such as editing list metadata or item quantities and deleting recipes/lists, but agents can work around most of them.
Add one or more items to the user's shopping list (or a specific list by id). Items appear in the user's LastList app on its next sync. Writes are literal — if an item might already be on the list, call get_list first and bump its quantity or skip it rather than adding a duplicate. Ask the user before adding items they didn't explicitly request.
Quantities: qty is always the COUNT OF BASE UNITS, not the number of packages. For 'a dozen eggs' send qty 12 with packSize 12 and packLabel 'dozen'; for 'two 12-packs of soda' send qty 24, packSize 12, packLabel '12-pack'. For anything sold by weight or volume ('2 lbs of chicken') send qty 2 with unit 'lb' and soldBy 'WEIGHT'. Getting this right is what lets the app's pack stepper and consume_items track what the user actually has.
Inputs: items (required), listId.
For a recipeId, add ONLY the ingredients the user is missing (recipe minus inventory) to their shopping list. Use for 'add what I'm missing for lasagna'. To add ALL ingredients regardless of inventory, use add_items with the full ingredient list instead.
Inputs: recipeId (required), listId, inventoryItems.
Build a shopping plan for one of the user's lists: find stores near them, work out which stores actually carry which items, and recommend a single-stop or split trip. Use for 'where should I shop for this', 'plan my trip', 'can I get all of this at one store'. This is about routing a trip, not ranking prices — describe the result as where to go and what each stop covers.
Items must be REFINED first (the shopper picking which milk, what size). Items added through these tools are not, so a list you built here needs the user to open it in LastList once, which lands on the Suggestions page and walks them through it. This tool will tell you when that is needed, and refine_items is how you resolve it in conversation.
Location: if the user has planned this list in the app before, their saved location is reused and you don't need to ask. Otherwise pass a zip (or lat/lng); without one the tool will tell you to ask the user where they're shopping.
A big list can take a few minutes. If the plan isn't ready when this returns, you get a jobId — tell the user it's building and call get_plan to check.
Inputs: lat, lng, zip, listId, +1 more.
Marks an item as bought, or undoes that. This is the tool for an item the user has acquired: 'got the milk', 'mark eggs as bought'. The item stays on the list, shown as done, so the record of the trip survives.
It is the non-destructive counterpart to remove_item, which deletes an item and leaves no record that it was ever there. Passing checked:false reverses a check-off.
Matching is loose, so 'milk' matches 'whole milk'. Returns the item and its new state, and reports an error without changing anything when nothing matches.
Inputs: name (required), listId, checked.
Record that the user USED items from their inventory (e.g. after cooking a meal): 'I made the chili', 'we used the last two eggs', 'I cooked with the chicken'. Each named item is decremented by its amount, or removed entirely when no amount is given or the amount covers what's left. Set restock:true to add anything fully used up back onto the shopping list. This is destructive to inventory — only call it when the user has actually consumed the items, never to guess at what a recipe might have used. If you are inferring the items from a recipe, confirm the list with the user first.
Inputs: items (required), amounts, restock.
Create a new list for the user (e.g. 'make a Costco list', 'start a party list', 'set up a baby registry'). Defaults to a shopping list. The list appears in the user's LastList app and is labeled as created by you. Ask the user before creating a list they didn't request.
Inputs: title (required), listType, registryOccasion.
Find stores near a location. Pass coordinates (lat, lng) if you know them, or a US ZIP code. If neither is in the conversation, ask the user. Returns retailer name, distance, address, and the store's type tags (grocery / hardware / pharmacy / etc.).
Inputs: lat, lng, zip, limit, +2 more.
Reads one list in full: its title, type, and every item on it with quantities and whether each has been checked off. This is what answers 'what's on my list', what shows whether an item is already present, and what reads the pantry's contents.
It takes a list id, which is one of the ids returned by search_lists. search_lists returns the lists themselves; this returns the contents of one of them.
Inputs: listId (required).
Check on a shopping plan that build_plan reported as still building, using the jobId it returned. Returns the finished plan, or the current progress if it is still working. Plans expire after a while — if the job is gone, just call build_plan again.
Inputs: jobId (required).
Get full detail for one recipe by its recipeId: ingredients (name, quantity, unit), the kitchen tools it needs, servings, timing, cuisine, and dietary tags. Use after search_recipes to inspect a specific recipe the user picked. Tools tiered 'specialty' are the ones a typical kitchen may not have — worth mentioning before the user commits to the recipe.
Inputs: recipeId (required).
Handle 'I already have X': take the item off the shopping list if it's there, and record it in the user's pantry/inventory if they aren't tracking it yet. Use for 'I already have rice', 'we've got plenty of olive oil', 'scratch the eggs, found some'. Use out_of_item for the opposite direction. Filler answers like 'all' or 'everything' are ignored rather than stored — if the user says something like that, ask which items they mean.
Inputs: items (required).
List the people the user is connected to in LastList, with how many lists they've already shared with each. Use this before share_list so you can name the right person. New connections have to be invited from the app — you can't create one.
Inputs: no named parameters.
Find recipes the user can make from what they have on hand. Returns 'canMakeNow' (every ingredient covered) and 'almostThere' (a few missing). Pass the user's inventory as inventoryItems; if omitted, the connection's inventory list is used. Use for 'what can I make?' / 'what's for dinner?'.
Inputs: limit, cuisine, dietary, inventoryItems.
List the recipes belonging to this user: ones they created in LastList and ones they saved from the catalog. Use for 'what are my recipes', 'pull up the one I wrote', or before publish_recipe. For the shared catalog use search_recipes instead.
Inputs: limit.
Handle 'I'm out of X': remove the item from the user's inventory (if present) and add it to their shopping list, in one step. Use for 'I'm out of butter', 'we ran out of milk', 'we need more eggs'.
Inputs: name (required).
Publish one of the user's own recipes to a PUBLIC web page anyone can open, or unpublish one that's already live.
This puts the recipe on the public internet under the user's name, so ALWAYS get explicit confirmation before publishing — say which recipe and that it will be publicly visible, and wait for a clear yes. Never publish as a side effect of some other request.
Only recipes the user wrote in LastList can be published. Catalog recipes and ones imported from another site are refused for copyright reasons. Call my_recipes first to see which ones qualify.
Inputs: recipeId (required), action.
Given a recipeId, report which ingredients the user is MISSING for it (diffed against their inventory), plus what they already have. Read-only. Use for 'what do I need for lasagna?'. To add the missing items, use add_recipe_gap_to_list.
Inputs: recipeId (required), inventoryItems.
Resolve what the shopper actually means by each item on a list, so it can be planned. 'milk' could be whole, 2%, skim or oat; 'eggs' could be 12 or 18. Call this when build_plan says items need refining, or after adding vague items.
Call it with NO choices first: it returns each unresolved item with the options to offer. Ask the shopper about them, one item at a time and in their own words rather than reading out a menu, then call it again with their answers.
Use the option labels exactly as given. An item the shopper is happy to leave vague can be skipped, but it will not be plannable until it is resolved.
Inputs: listId, choices.
Deletes an item from a list entirely, as if it had never been added. This is the tool for an item the user no longer wants: 'take milk off the list', 'I don't need the eggs after all'.
It is one of four tools that take an item off a list, and they differ by reason. check_off_item marks an item as bought and keeps it on the list. out_of_item moves an item from the pantry onto the shopping list. consume_items records that pantry items were used up while cooking. This one simply deletes, leaving no record.
Matching is loose, so 'milk' matches 'whole milk'. When several items match, the closest one is removed. Returns the removed item and the list it came from, and reports an error without changing anything when nothing matches.
Inputs: name (required), listId.
Save a recipe to the user's own collection so it shows up in my_recipes and in the app. Use when the user likes one you found ('save that one', 'add it to my recipes'). Saving is idempotent — saving twice is harmless.
Inputs: recipeId (required).
Lists the user's real LastList lists, returning each one's id, title, type and item count. This is where list ids originate: the ids accepted by the other list tools are the ones returned here. With no arguments it returns every list the user has, and the optional type filter narrows it. It returns the lists themselves rather than their contents; get_list returns the items on one.
Inputs: listType.
Search LastList's recipe catalog by name, cuisine, dietary preference, and kitchen equipment. Returns a short list of matching recipes the user can choose from, each with the tools it needs. If the user is asking 'what can I make' without naming a recipe, prefer match_recipes_to_inventory over a blind search.
Inputs: limit, query, tools, cuisine, +3 more.
Show the other products available for ONE item at ONE store, from a plan you already built. Use when a pick from build_plan is not what the shopper wanted, or when they ask what else is available for something.
Pass the jobId from build_plan and the item. Only offer this for items whose pick reported otherOptions above 0; the rest have nothing else to show.
This reads the shelf the plan was built from, so it reflects that store at that moment rather than a fresh search. A plan older than about 15 minutes has expired and needs rebuilding.
Showing alternatives does NOT change the shopper's list. If they pick one, tell them to switch it in LastList, which is where a chosen product is recorded.
Inputs: item (required), jobId (required), storeId.
Add items to the user's grocery pantry inventory in bulk, creating the pantry list if they don't have one. Use when the user is telling you what's in their kitchen ('here's what I keep stocked', 'I have flour, sugar, rice and canned tomatoes'), which is what makes match_recipes_to_inventory and recipe_needs useful. Does not touch the shopping list — use have_items when the point is that they no longer need to buy something. Duplicates are skipped.
Inputs: items (required), title.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Turn any shopping list into a ready-to-checkout grocery cart across 26 European supermarkets.
AI meal plans that fill your Kroger/Instacart cart - pantry-aware lists, all from chat.
Real recipes you can cook from the food you already have, with exactly what is missing.
Your kitchen in chat: pantry stock, shopping lists, recipes and scanned grocery receipts.
Add one secure layer between your agents and this server.
