Holiday cooking schedule
Scored across 2 tools
The two tools target different needs: a single-item turkey time calculator versus a multi-dish schedule planner. There is mild overlap because plan_cooking_timeline also folds in turkey roast and thaw steps when a weight is supplied, so an agent could hesitate on which to call for a turkey-only query. The descriptions do resolve this by framing one as the pure calculator and the other as multi-dish scheduling.
Both names use the same snake_case verb_noun pattern (calculate_turkey_times, plan_cooking_timeline) with clear action-first phrasing. No mixed conventions or vague verbs.
Two tools is thin for a server whose stated purpose spans turkey timing plus holiday meal scheduling. The pair is coherent and each earns its place, but the surface feels narrow and leaves little room for adjacent operations.
Within its declared domain the set is solid: weight-based roast/thaw times, oven-conflict detection, make-ahead handling, printable PDF, ICS export and a shopping note. Gaps are minor and explicitly out of scope (other meats, deep frying, smoking, actual recipes), though there is no dedicated tool for shopping quantities or oven-capacity planning beyond a simple ovens count.
Use this when the user asks a turkey cooking time calculator question: how long to roast a turkey by weight (lb or kg), stuffed or unstuffed, or turkey thaw time in the fridge or cold water. Returns the USDA FSIS roasting range at 325°F, the 165°F safe internal temperature, fridge and cold-water thaw times and, with a serve time, the clock times to start thawing and roasting. Covers 4 to 24 lb (stuffed 8 to 24 lb). Does not cover other meats, deep frying or smoking.
| Name | Required | Description | Default |
|---|---|---|---|
| clock | No | 12h (default) or 24h. | |
| weight | Yes | Turkey weight in pounds, or text with a unit, e.g. 14 or "6.5 kg". | |
| stuffed | No | true if stuffed. Default false. | |
| serve_time | No | Optional serve time to get clock times, e.g. "2026-11-26 16:00" or "4 PM" (default date Thanksgiving, 26 November 2026). | |
| rest_minutes | No | Minutes to rest before carving, default 30 (USDA says at least 20). |
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| source | Yes | |
| stuffed | Yes | |
| schedule | Yes | |
| weight_kg | Yes | |
| weight_lb | Yes | |
| roast_time | Yes | |
| oven_temp_f | Yes | |
| usda_bracket | Yes | |
| roast_minutes_low | Yes | |
| roast_minutes_high | Yes | |
| fridge_thaw_days_low | Yes | |
| safe_internal_temp_c | Yes | |
| safe_internal_temp_f | Yes | |
| fridge_thaw_days_high | Yes | |
| cold_water_thaw_minutes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the description's job is to add grounding context, which it does: it names the USDA FSIS source, the 325°F roasting range, the 165°F safe internal temperature, and the fact that supplying a serve time produces back-calculated start times. It does not describe output units or what happens outside the stated weight bounds, but the conditional-output behavior is valuable disclosure beyond the annotations.
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 dense sentences: the first front-loads the usage trigger and coverage, the second delivers the return payload and the domain bounds. No filler, no repetition of the title, and the exclusions come last where they are easy to scan.
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 need not be spelled out, yet the description still summarizes them accurately. Combined with the explicit weight-range limits and domain exclusions, an agent has everything needed to decide to call this tool and to supply weight plus optional serve_time correctly.
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 coverage is 100%, so the baseline is 3, and the description earns an increment by explaining the conditional effect of serve_time (clock times to start thawing and roasting) and the stuffed/unstuffed branch, which clarifies how parameters change results rather than just restating field docs. It does not mention clock, rest_minutes, or the default Thanksgiving date, leaving those entirely to the schema.
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 states a specific verb and resource (calculate turkey roast and thaw times) and enumerates the exact input dimensions it handles: weight in lb or kg, stuffed vs unstuffed, fridge vs cold-water thaw. It also bounds the domain (4 to 24 lb, stuffed 8 to 24 lb), so an agent knows precisely what question this tool answers.
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?
It gives an explicit trigger condition ("Use this when the user asks a turkey cooking time calculator question") and explicit exclusions ("Does not cover other meats, deep frying or smoking"). The only minor gap is that it does not name the sibling plan_cooking_timeline for multi-dish planning, but the when/when-not framing is unambiguous for the tool's own domain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants a Thanksgiving cooking timeline, a holiday dinner cooking schedule or an oven schedule for several dishes. Convert the user's menu, pasted recipe notes or a photo of a menu into the dishes array (name, prep_minutes, cook_minutes, rest_minutes, method, oven_temp, make_ahead); use text only as a fallback. Works backward from serve_time (default Thanksgiving, 26 November 2026, 4:00 PM) and gives each step a clock time, detects oven conflicts (one oven by default, ovens: 2 for two), moves make-ahead dishes earlier, adds turkey roast and thaw steps from the USDA table when a turkey weight is given, and returns a printable checklist PDF, an ICS calendar file with a reminder per step, and a shopping-day note. Up to 25 dishes. Does not invent recipe times or give recipes.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Fallback only: a pasted menu, one dish per line, e.g. "Stuffing: prep 20, bake 45 min at 350F, make ahead". Prefer dishes. | |
| clock | No | 12h (default, 4:00 PM) or 24h (16:00). | |
| cooks | No | People doing hands-on prep at the same time, default 1. | |
| ovens | No | Number of ovens, 1 (default) or 2. | |
| paper | No | PDF paper size: letter (default) or A4. | |
| title | No | Title for the PDF and calendar, e.g. Thanksgiving at Grandma's. | |
| dishes | No | The menu as a list of dish objects. Convert the user's pasted menu, recipe notes or a photo of a menu into these fields. Example: [{"name":"Green bean casserole","prep_minutes":15,"cook_minutes":30,"oven_temp":350,"make_ahead":true},{"name":"Gravy","cook_minutes":15,"method":"stovetop"}]. Up to 25 dishes. | |
| turkey | No | Optional turkey roasted from the USDA timetable at 325°F, e.g. {"weight":16,"stuffed":false,"frozen":true}. | |
| burners | No | Stovetop burners, default 4. | |
| serve_date | No | Serve date if given separately, e.g. 2026-11-26. | |
| serve_time | No | When dinner is served, e.g. "2026-11-26 16:00", "4:00 PM" or "Nov 26 5pm". Default date is Thanksgiving, 26 November 2026; default time 4:00 PM. | |
| hold_minutes | No | Minutes a dish that is not make-ahead may come out early and wait covered to make room in the oven, default 30. 0 to never hold. | |
| share_within_f | No | A dish that is not make-ahead may join an oven already running within this many °F (cooked about 10% longer per 25°F lower), default 25. 0 to keep recipe temperatures. | |
| preheat_minutes | No | Minutes to preheat or change oven temperature, default 15. | |
| reminder_minutes | No | Calendar alarm this many minutes before each step, default 5. | |
| temperature_unit | No | F (default) or C for oven temperatures given without a unit. | |
| shopping_days_before | No | Shopping day this many days before serving, default 2. |
| Name | Required | Description |
|---|---|---|
| held | Yes | |
| flags | Yes | |
| moved | Yes | |
| ovens | Yes | |
| serve | Yes | |
| steps | Yes | |
| title | Yes | |
| counts | Yes | |
| dishes | Yes | |
| turkey | Yes | |
| shopping | Yes | |
| stovetop | Yes | |
| conflicts | Yes | |
| downloads | Yes | |
| plan_notes | Yes | |
| assumptions | Yes | |
| flags_count | No | |
| shared_oven | Yes | |
| steps_count | No | |
| dishes_count | No | |
| conflicts_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial behavior beyond them: it works backward from serve_time, applies a default date of 26 November 2026 4:00 PM, detects oven conflicts, moves make-ahead dishes earlier, pulls turkey roast/thaw steps from the USDA table, caps input at 25 dishes, and states it does not invent times or supply recipes. It also discloses the three return artifacts (PDF, ICS with per-step reminders, shopping-day note).
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 trigger condition is front-loaded and the paragraph reads as a dense chain of behavioral facts with no filler sentences. It is long, but for a 17-parameter tool nearly every clause carries information; only the repeated dishes/text fallback guidance overlaps with the schema.
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?
For a 17-parameter, no-required-param tool with an output schema, the description covers the trigger, the input conversion strategy, key defaults, conflict-handling logic, limits, and what artifacts are produced. An agent has everything needed to decide to call it and how to shape inputs correctly.
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 coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema cannot express: it instructs converting a menu or photo into the dishes array with text as fallback only, and clarifies 'one oven by default, ovens: 2 for two'. It does not elaborate on the many numeric tuning params (hold_minutes, share_within_f), which the schema already documents.
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 opens with a concrete trigger ('Use this when the user wants a Thanksgiving cooking timeline, a holiday dinner cooking schedule or an oven schedule for several dishes'), naming a specific verb and resource. It never mentions the sibling calculate_turkey_times, so an agent cannot tell from this text alone whether turkey timing belongs here or in the sibling, keeping it below a 5.
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?
It gives explicit usage context via the 'Use this when...' clause and enumerates valid inputs (menu, pasted recipe notes, photo of a menu, with text only as fallback). It does not state when NOT to use it or point to calculate_turkey_times, so the guidance is clear but has no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
calculate_turkey_timesplan_cooking_timelineTurkey and roast cooking times, thawing times and roast dinner timelines. UK and US times.
Weekly staff shift schedules
Turkey thaw, roast, and food-safety timelines calculated for your bird's weight and dates.
Recipes, plating guides and kitchen calculators (turkey, Thanksgiving timeline). Free, read-only.
Add one secure layer between your agents and this server.