mealie-mcp

add_to_meal_plan

Add a recipe to a meal plan by specifying its ID, date, and meal type (breakfast, lunch, dinner, or snack) to organize daily meals.

Instructions

Add a recipe to the meal plan for a date and meal.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "recipe_id": "<recipe_id>",
      "date": "<date>",
      "meal_type": "<meal_type>"
    },
    "name": "add_to_meal_plan"
  }
}

Input Schema

Name	Required	Description
`date`	Yes	Date in YYYY-MM-DD format
`meal_type`	Yes
`recipe_id`	Yes	The recipe ID to add

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 7, 2026

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are supplied, so the description carries the full behavioral burden. "Add" implies mutation, but nothing is said about duplicate handling (append vs replace), whether the slot can hold multiple recipes, permission requirements, or what is returned on success/failure — all material for a write tool against a meal plan.

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

Conciseness3/5

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

A single well-formed sentence with no wasted words, but its brevity is under-specification rather than efficiency — the front-loaded purpose is fine, yet a mutation tool warrants at least one more clause on effect.

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?

With no annotations, no output schema, and a three-required-parameter mutation, the description should explain the resulting state change and error conditions. It leaves the agent unable to predict what happens on a conflicting entry or whether the recipe must pre-exist.

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 67%: date format and recipe_id are documented in the schema, and meal_type's enum is self-explanatory. The description only restates "for a date and meal" and adds no meaning about constraints, defaults, or accepted recipe_id provenance beyond what the schema already gives.

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?

States a specific verb ("Add") and resource ("a recipe to the meal plan") plus the scoping dimensions (date and meal). It is clearly distinguishable from remove_from_meal_plan and get_meal_plan by the verb alone, though it never names a sibling explicitly.

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?

There is no guidance on when to use this versus alternatives, no mention of prerequisites (e.g. the recipe must already exist, created via create_recipe), and no statement about behavior when an entry already occupies that date/meal slot.

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

Deploy Server