mcp-mealie

delete_mealplan_rule

Delete a meal-plan rule by its UUID to remove it from your schedule.

Instructions

Delete a meal-plan rule by UUID.

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": {
      "rule_id": "<rule_id>"
    },
    "name": "delete_mealplan_rule"
  }
}

Input Schema

Name	Required	Description	Default
`rule_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.7.0Jun 19, 2026

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present, so the description must fully disclose behavioral traits. It only says 'Delete,' which implies a destructive operation, but does not state whether deletion is permanent, cascading, reversible, or requires specific permissions. The agent has no information about side effects or constraints beyond the name.

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 a single sentence that immediately conveys the purpose. It is as concise as possible for a simple delete operation. No extra words are present, and it is front-loaded. It earns a 4 because it is appropriately sized for the tool's simplicity.

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's low complexity (1 parameter, no output schema) and lack of annotations, the description provides minimal context beyond the action. It is adequate for a straightforward delete, but missing information about idempotency, error handling, or relational impact. The agent can likely invoke it correctly but with some risk.

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?

The schema provides no description for rule_id (coverage 0%). The description adds the hint 'by UUID,' which clarifies the expected format. This adds value beyond the schema's title 'Rule Id.' However, for a single parameter, more detail (e.g., source of UUID) would be helpful.

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 action ('Delete') and resource ('a meal-plan rule') and specifies the identifier method ('by UUID'). The name itself is unambiguous, and it distinguishes from sibling tools like update_mealplan_rule and get_mealplan_rule through the verb. However, it does not explicitly contrast with these siblings, so a 5 is not warranted.

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?

No usage guidelines are provided. There is no indication when to use this tool versus alternatives (e.g., update_mealplan_rule for changes, or list_mealplan_rules to find the UUID). No prerequisites or exclusions are mentioned. This is a significant gap for a destructive action.

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

Deploy Server