Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AnyList MCP Server Add the ingredients for my lasagna recipe to the Groceries list"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that connects AI assistants to AnyList — giving them access to your shopping lists, recipes, and meal plans.
Shopping Lists — View lists, check items, add freeform items or recipe ingredients
Recipes — Search and retrieve full recipe details including ingredients and steps
Meal Planning — View and schedule meals on your AnyList calendar
Grocery Helpers — Add ingredients from one or multiple recipes to a list with duplicate handling
Related MCP server: Mealie MCP Server
Node.js >= 18
An AnyList account (email/password)
Clone this repository:
git clone <this-repo> anylist-mcp
cd anylist-mcpInstall dependencies:
npm installBuild:
npm run buildThe server requires your AnyList credentials as environment variables:
Variable | Description |
| Your AnyList account email |
| Your AnyList account password |
Add to your Claude Desktop config (claude_desktop_config.json):
{
"mcpServers": {
"anylist": {
"command": "node",
"args": ["/path/to/anylist-mcp/dist/index.js"],
"env": {
"ANYLIST_EMAIL": "your-email@example.com",
"ANYLIST_PASSWORD": "your-password"
}
}
}
}Run the server via stdio transport:
ANYLIST_EMAIL=you@example.com ANYLIST_PASSWORD=secret node dist/index.jsOr for development:
ANYLIST_EMAIL=you@example.com ANYLIST_PASSWORD=secret npm run devTool | Description |
| List all shopping lists with item counts |
| Get all items on a specific list |
| Add a freeform item to a list (with duplicate checking) |
| Add a recipe ingredient to a list with proper categorization |
Tool | Description |
| List all recipes, optionally filtered by name |
| Get full recipe details including ingredients and steps |
Tool | Description |
| Add all ingredients from a recipe to a list |
| Batch add ingredients from multiple recipes to a list |
Tool | Description |
| Get meal plan events for a date range (defaults to current week) |
| Schedule a recipe or event on a specific day |
add_item_to_listAdd a freeform item to a shopping list. If the item already exists and is checked off, it will be unchecked instead of duplicated.
item_name (required) — Name of the item
list_name (required) — Target list name
quantity (optional) — e.g. "2 lbs", "3"
add_ingredient_to_listAdd a specific ingredient from a recipe to a shopping list. Uses AnyList's ingredient handler for proper categorization, and matches against existing or recently used items.
recipe_name or recipe_id (one required) — The recipe to pull from
ingredient_name (required) — Ingredient name (case-insensitive, partial match)
list_name (optional, default: "Groceries") — Target list
add_recipe_ingredients_to_listAdd all ingredients from a single recipe to a list. Handles duplicates: skips items already present, unchecks previously checked-off items.
recipe_name or recipe_id (one required)
list_name (optional, default: "Groceries")
add_ingredients_to_listBatch version — add ingredients from multiple recipes at once. Deduplicates across recipes.
recipe_names or recipe_ids (one required, array)
list_name (optional, default: "Groceries")
get_recipe_detailsGet full recipe details including ingredients (with name, quantity, and notes) and preparation steps.
recipe_name or recipe_id (one required)
add_meal_plan_eventSchedule a recipe or titled event on the meal plan calendar.
date (required) — YYYY-MM-DD format
recipe_name or recipe_id (optional) — Recipe to schedule
title (optional) — Event title (used if no recipe, or as override)
label (optional) — e.g. "Breakfast", "Lunch", "Dinner"
ISC
Add ingredients from multiple recipes to a shopping list at once. Defaults to the "Groceries" list. Handles duplicates across recipes: each ingredient is only added once.
| Name | Required | Description | Default |
|---|---|---|---|
| recipe_names | No | Array of recipe names | |
| recipe_ids | No | Array of recipe identifiers | |
| list_name | No | Target list name (defaults to "Groceries") | Groceries |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses critical deduplication logic ('each ingredient is only added once') and default list behavior ('Defaults to the Groceries list'). Missing error handling behavior and return value description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences with zero waste. First sentence establishes core purpose; second covers default behavior and deduplication. Information is front-loaded and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a 3-parameter tool with no output schema. Covers purpose, defaults, and deduplication. Deducted one point because it fails to clarify parameter relationships (whether recipe_names and recipe_ids are alternatives) and provides no return value information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage, establishing baseline 3. Description reinforces the default list value but does not add syntax details or clarify the relationship between 'recipe_names' and 'recipe_ids' parameters (mutually exclusive vs. complementary).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description provides specific verb ('Add'), resource ('ingredients from multiple recipes'), and scope ('at once'). The phrase 'multiple recipes' effectively distinguishes this from sibling tools 'add_ingredient_to_list' (singular) and 'add_recipe_ingredients_to_list' (likely single recipe).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies batch usage through 'at once' and 'multiple recipes', but does not explicitly state when to use this versus siblings like 'add_recipe_ingredients_to_list' or 'add_item_to_list'. No explicit exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a specific ingredient from a recipe to a shopping list. Matches existing items or recent items by name for proper AnyList categorization.
| Name | Required | Description | Default |
|---|---|---|---|
| recipe_name | No | Recipe name (case-insensitive match) | |
| recipe_id | No | Recipe identifier | |
| ingredient_name | Yes | Name of the ingredient to add (matched against recipe ingredients) | |
| list_name | No | Target list name (defaults to "Groceries") | Groceries |
| event_id | No | Meal plan event identifier to link this ingredient to | |
| event_date | No | Meal plan event date in YYYY-MM-DD format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden. It successfully explains the fuzzy matching behavior ('Matches existing items or recent items by name') and AnyList categorization system integration, adding valuable context beyond the schema. However, it omits whether the operation is idempotent, what happens if the ingredient isn't found in the recipe, or return value details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first front-loads the core action and scope, while the second adds essential behavioral context about the matching algorithm. Every word earns its place; no redundancy or filler present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 100% schema coverage and the tool's moderate complexity (6 parameters with interrelationships), the description adequately covers the essential operational logic and matching behavior. Minor gap: no output schema exists, and the description doesn't indicate return values or success/failure signaling, though this is partially mitigated by the straightforward 'add' operation pattern.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, establishing a baseline of 3. The description adds semantic value by clarifying the relationship between parameters—specifically that 'ingredient_name' is matched against recipe ingredients and sourced from the recipe identified by 'recipe_name'/'recipe_id'. This contextual linkage exceeds the raw schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('Add'), resource ('specific ingredient'), source ('from a recipe'), and target ('shopping list'). The use of 'specific ingredient' effectively distinguishes this singular operation from sibling tools 'add_ingredients_to_list' (plural) and 'add_recipe_ingredients_to_list' (bulk), while 'from a recipe' differentiates it from 'add_item_to_list' (generic items).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'from a recipe,' suggesting it requires recipe context, but lacks explicit guidance on when to use this versus 'add_recipe_ingredients_to_list' (all ingredients) or 'add_item_to_list' (manual entry). No alternatives or prerequisites are explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a freeform item to a shopping list. Checks for duplicates before adding.
| Name | Required | Description | Default |
|---|---|---|---|
| item_name | Yes | Name of the item to add | |
| list_name | Yes | Name of the list to add to | |
| quantity | No | Quantity string, e.g. "2 lbs" or "3" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It successfully documents the duplicate-checking behavior, but omits other critical mutation details such as error handling when lists don't exist, authentication requirements, or what constitutes a duplicate match.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two highly efficient sentences with zero waste. The first sentence establishes purpose immediately, while the second adds behavioral context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 flat parameters, 100% schema coverage, no output schema), the description is adequately complete. It covers core functionality and key behavior (duplicate checking). Minor gaps remain regarding error conditions and return values, but these are less critical for a straightforward mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already comprehensively documents all parameters including quantity examples. The description adds minimal semantic value beyond the schema, though 'freeform' slightly clarifies the item_name parameter's nature. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Add'), resource type ('freeform item'), and target ('shopping list'). The term 'freeform' effectively distinguishes this tool from sibling tools like 'add_ingredients_to_list' and 'add_recipe_ingredients_to_list' which imply structured data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance through the 'freeform' designation, suggesting use for arbitrary text items rather than structured ingredients. However, it lacks explicit when-to-use guidance or named alternatives (e.g., 'use this instead of add_ingredients_to_list when items are not from a recipe').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule a recipe or titled event on a specific day in the meal plan calendar.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | Date in YYYY-MM-DD format | |
| recipe_name | No | Recipe name to schedule (case-insensitive match) | |
| recipe_id | No | Recipe identifier for exact lookup | |
| title | No | Event title (used if no recipe specified, or as override) | |
| label | No | Meal label, e.g. "Breakfast", "Lunch", "Dinner" (case-insensitive match) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the core action ('Schedule'). It lacks disclosure of mutation behavior (does it overwrite existing events?), validation rules (must recipe exist first?), or idempotency characteristics critical for a calendar scheduling tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero waste. Key verb 'Schedule' front-loaded, followed by content options and location. Every word serves a distinct purpose in conveying the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with complex conditional logic (recipe_id/name vs title) and no output schema or annotations, the description is incomplete. It omits success/failure behaviors, return value structure, and whether the operation is idempotent or destructive—essential context for calendar mutation operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing baseline 3. The description adds high-level mapping ('recipe or titled event') that clarifies the parameter grouping logic, but doesn't add syntax details, format examples, or validation constraints beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Schedule' with clear resource 'meal plan calendar' and distinguishes content types ('recipe or titled event'). It effectively differentiates from sibling 'add_*_list' tools by using domain-specific terminology ('schedule' vs 'add', 'calendar' vs 'list').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use recipe_id vs recipe_name vs title, nor when to use get_meal_plan first to check existing events. The parameter relationships (mutually exclusive options) are undocumented, leaving agents to infer from schema descriptions alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add all ingredients from a single recipe to a shopping list. Defaults to the "Groceries" list. Checks for duplicates: skips items already on the list, unchecks previously checked-off items.
| Name | Required | Description | Default |
|---|---|---|---|
| recipe_name | No | Recipe name (case-insensitive match) | |
| recipe_id | No | Recipe identifier | |
| list_name | No | Target list name (defaults to "Groceries") | Groceries |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and successfully discloses key behavioral traits: the duplicate-checking logic (skips existing, unchecks checked-off items) and default list targeting. It could be improved by mentioning error conditions or what happens if both recipe_name and recipe_id are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences with zero waste: first establishes the core action, second covers defaults, third explains behavioral specifics (duplicate handling). Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple flat schema with 3 parameters and no output schema, the description is nearly complete. It covers the primary function, default behavior, and side effects. Minor gap: it does not clarify the logical requirement that at least one of recipe_name or recipe_id must be provided (since both are marked optional in the schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing detailed descriptions for all three parameters (recipe_name, recipe_id, list_name). The description reinforces the default 'Groceries' behavior but does not add significant semantic meaning beyond what the schema already provides, which is appropriate given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (Add), source (all ingredients from a single recipe), and target (shopping list). It effectively distinguishes from siblings like 'add_ingredient_to_list' and 'add_item_to_list' by specifying the recipe-to-list workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case through 'from a single recipe' and mentions the default 'Groceries' list, providing clear context. However, it does not explicitly state when to use this versus 'add_ingredients_to_list' or clarify that at least one recipe identifier (name or ID) must be provided since both are optional in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all items on a specific shopping list.
| Name | Required | Description | Default |
|---|---|---|---|
| list_name | Yes | Name of the list to retrieve items from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, the description lacks critical details: return format, behavior when list_name doesn't exist, or whether results are paginated for large lists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at 7 words in a single sentence. No filler words or redundant information. Immediately front-loaded with the action and target resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read operation, the description meets minimum viability but has clear gaps. Without an output schema or annotations, it should at least mention error conditions (e.g., list not found) or return value structure to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents the list_name parameter. The description adds minimal semantic value beyond the schema, merely referencing a 'specific shopping list' without adding format constraints, examples, or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('items on a specific shopping list'). It implicitly distinguishes from sibling 'get_lists' by specifying 'items' versus lists, though it could explicitly clarify this distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives like 'get_lists' (which retrieves the lists themselves). Does not mention prerequisite steps like obtaining the list_name or error handling if the list doesn't exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all shopping lists in the AnyList account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. While 'List' implies a read-only operation, the description lacks crucial behavioral details: authentication requirements, rate limits, pagination behavior, or the structure/format of the returned list data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of eight words with zero redundancy. Information is front-loaded and every word serves a purpose in defining scope and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple parameterless tool, but gaps remain: without an output schema, the description should ideally specify what list attributes are returned (IDs, names, metadata). However, given the low complexity, it meets minimum viability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, which establishes a baseline score of 4 per evaluation guidelines. The description appropriately signals no filtering capabilities by stating 'all' lists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'List' with clear resource 'shopping lists' and scope 'in the AnyList account'. It effectively distinguishes from sibling 'get_list_items' by specifying 'all shopping lists' (plural, account-level) versus items within a specific list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the name and description (use when you need to retrieve all lists), but there are no explicit when-to-use guidelines, prerequisites, or contrasts with alternatives like 'get_list_items'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get meal plan events for a date range. Defaults to the current week (Mon-Sun). Use a 6-week lookback (e.g. start_date 6 weeks ago) to understand recent eating patterns when recommending new meals.
| Name | Required | Description | Default |
|---|---|---|---|
| start_date | No | Start date in YYYY-MM-DD format (defaults to this Monday) | |
| end_date | No | End date in YYYY-MM-DD format (defaults to this Sunday) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses default date range behavior (Mon-Sun). However, lacks disclosure of rate limits, empty result behavior, or data freshness guarantees expected for a read tool with no safety annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences optimally structured: purpose first, defaults second, usage recommendation third. No redundancy or filler; every sentence earns its place with actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter read tool with 100% schema coverage, description adequately covers purpose, defaults, and usage patterns. Minor gap: does not describe return value structure (though no output schema exists to reference).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds semantic value by framing defaults as 'current week (Mon-Sun)' and providing concrete usage pattern 'start_date 6 weeks ago' that illustrates how to construct date ranges for pattern analysis.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Get' + resource 'meal plan events' + scope 'date range'. Clearly distinguishes from sibling 'add_meal_plan_event' (mutator vs reader) and 'get_recipes' (events vs recipes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit positive guidance: 'Use a 6-week lookback... to understand recent eating patterns when recommending new meals.' Includes concrete example (6 weeks). Does not explicitly name alternatives to avoid, but clear differentiation from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details of a specific recipe including ingredients and preparation steps. Look up by name or ID.
| Name | Required | Description | Default |
|---|---|---|---|
| recipe_name | No | Recipe name to look up (case-insensitive partial match) | |
| recipe_id | No | Recipe identifier for exact lookup |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It compensates partially by disclosing return content (ingredients, preparation steps) since no output schema exists. However, it omits safety properties (read-only), error behavior (not found), and whether partial name matches return single or multiple results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficiently structured sentences with zero waste. First sentence front-loads the action and return value; second covers parameter usage. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for tool complexity. Without an output schema, the description usefully enumerates what 'details' include (ingredients, steps). Could improve by noting error cases or search behavior, but adequate for a simple lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage (case-insensitive partial match vs exact lookup), establishing baseline 3. Description reinforces the lookup methods ('name or ID') but adds no additional semantic context beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb (Get) + resource (recipe details) and scope (ingredients, preparation steps). Implicitly distinguishes from sibling 'get_recipes' by specifying 'specific recipe' and 'full details', though it doesn't explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides lookup method guidance ('Look up by name or ID'), implying the two identification options. However, lacks explicit when-to-use guidance versus 'get_recipes' and doesn't clarify that at least one parameter is required despite the schema showing zero required fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all saved recipes from the AnyList account. Returns name, rating, cook time, prep time, and servings for each recipe. Use the optional search parameter to filter by name.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Optional text to filter recipes by name (case-insensitive) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing what the tool returns, specifically listing the output fields (name, rating, cook time, etc.) to compensate for the missing output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences with zero waste: purpose declaration, return value disclosure, and parameter usage guidance. Information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool (1 optional parameter, no nesting), the description is complete. It adequately compensates for missing annotations and output schema by describing return values, though explicit differentiation from get_recipe_details would strengthen it further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description mentions the optional search parameter but adds minimal semantic meaning beyond the schema's existing description of 'Optional text to filter recipes by name (case-insensitive)'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('saved recipes from the AnyList account'), clearly distinguishing it from sibling tools like get_recipe_details (singular details) and get_lists (shopping lists).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides implied usage by explaining the search parameter's purpose, but lacks explicit guidance on when to use this bulk listing tool versus get_recipe_details for detailed single-recipe retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0add_ingredient_to_listadd_ingredients_to_listadd_item_to_listadd_meal_plan_eventadd_recipe_ingredients_to_listget_list_itemsget_listsget_meal_planget_recipe_detailsget_recipesThere is significant overlap between tools like add_ingredients_to_list, add_ingredient_to_list, add_recipe_ingredients_to_list, and add_item_to_list, which all add items to shopping lists with subtle distinctions that could confuse an agent. However, the descriptions provide some clarity on their specific use cases, such as handling multiple recipes versus single recipes versus freeform items.
All tool names follow a consistent verb_noun pattern with snake_case, such as add_ingredients_to_list, get_list_items, and get_meal_plan. This predictability makes it easy for an agent to understand and navigate the tool set without confusion.
With 10 tools, the server is well-scoped for managing shopping lists, recipes, and meal plans. Each tool serves a distinct purpose within this domain, and the count is neither too sparse nor overwhelming, fitting typical server ranges of 3-15 tools.
The tool set covers core operations for shopping lists (add, get), recipes (get details, list), and meal plans (add events, get plan), with minor gaps such as missing update or delete functions for items, lists, or recipes. Agents can likely work around these omissions, but they represent a slight limitation in lifecycle coverage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search, save, organize, cook, and share recipes with any AI assistant.
AI-powered kitchen management — pantry, recipes, meal plans, shopping lists
Household-aware cooking brain: pantry, meal suggestions, dietary safety, recipes, shopping lists.
Manage Superlist tasks and lists in plain language from any MCP-compatible AI agent.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/davidashman/anylist-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
