How do I use Meal Planner MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Meal Planner MCP Plan a week of meals using my recipes and generate a shopping 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.

Meal Planner MCP

by illinigirl

Overview Schema Source Related Servers Discussions Admin

Python

Local

Meal Planner MCP

A self-contained MCP server that plans a week of meals from a local recipe library — optimizing for shared ingredients, reusing leftovers, and avoiding recent repeats — then generates a consolidated shopping list and a Markdown plan you can stick on the fridge.

No cloud, no API keys, no database. Clone it and it runs.

python3 -m venv .venv && source .venv/bin/activate    # isolate deps
pip install -e ".[test]" && pytest -q                 # 76 tests
python -m mealplanner.cli plan --days 7               # try the planner
python -m mealplanner.cli shopping                    # and the shopping list

Example

It ships with a seed library, so it plans the moment you clone it — no data entry. The planner optimizes for ingredient overlap across the week, then consolidates everything into one deduplicated shopping list:

$ python -m mealplanner.cli plan --days 5

Plan for 5 days (household 4):

  2026-06-05   Veggie Fried Rice  (serves 4)
  2026-06-06   Chicken Stir-Fry  (serves 4)
  2026-06-07   Sheet-Pan Chicken & Peppers  (serves 4)
  2026-06-08   Poached Eggs in Tomato Sauce  (serves 4)
  2026-06-09   Chickpea & Spinach Stew  (serves 4)

$ python -m mealplanner.cli shopping

Shopping list:

  [ ] 5  bell pepper
  [ ] 2 can  canned tomato
  [ ] 2 pound  chicken breast
  [ ] 11 clove  garlic
  [ ] 6 tablespoon  soy sauce
  …

The MCP tools run the same logic — plan_week then generate_shopping_list — so in Claude Desktop you just ask for it in plain language.

Related MCP server: yes_chef_mcp

In Claude Desktop

Wired in as a local MCP server, Claude discovers the tools and drives them from a plain-language ask — here it picks up plan_week, calls it with days: 5, then explains the result and offers next steps:

Claude discovering the meal-planner MCP tools and calling plan_week with days=5

The resulting 5-day plan, with Claude explaining the ingredient-overlap optimization and offering to swap a day or build the shopping list

Why an MCP (and not just asking Claude)?

A tool only earns its place if it does something the model can't. This one clears that bar on four counts — which is the whole reason it exists:

Ask	Plain Claude	This server
"Suggest a sci-fi… er, a pasta dish"	✅ fine on its own	(a tool adds nothing)
"Plan around my recipes"	❌ doesn't know them	✅ grounded in your local library
"Don't repeat what we ate last week"	❌ no memory across chats	✅ persistent history file
"Give me a plan + list I can keep"	❌ can't write files	✅ Markdown export
"Merge 1 + 2 + ½ onion across 4 recipes, scaled to 6"	❌ hand-waves the math	✅ exact, deterministic

The model does the creative part (which week feels good); the server supplies the private data, the memory, the persisted artifact, and the exact arithmetic.

What it does

plan_week — greedy optimizer: picks recipes that share the most ingredients with what's already chosen, skips anything cooked recently, and fills extra nights from serving-surplus leftovers (a batch of chili that serves 8 covers two dinners for a family of four). The overlap objective rewards similar recipes, so it clusters same-protein nights by design; diversity_weight (off by default) dials in variety vs. waste.
swap_meal / remove_meal — iterate per day: "put tacos on Tuesday," "skip Thursday." The plan, shopping list, and export all update with you. ("Make Friday quicker" needs no new tool — Claude calls suggest_recipes then swap_meal.)
generate_shopping_list — merges and scales ingredients across the plan's cook days, deduped, with no silent unit conversion.
export_plan — writes the week + shopping list and returns it inline (so a remote caller who can't read the server's disk still gets it). format="markdown" (table + checklist, renders in Claude and note apps) or "text" (plain text for pasting into Notes / Reminders). With no path it writes to a known location under the data dir (not the process cwd, which is unpredictable when Claude Desktop launches the server).
set_course — recategorize a recipe (mark a stray import as a Sauce so it stops landing in dinner slots). Curation; the planner relies on this normalized field, never on title guessing.
suggest_recipes / list_recipes / get_recipe — query the library.
record_cooked — log what you actually made; this is the memory that powers avoid-repeats.
add_recipe — save one recipe from free text. The everyday way to build your library — no file or format needed.
add_recipes — bulk-add a whole batch in one call: the fast way to build a starter library with no Plan to Eat export. Generate a batch from your tastes, review it, and save them all at once (Claude generates; the tool just persists).
import_recipes — optional bulk shortcut for an existing Plan to Eat export: by csv_path (a file on the server — local use) or csv_content (pasted CSV text — works for a remote caller with no server-disk access). Offline, no scraping.

