Fitatu MCP Unofficial

Delete Fitatu Recipe

delete_recipe

Destructive

Soft-delete a recipe after confirming its exact name to hide it from searches while preserving historical meal-plan entries.

Instructions

Soft-deletes and confirms deletion of an owned active recipe definition identified by a raw recipeId after exact-name confirmation. It disappears from recipe searches, but existing day-plan entries remain historical snapshots and must be removed separately with remove_meal_items mealKey and itemId targets. Returns { status, recipeId, name, deleted }.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`recipeId`	Yes	Raw Fitatu recipe id returned by a recipe-aware MCP tool.
`expectedName`	Yes	Exact, case-sensitive current recipe name used as a destructive-action confirmation. Obtain it from get_recipe and do not trim or normalize it.

Output Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Exact name of the recipe that was deleted.
`status`	Yes	Fitatu accepted the write and the service confirmed its observable effect.
`deleted`	Yes	Confirmation that the recipe is observably deleted in Fitatu.
`recipeId`	Yes	Canonical id of the recipe that was deleted.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Sep 21, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations' destructiveHint, the description adds crucial behavioral nuance: the deletion is soft, the recipe disappears from searches, existing day-plan entries remain as historical snapshots, and the operation requires exact-name confirmation. It also states the return shape. This exceeds what annotations alone convey.

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 dense and information-rich without filler. Each sentence covers a distinct need: what is deleted, what persists, how to remove the remaining artifacts, and what the response contains.

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?

Given the tool's destructiveness and confirmation requirement, the description fully covers behavior, parameter sourcing, side effects, and return value. The output schema and sibling context complement it, so an agent has everything needed to invoke it safely and correctly.

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 100%, so the baseline is 3. The description adds meaningful context beyond the schema: recipeId must be a raw id from a recipe-aware MCP tool, and expectedName is an untrimmed, case-sensitive confirmation value obtained from get_recipe. This reinforces and extends the schema documentation.

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 uses a specific verb ('soft-deletes') and a precise resource ('owned active recipe definition identified by a raw recipeId after exact-name confirmation'). It clearly distinguishes this deletion from removing meal-plan entries, which is handled by remove_meal_items.

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 states when the tool applies (owned active recipes with exact-name confirmation) and explicitly tells the agent that day-plan entries are not removed and must be handled separately via remove_meal_items. This prevents a common misuse without ambiguity.

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