Cookidoo MCP Server

Overview Schema Source Related Servers Discussions Admin

Move In Meal Plan

move_in_meal_plan

Destructive

Move a planned recipe from one day to another in a Cookidoo meal plan, adding it to the new day first and rolling back if the move fails.

Instructions

Move a planned recipe (catalogue or custom) from one day of the meal plan to another. It is added to the new day before it is removed from the old one; if that fails, the change is rolled back.

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>",
      "from_day": "<from_day>",
      "to_day": "<to_day>"
    },
    "name": "move_in_meal_plan"
  }
}

Input Schema

Name	Required	Description
`to_day`	Yes	The new day, as YYYY-MM-DD
`from_day`	Yes	The day it is planned on, as YYYY-MM-DD
`recipe_id`	Yes	ID of a recipe planned on from_day (from get_meal_plan_week)

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0Nov 10, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, so safety is covered. The description adds real value beyond that: the ordering guarantee (added to the new day before removal from the old) and the rollback-on-failure behavior, which tells an agent the operation is atomic. It stops short of noting what the response looks like or any post-move side effects.

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 sentences, both earning their place: the first defines the operation, the second defines the failure semantics. The core action is front-loaded with zero preamble.

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?

With full schema coverage, an output schema, and rich annotations, the description carries only what structure can't: atomicity and rollback. Adequate for a 3-parameter mutation; the only minor gap is no mention of behavior when the target day already contains that recipe.

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 description coverage is 100%, so all three parameters are already documented, including that recipe_id comes from get_meal_plan_week. The description only adds that the recipe may be catalogue or custom, which marginally clarifies recipe_id but doesn't explain from_day/to_day beyond the schema's YYYY-MM-DD notes.

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?

States a specific verb+resource+scope: "Move a planned recipe (catalogue or custom) from one day of the meal plan to another." The move semantics (relocation, not add or remove) distinguish it from the add/remove siblings without needing to name them.

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?

Usage is implied rather than stated: an agent can infer this is the right call when a recipe already exists on one day and should be relocated, replacing a remove+add pair. No explicit when-to-use guidance, prerequisites, or named alternatives (e.g., add_to_meal_plan vs remove_from_meal_plan) are given.

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