Seeding your library

Four ways, none requiring any particular app or format:

Just start — 16 recipes ship in data/recipes.seed.json, so it plans a week the moment you clone it.
Add as you go (the normal path) — paste or describe a recipe in chat; Claude structures it and calls add_recipe. "Save my chili: 2 lb ground beef, an onion, 2 cans tomatoes, kidney beans, chili powder — serves 8." No CSV, no schema.
Generate a starter set (no export needed) — don't want to add them one by one? Ask Claude to generate a batch from your tastes — "25 quick weeknight dinners I'd like, mostly vegetarian" — review it, and it saves them all in one add_recipes call. The planner optimizes over recipes you'll actually cook, so keep the batch to food you'd really make rather than generic filler.
Bulk migrate (optional) — already have a Plan to Eat export? import_recipes loads it in one offline pass. It's a convenience, not a requirement — and adding other formats (Paprika, Mealie, plain JSON) is a documented seam.

Architecture

Pure core + thin adapters. All the logic is I/O-free and unit-tested without a runtime; the MCP server and the CLI are two adapters over the same functions, and one module does all the file I/O.

src/mealplanner/
  models.py       Recipe · Ingredient · HistoryEntry · PlanDay
  ingredients.py  parse free text → {qty,unit,item} · canonicalize · aggregate   (pure)
  core.py         library search · overlap scoring · avoid-repeats               (pure)
  planner.py      greedy week optimizer (overlap + leftovers + avoid-repeats)    (pure)
  exports.py      shopping-list build · Markdown render                          (pure)
  store.py        JSON persistence · Plan to Eat CSV import          (the only I/O)
  server.py       MCP adapter (FastMCP)
  cli.py          CLI adapter
data/recipes.seed.json   bundled starter library (clones-and-runs)

The bundled seed ships in the repo; your mutable state (history, plans, imported recipes) lives in a gitignored state.json under ~/.meal-planner/ — so your real recipes never land in a commit.

Use it from Claude

The server runs over two transports from one codebase — stdio for a local Claude Desktop subprocess, or streamable-HTTP so it can be added as a remote custom connector by URL.

Local (stdio) — Claude Desktop. Clone, make a virtualenv, and install — the install puts a meal-planner console script inside .venv/bin:

git clone https://github.com/illinigirl/meal-planner-mcp
cd meal-planner-mcp
python3 -m venv .venv && source .venv/bin/activate
pip install -e .

Then point your claude_desktop_config.json at that script (absolute path), and restart Claude Desktop — the meal-planner tools will appear:

{
  "mcpServers": {
    "meal-planner": {
      "command": "/absolute/path/to/meal-planner-mcp/.venv/bin/meal-planner"
    }
  }
}

As a custom connector (HTTP). Run it as an HTTP server and point a connector at the URL:

meal-planner --http --port 8765          # or MEAL_PLANNER_HTTP=1
# then add http://localhost:8765/mcp as a custom connector

(For a remote connector — claude.ai / mobile — host it behind a public HTTPS URL with auth, the same way a production MCP deployment would.)

Then just talk: "Plan us 7 dinners this week, nothing we had recently, keep weeknights under 30 minutes — then give me the shopping list." — and iterate: "swap Tuesday for something vegetarian," "skip Thursday."

For reviewers — drive it with Claude Code

It's built to be worked in by an agent. Good first tasks, easiest first:

Run the tests — pip install -e ".[test]" && python -m pytest -q (75; the pure-core subset runs on stdlib alone, the tool-layer tests use the MCP SDK).
Improve the ingredient parser to handle 1 (14 oz) can tomatoes — see ingredients.parse_ingredient and add a test.
Add leftover mode B (cook-once-eat-twice): give recipes produces/uses tags so roast chicken → chicken soup chains. The seed already has both recipes waiting.
Add an explicit unit-conversion table (3 tsp → 1 tbsp) — but only convert when asked, never silently.

