Add a meal plan entry to your Mealie calendar for breakfast, lunch, dinner, or side dishes by specifying a date, entry type, and title. Use it to schedule meals and optionally link a recipe.
Anade una entrada al calendario de Mealie. entry_type: lunch|dinner|breakfast|side.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| date_str | Yes | ||
| entry_type | Yes | ||
| recipe_slug | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does not say whether an entry at the same date/type is overwritten or duplicated, what permissions or preconditions are required (e.g., recipe_slug must exist), or anything about the mutation's effects.
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?
Two short sentences with no filler and the purpose is front-loaded. However, the brevity comes at the cost of under-specification rather than being a model of tight structure.
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?
An output schema exists, so return values needn't be explained. But for a 4-parameter mutation tool with zero annotation and zero schema-description coverage, key details (date format, recipe linkage, duplicate handling) are missing.
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?
Schema description coverage is 0%, so the description must compensate, and it only clarifies entry_type's allowed values (lunch|dinner|breakfast|side) — valuable since the schema lacks an enum. It leaves date_str's expected format, title's meaning, and the optional recipe_slug linkage completely undocumented.
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?
States a specific verb ('Añade') and resource ('entrada al calendario de Mealie'), so the agent knows it creates a meal-plan entry. It is implicitly distinct from get_mealplan_week and delete_mealplan_entry, but doesn't name or contrast with them.
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?
There is no guidance on when to use this versus siblings like delete_mealplan_entry, clear_mealplan_week, or how it interacts with get_mealplan_week. The agent must infer the calling context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.