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.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| rule_id | Yes |
Delete a meal-plan rule by its UUID to remove it from your schedule.
Delete a meal-plan rule by UUID.
| Name | Required | Description | Default |
|---|---|---|---|
| rule_id | Yes |
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.
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.
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.
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.
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.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/obrien-matthew/mcp-mealie'
If you have feedback or need assistance with the MCP directory API, please join our Discord server