CLAUDE.md is the orientation file: architecture, conventions, design rationale, and every deliberate simplification (each one a place to extend).

License

MIT.

Available Tools

14 tools

add_recipeB

Save one recipe to your library — the everyday way to seed it.

No file or special format needed: paste or describe a recipe and let Claude fill these fields in. ingredients is a list of free-text lines ("1 cup flour", "2 cloves garlic", "salt to taste") — each is parsed into a structured amount so it can feed the shopping-list math.

Set course ("Dinner", "Sauce", "Side", "Dessert", …) so the planner knows whether this is a dinner anchor — you know a sauce from a main; pass it along. Omit it and it's treated as a main.

ParametersJSON Schema

Name	Required	Description	Default
`tags`	No
`title`	Yes
`course`	No
`cuisine`	No
`servings`	No
`directions`	No
`ingredients`	Yes
`total_time_min`	No

TDQS

B3.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that ingredients are parsed into structured amounts for shopping-list math, and that setting 'course' affects planning. Since no annotations are provided, the description carries the full burden, but it does not mention whether the operation is safe, reversible, or has any side effects beyond saving. This is adequate for a simple creation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise at about four lines, with the main purpose front-loaded. Every sentence adds value, though 'the everyday way to seed it' is slightly informal but acceptable. No unnecessary repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 8 parameters and no output schema, the description should hint at the return value or success confirmation. It only says 'Save one recipe to your library' without mentioning what the agent should expect after invocation. Error conditions are also absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate. It explains two critical parameters: 'ingredients' (format and parsing) and 'course' (influence on planning). It also mentions 'servings' default. However, other parameters like 'tags', 'cuisine', 'directions', and 'total_time_min' receive no explanation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's verb and resource: 'Save one recipe to your library'. It distinguishes from siblings by implying this is for adding a single recipe ('the everyday way to seed it'), while a sibling named 'add_recipes' likely handles bulk addition. However, it does not explicitly contrast with alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description says 'No file or special format needed: paste or describe a recipe', suggesting it is for simple, manual input. But it provides no explicit guidance on when to use this tool versus siblings like 'add_recipes' (which may handle bulk imports). No when-not scenarios are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

add_recipesA

Bulk-add many recipes in one call — the fast way to build a starter library when you DON'T have a Plan to Eat export to import.

The intended flow: generate a batch tailored to the user's tastes (their cuisines, constraints, what they actually cook — don't just produce generic recipes they won't make), let them review it, then save the batch here. The planner only earns its keep over recipes the user genuinely likes.

Each item: {"title": str, "ingredients": [free-text lines], plus optional "servings", "tags", "total_time_min", "cuisine", "course", "directions"}. Ingredient lines are parsed like add_recipe so they feed the shopping-list math. Items missing a title or ingredients are skipped (and reported); ids are de-duplicated against the library and within the batch. One state write for the whole batch. Returns the saved recipes + counts.

ParametersJSON Schema

Name	Required	Description	Default
`recipes`	Yes

TDQS

A5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses item skipping for missing title/ingredients, de-duplication, single state write, and return structure. No annotations present, so description carries full burden.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Efficiently structured with purpose, flow, and details; each sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Comprehensively covers purpose, usage, item format, error handling, and return value despite no output schema or annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Adds detailed field descriptions (title, ingredients, optional fields) and behavior (parsing, de-duplication) beyond the minimal schema, which has 0% coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Bulk-add many recipes in one call' with specific use case (building a starter library) and distinguishes from sibling tools like add_recipe and import_recipes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Describes when to use (no Plan to Eat export) and the intended flow (generate, review, save), with explicit exclusions and alternative tool mention.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

export_planA

Write the current plan + shopping list AND return the rendered content inline.

format: "markdown" (default — renders as a table + checklist in Claude and note apps) or "text" (plain text for pasting into Notes / Reminders / a text message). With no path, writes to a known location under the data dir (MEAL_PLANNER_DATA_DIR/meal-plans/.{md,txt}) — not the process cwd, which is unpredictable when Claude Desktop launches the server. The content field is always returned, so a remote caller who can't read the server's disk still gets the result to display or save client-side.

ParametersJSON Schema

