Cookidoo MCP Server

Overview Schema Source Related Servers Discussions Admin

Remove Recipes From Shopping List

remove_recipes_from_shopping_list

Destructive

Remove selected recipes and all their ingredient items, including ticked states, from the Cookidoo shopping list while keeping manually added items.

Instructions

Remove recipes and all their ingredient items from the shopping list, including the ticked state of those items. Items added by hand are kept.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "remove_recipes_from_shopping_list"
  }
}

Input Schema

Name	Required	Description	Default
`recipe_ids`	No	Cookidoo catalogue recipe IDs
`custom_recipe_ids`	No	IDs of the user's own custom recipes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0Nov 10, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description still earns credit for disclosing the specific destructive scope that annotations cannot express: ingredient items go, their ticked/checked state goes, and manually added items survive. It leaves open what happens when both optional parameters are omitted or how partial failures are handled.

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 short sentences, zero filler, with the destructive scope front-loaded and the preservation rule as the closing qualifier. Every clause carries distinct information.

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 an output schema present, return values need not be described, and the destructive semantics plus preservation rule are covered. The remaining gap is edge-case behavior for empty/null inputs on a destructive tool where both parameters are optional.

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 both parameters (cookidoo recipe IDs and custom recipe IDs) are already documented in the schema. The description adds no syntax, format, or interaction detail about the two lists, and does not clarify the meaning of both defaulting to null. Baseline 3 is appropriate.

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 states a specific verb and resource ('Remove recipes and all their ingredient items from the shopping list') and makes the scope of the cascade explicit. It implicitly separates itself from item-level removal tools by contrasting recipe-derived items with 'items added by hand,' though it never names a sibling outright.

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 only implied: the 'Items added by hand are kept' clause hints this is the right tool when you want to clear a recipe's contribution rather than wipe the list. There is no explicit when-to-use/when-not guidance pointing to remove_shopping_list_items, clear_shopping_list, or remove_recipe-level alternatives.

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