Name	Required	Description	Default
`path`	No
`format`	No		markdown

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that writing occurs to a known location under MEAL_PLANNER_DATA_DIR, not the process cwd, and that content is always returned. This is good transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with a bullet for format, front-loads the main action, and is mostly concise. A minor reduction for slight verbosity but still effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with two optional parameters and no output schema, the description covers side effects (file writing), default behavior, and return value. It lacks edge cases or error handling, but is sufficient for this simple export tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description adds meaning: it explains the 'format' parameter values ('markdown' vs 'text') and their effects, and clarifies that 'path' is optional with default behavior. It compensates well for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool writes the current plan and shopping list and returns rendered content inline. This distinguishes it from siblings like 'get_current_plan' and 'generate_shopping_list'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the format parameter and default path behavior, implying when to use the tool. However, it does not explicitly mention when not to use it or provide alternatives, leaving some ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

generate_shopping_listA

Consolidated shopping list for the current plan — ingredients merged and scaled across cook days (leftover nights add nothing). Deterministic math, not an LLM estimate.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that the output is deterministic and not LLM-generated, and that leftover nights add nothing. However, it does not mention potential error states (e.g., no current plan) or output format, and no annotations 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long, front-loaded with the core purpose, and every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's core functionality and behavioral traits adequately for a parameterless tool. It does not explain prerequisites like having a plan, but that is implied by 'current plan' and sibling tool context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, and schema coverage is 100%. The baseline for zero parameters is 4, and the description does not need to add parameter info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool generates a consolidated shopping list for the current plan, merging and scaling ingredients across cook days. It distinguishes itself from sibling tools that deal with recipes, planning, or exporting.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage after planning is done, but lacks explicit when-to-use or when-not-to-use guidance or alternatives. The context suggests it is used when a shopping list is needed, which is reasonably clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_current_planC

The currently saved plan, if any.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

C2.8/5.0

Behavior1/5

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 does not state what happens when no plan exists (e.g., returns null or throws error), nor any side effects. The description is too minimal to provide meaningful transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, using only one short phrase. It is front-loaded with the key information. While it could include more detail, it earns its place by being directly informative for a simple retrieval tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no complexities (0 params, no output schema, no annotations), the description lacks completeness. It does not explain the return value's structure or content (e.g., meal plan details), nor potential edge cases. A user cannot fully understand what to expect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, and schema coverage is 100% trivially. The description does not need to add parameter details. It provides adequate context that the tool requires no inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'The currently saved plan, if any' clearly indicates that the tool retrieves a saved plan, and the name 'get_current_plan' reinforces this. It is specific enough to distinguish from sibling tools like 'plan_week' or 'export_plan', though it does not explicitly differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or context. For example, it does not clarify if a plan must exist or if this tool should be used before generating a shopping list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_recipeB

Full detail for one recipe, including its ingredient list.

ParametersJSON Schema

Name	Required	Description	Default
`recipe_id`	Yes

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must disclose all behavioral traits. Only states it returns 'full detail' including ingredients, but does not mention any side effects, authentication requirements, rate limits, or what 'full detail' entails beyond ingredients. Minimal behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence of 9 words is highly concise. Front-loaded with key action and scope. However, it is too brief and could benefit from additional structure or details without being verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and minimal annotations, description should provide more details about return value structure or behavior. Merely stating 'full detail' and 'ingredient list' is insufficient for an agent to fully understand the output. Lacks completeness for a simple retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has one required string parameter 'recipe_id' with 0% description coverage. Description does not explain the parameter, its format, or how to obtain it. The tool name implies the parameter is a recipe identifier, but no explicit semantics added.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool retrieves full detail for one recipe, including ingredient list. Verb 'get' and resource 'recipe' are specific. Distinguishes from siblings like 'list_recipes' (which returns multiple) and 'suggest_recipes' (which suggests based on criteria).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance. Implicitly, it is for retrieving details of a single recipe, as opposed to listing or suggesting. However, no alternatives mentioned, and no context on when to choose this over other recipe-related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

import_recipesA

Optional bulk shortcut: import many recipes from a Plan to Eat CSV export. Most users seed with add_recipe instead.

csv_path reads a file on the SERVER's filesystem (local use). csv_content takes the CSV text directly — use this from a remote client that can't reach the server's disk (paste the export's contents).

ParametersJSON Schema

Name	Required	Description	Default
`csv_path`	No
`csv_content`	No

TDQS

A4.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavioral traits. It explains the two parameters and their usage but does not disclose side effects (e.g., whether it overwrites existing recipes, handles duplicates, or any destructive behavior). The description is moderately transparent but lacks details on the overall operation's impact.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with four sentences, front-loading the purpose and then detailing parameter usage. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has two optional parameters and no output schema, the description adequately covers usage and parameter semantics. However, it does not mention what happens after import (e.g., error handling, return values), leaving some context incomplete for a comprehensive understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by explaining the two parameters: csv_path for reading a server file, csv_content for pasting CSV text from a remote client. This adds critical meaning beyond the schema's type definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it imports many recipes from a Plan to Eat CSV export, specifying it as an optional bulk shortcut. It distinguishes itself from the sibling add_recipe by noting that most users seed with add_recipe instead, making the purpose specific and distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance: it contrasts with add_recipe for single entries and advises using add_recipe instead for most users. It also explains the two methods of providing CSV data (server file vs. direct content), giving clear context for each scenario.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_recipesA

List recipes in the library (bundled seed + your imported/added recipes).

Args: tag: optional tag filter (e.g. "vegetarian", "quick"). max_time: optional max total time in minutes.

ParametersJSON Schema

Name	Required	Description	Default
`tag`	No
`max_time`	No

TDQS

A3.7/5.0

Behavior2/5

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 does not mention that the tool is read-only, nor does it describe any side effects, pagination, ordering, or rate limits. The description only states the basic function, missing critical behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences plus a parameter list. No unnecessary words, and the key information is front-loaded. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no output schema, the description should ideally mention what is returned (e.g., list of recipe IDs or full objects). This is missing. However, with only two optional params and a simple purpose, the description covers the essential usage adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must add meaning. It clearly describes both parameters: 'tag' as an optional filter (with examples) and 'max_time' as max total time in minutes. This adds significant clarity beyond the bare schema properties.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool lists recipes from the library (bundled seed + imported/added), clearly distinguishing it from siblings like get_recipe (single recipe) or add_recipe (adding). The verb 'list' is specific and the scope is well-defined.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing and filtering recipes via optional parameters, but it does not explicitly state when to use this tool over alternatives like suggest_recipes or get_current_plan. No 'when not to use' or alternative recommendations are provided, leaving the agent to infer context from sibling names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

plan_weekA

Build and save a meal plan, optimizing ingredient overlap, reusing serving-surplus leftovers, and avoiding recently-cooked recipes.

main_course_only (default true) keeps sauces/sides/desserts out of dinner slots. diversity_weight (default 0 = off) trades waste for variety: the overlap objective rewards similar recipes, so it clusters same-protein nights; a weight > 0 penalizes repeating a protein within the week. Saves as the current plan; tweak with swap_meal / remove_meal or re-call with new constraints. generate_shopping_list / export_plan use it.

ParametersJSON Schema

Name	Required	Description	Default
`days`	No
`max_time`	No
`start_date`	No
`exclude_tags`	No
`include_tags`	No
`household_size`	No
`diversity_weight`	No
`main_course_only`	No
`avoid_recent_days`	No

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Explains key behaviors: saves as current plan, reuses leftovers, avoids recently-cooked recipes, optimizes overlap and diversity. Does not mention overwriting behavior but implies it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with clear paragraphs, front-loads main purpose. Detailed but not verbose. Could be slightly more concise but effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has 9 parameters, no output schema, no annotations. Description leaves many parameters unexplained (7/9). No mention of return value or success behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%. Only main_course_only and diversity_weight are explained in detail. Other 7 parameters (days, max_time, start_date, exclude_tags, include_tags, household_size, avoid_recent_days) are not described.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states 'Build and save a meal plan' with specific optimization goals (ingredient overlap, leftovers). Distinguishes from sibling tools like swap_meal, remove_meal, generate_shopping_list, export_plan.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly describes when to use (build and save a meal plan) and mentions alternatives for tweaking (swap_meal, remove_meal) or re-calling. Lacks explicit 'when not to use' but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

record_cookedA

Log that you actually cooked a recipe (defaults to today). This is the cross-session memory that powers avoid-repeats — what plain Claude can't do.

ParametersJSON Schema

Name	Required	Description	Default
`on_date`	No
`recipe_id`	Yes

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It adds context about cross-session memory and avoid-repeats but does not disclose idempotency, side effects on other data, or whether it overwrites previous logs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no wasted words. The second sentence adds valuable context about cross-session capability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple logging tool with 2 params and no output schema, the description covers purpose and behavioral context. Could mention return value but acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description mentions 'defaults to today' for on_date but does not explain recipe_id. The schema default is null, not today, which may be misleading. Minimal addition beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the action (log cooking), the resource (recipe), and default behavior (today). It also distinguishes by mentioning cross-session memory and avoid-repeats, differentiating it from sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage after cooking a recipe but lacks explicit guidance on when not to use or alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

remove_mealA

Clear one day of the current plan (eating out, skipping). The date stays as an unplanned slot.

ParametersJSON Schema

Name	Required	Description	Default
`date`	Yes

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavioral traits. It states that the date remains as an unplanned slot after clearing, which is helpful. However, it does not mention if the operation is reversible, if it requires specific permissions, or what happens if the date does not exist in the plan.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core action, and contains no superfluous information. Every word serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description is incomplete for a tool with a single required parameter that likely expects a specific date format. It also does not clarify behavior for invalid or missing dates, leaving the agent uncertain about edge cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'date' lacks any format or example in the description. With 0% schema description coverage, the description should have specified the expected date format (e.g., ISO 8601) to ensure correct usage. This is a significant gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: clearing one day's meal from the current plan, leaving it unplanned. The verb 'clear' and resource 'one day of the current plan' are specific, and it distinguishes from siblings like 'swap_meal' or 'add_recipe' which modify or add rather than remove.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context hints ('eating out, skipping') suggesting when to use, but does not explicitly contrast with alternatives like 'swap_meal' or specify when not to use. The scenarios are implied rather than stated as guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

set_courseA

Recategorize a recipe's course — curation for imports that came in uncategorized (e.g. mark a sauce as "Sauce" so it stops landing in dinner slots). Only your own/imported recipes are editable; seed recipes are read-only.

ParametersJSON Schema

Name	Required	Description	Default
`course`	Yes
`recipe_id`	Yes

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, so description carries full burden. It discloses the action (recategorize) and a key constraint (seed recipes read-only). However, it doesn't describe error behavior or side effects beyond the scope.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no wasted words. Main action is front-loaded, and additional context follows efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple mutation with no output schema, the description covers the primary use and constraints. Missing return value info but acceptable given tool simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description does not elaborate on individual parameters. 'recipe_id' and 'course' are mentioned only in context, lacking specific format, allowed values, or examples.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'Recategorize' and resource 'recipe's course', with a concrete use case ('curation for imports that came in uncategorized'). Clearly distinguishes from sibling tools like import_recipes or list_recipes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: for own or imported recipes that need categorization. Also specifies constraint: seed recipes are read-only. Could mention alternatives but overall clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

suggest_recipesA

Candidate recipes matching constraints — the grounding step before you decide a week. Returns recipes from YOUR library (the thing base Claude can't see), filtered by time/tags/ingredients.

ParametersJSON Schema

Name	Required	Description	Default
`max_time`	No
`exclude_tags`	No
`include_tags`	No
`include_ingredients`	No

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It discloses that the tool accesses the user's private library and filters results, but does not detail rate limits, authentication, or what happens on empty results. Adequate but could be more explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two efficient sentences with no wasted words. Front-loaded with the core purpose immediately, followed by qualifications. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 optional parameters, no output schema, and no annotations, the description provides good context about source (user's library) and filtering. Could mention behavior on no matches or return format, but overall sufficient for a suggestion tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (no descriptions). The description mentions filtering by time/tags/ingredients, which maps to the parameters, but does not specify formats (e.g., units for max_time, tag format). Minimal added value beyond the parameter names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'suggest' and resource 'recipes from YOUR library', and distinguishes it from base Claude's inability to see the library. It also frames it as the grounding step before planning a week, providing strong purpose clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly guides use as the grounding step before deciding a week and notes it returns recipes from the user's library (contrasting with base Claude). While it doesn't explicitly state when not to use or name alternatives, the context is sufficient for appropriate selection among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

swap_mealA

Replace one day of the current plan with a specific recipe — "put tacos on Tuesday instead." A literal per-day override (clears any leftover marking on that day). For "make Friday quicker", call suggest_recipes first, then swap.

ParametersJSON Schema

Name	Required	Description	Default
`date`	Yes
`recipe_id`	Yes

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden. It discloses that the tool 'clears any leftover marking on that day', indicating a side effect beyond a simple swap. However, it does not mention authentication, rate limits, or whether previous recipes are replaced permanently.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with zero wasted words. The core purpose is front-loaded, and the usage guideline is appended efficiently. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter mutation tool with no output schema or annotations, the description provides adequate context: purpose, side effect, and usage flow. It mentions clearing markings and references a sibling tool. Minor gap: no explanation of 'leftover marking' or return value, but overall sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description must compensate. The example implies date is a day (e.g., 'Tuesday') and recipe_id selects a specific recipe, adding meaning beyond bare schema titles. However, it does not specify expected formats (e.g., ISO date) or that recipe_id might require prior existence.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool replaces a meal on a specific day with a specific recipe, using a concrete example ('put tacos on Tuesday instead'). It distinguishes from siblings like suggest_recipes by explicitly calling it a 'literal per-day override' and contrasting it with the recommendation flow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance: use it to replace a day with a specific recipe, and if the goal is to make a day quicker, call suggest_recipes first. This clear when-to and when-not advice helps the agent decide correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

14 tool updatesv0.1.0Jul 6, 2026
- First observedadd_recipe
- First observedadd_recipes
- First observedexport_plan
- First observedgenerate_shopping_list
- First observedget_current_plan
- First observedget_recipe
- First observedimport_recipes
- First observedlist_recipes
- First observedplan_week
- First observedrecord_cooked
- First observedremove_meal
- First observedset_course
- First observedsuggest_recipes
- First observedswap_meal

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-07-06 00:35 across 14 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: adding recipes (single, bulk, CSV import), listing/getting recipes, planning (plan_week, swap_meal, remove_meal), generating shopping lists, exporting, and logging cooked meals. No two tools overlap in function.

Naming Consistency5/5

All tool names use a consistent snake_case verb_noun pattern (e.g., add_recipe, export_plan, record_cooked). The verbs are meaningful and predictably describe the action. No naming convention violations.

Tool Count5/5

14 tools cover the full meal planning workflow without being excessive. Each tool serves a specific need, from recipe management to weekly planning and shopping list generation.

Completeness3/5

Core planning operations are present, but there are gaps: no tool to update or delete user-added recipes (only add and read). This is a notable missing feature for a recipe library, though the planning cycle itself is complete.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Agent Chef AOAuth
net.agentchef
Family meal planning run by your agent: weekly dinners, household votes, grocery list minus pantry.
Autonomous Agents App Automation
1
pantry-aideOAuth
com.pantryaide
AI meal plans that fill your Kroger/Instacart cart - pantry-aware lists, all from chat.
E-commerce & Retail Health & Wellness
2
Scraps KitchenOAuth
io.github.mitchmolstad
Household-aware cooking brain: pantry, meal suggestions, dietary safety, recipes, shopping lists.
Home Automation & IoT Health & Wellness App Automation
2
Pantry PersonaOAuth
com.pantrypersona
AI-powered kitchen management — pantry, recipes, meal plans, shopping lists
Home Automation & IoT Health & Wellness E-commerce & Retail
2

Related MCP Servers

Gamito
Health & Wellness
nerkyzas157
F
license
B
quality
D
maintenance
Enables AI agents to generate budget-disciplined, allergy-safe weekly meal plans, shopping lists, and meal swaps using a fully local deterministic engine.
Updated 3 months ago (2026-06-14 14:57 UTC)
20
-
yes_chef_mcp
Health & Wellness Search
ltmorro
F
license
Not graded
quality
D
maintenance
Enables AI assistants to search recipes, compose nutritionally balanced meals, optimize weekly meal plans based on macro targets for family members, and generate consolidated grocery lists from a personal recipe database.
Updated 5 months ago (2026-04-05 23:31 UTC)
-
shelfwatch
E-commerce & Retail Web Scraping
Kronixion
A
license
Not graded
quality
C
maintenance
Enables automated weekly meal planning and grocery price comparison across Swedish supermarkets through a Claude/GPT interface.
Updated 5 months ago (2026-04-16 11:59 UTC)
3
MIT
mealforge
Health & Wellness
LooseWireDev
A
license
Not graded
quality
A
maintenance
Enables AI-driven weekly meal planning with structured recipes, cooking steps, and grocery lists.
Updated 2 months ago (2026-07-13 23:41 UTC)
1
MIT