Turkey thaw, roast, and food-safety timelines calculated for your bird's weight and dates.
Scored across 3 tools
get_roast_time and get_thaw_time are clearly separated by which phase of the cook they answer, and plan_turkey_timeline is framed as the full dated plan rather than a single calculation. There is mild overlap since the planner restates thaw and roast timings, so an agent must decide between 'one number' and 'whole schedule', but the descriptions make that choice legible.
All three names are snake_case verb_noun constructions (get_roast_time, get_thaw_time, plan_turkey_timeline). The verb change from get_ to plan_ tracks a real semantic difference (lookup vs. multi-step schedule) rather than arbitrary variation.
Three tools is thin but defensible for a single-domain turkey-timing server, and each tool has a distinct job. A slightly richer surface (e.g. a standalone brine or sides calculator) would reduce reliance on the single planner tool.
The surface covers thaw, roast, and a full buy/thaw/brine/roast/rest timeline, which is the core lifecycle for the stated purpose. Gaps are minor: brining and sides timings exist only inside plan_turkey_timeline, and the 8-24 lb unstuffed range is a hard boundary with no stuffed-bird or oversized-bird path.
Dinner at 5 does not mean the oven at 5: for a big bird, the oven time lands hours earlier than most people picture. The USDA roast time for an unstuffed turkey at 325F: the chart band and the middle of the band a plan should use, plus the oven-in time when a dinner date and time are given. With state frozen, it gives the USDA from-frozen chart band instead (cooking from frozen is safe and takes at least 50 percent longer). Covers 8 to 24 lb. Ends with the 165F check rule.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Whether the bird is thawed or still frozen. Default: thawed. Frozen uses the USDA from-frozen roast chart. | |
| weight_lb | Yes | Turkey weight in pounds, 8 to 24. Example: 18 | |
| dinner_date | No | Optional dinner date, YYYY-MM-DD. Default when a time is given: the next upcoming turkey day (Thanksgiving, or Dec 25 once Thanksgiving has passed). | |
| dinner_time | No | Optional dinner time, 24-hour HH:MM. With a dinner time, the tool returns when the bird goes in the oven. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations that already establish a safe read-only lookup, the description adds meaningful behavior: it returns a chart band plus a middle-of-band plan, computes oven-in time when dinner date/time are supplied, uses a different from-frozen chart, and notes frozen cooking takes at least 50 percent longer. It still does not fully specify the exact response shape, which matters because no output schema exists.
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 relatively compact and organized around the roast-time behavior, frozen variant, weight range, and final safety check. The opening dinner-time framing is somewhat rhetorical, but it sets context rather than adding unnecessary detail.
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 four-parameter, read-only lookup with rich schema coverage and annotations, the description covers the important cooking context, frozen behavior, weight bounds, and the 165F safety rule. The main remaining gap is that return-value structure is not spelled out and sibling routing is not explicit.
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 100%, so the schema already carries parameter meaning, including the 8 to 24 lb weight range, default thawed state, and dinner date/time behavior. The description reinforces some of this and adds the chart-band framing, but most parameter semantics are already present in 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 precise resource and scope: USDA roast-time guidance for unstuffed turkey at 325F, 8 to 24 lb, with a separate frozen path. It does not explicitly distinguish itself from get_thaw_time or plan_turkey_timeline, so the sibling differentiation is only implicit in the roast/oven-time framing.
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 explains that dinner date and time cause the tool to return oven-in time, and that state=frozen switches to the from-frozen chart. However, it does not explicitly say when to use this tool instead of get_thaw_time or plan_turkey_timeline, leaving alternative selection implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The thaw is where Thanksgiving goes wrong: guess the start day and the bird is still frozen on cook day. This names the exact start day. How long a turkey takes to thaw, by USDA method: in the fridge (chart band in days, plus the start date when a cook date is given) or in cold water (30 minutes per pound, with the chart band in hours). Covers 8 to 24 lb.
| Name | Required | Description | Default |
|---|---|---|---|
| method | No | Thaw method. Default: fridge. | |
| cook_date | No | Optional cook date, YYYY-MM-DD. With a fridge thaw, the tool returns the date to move the bird to the fridge. | |
| cook_time | No | Optional cook time, 24-hour HH:MM. Default: 17:00. For a fridge thaw, give the dinner time the plan counts back from (the same frame as plan_turkey_timeline); the answer states the real time the bird spends in the fridge before oven-in. For cold water, give the time the bird must be thawed by (when it goes in the oven), not the dinner time. | |
| weight_lb | Yes | Turkey weight in pounds, 8 to 24. Example: 20 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the description's job is to add behavior beyond that, which it does: it discloses the per-method return shapes (day band on fridge, hour band on cold water) and the 30-minutes-per-pound rule. It stops short of disclosing out-of-range handling for weights outside 8-24 lb.
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 core facts are front-loaded after a one-line framing sentence about Thanksgiving risk, and the method-specific behavior follows in a single compact sentence. The opening hook costs a little space but is short and does orient the reader quickly.
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?
With no output schema, the description must characterize the return value, and it does so for both methods plus the conditional start date. Annotations and the fully documented four-parameter schema cover safety and inputs, leaving only edge-case behavior (invalid weights, date formats) unaddressed.
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 one step above it by adding the quantitative thaw rate (30 minutes per pound) and by clarifying the differing meaning of the result depending on method. The cook_time framing distinction itself lives in the schema, so no additional credit is due there.
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 names the exact resource and computed quantity ('How long a turkey takes to thaw'), and specifies the two USDA methods and the 8-24 lb range, so the agent knows precisely what comes back. It never explicitly distinguishes itself from get_roast_time or plan_turkey_timeline, so sibling differentiation is only implicit through the cook_time reference.
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?
Usage is implied rather than stated: the description explains that a fridge thaw yields a chart band in days and a start date when a cook date is supplied, and that cold water yields a band in hours. It never says when to reach for this tool versus plan_turkey_timeline (which also produces a timeline) or when the tool is the wrong choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ThawDay counts back from your dinner hour and names the exact buy, thaw, brine, and roast days. Build the dated turkey plan for one dinner: when to buy, when to start the fridge thaw, when to start brining (if brining), when the bird goes in the oven at 325F, when to start the sides, and when to rest and carve. Dates come from USDA FSIS thaw and roast charts. Plans unstuffed birds, 8 to 24 lb. Dinner times are read in local time, just as they were given. Steps that depend on the time now are judged in that local frame: pass an IANA timezone when you know it; without one, a step is only called past once it is past in every US time zone. The plan says so in a clock note.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | Whether the bird is frozen or fresh. Default: frozen. | |
| brining | No | Add a brine start row, 24 hours before the oven. Default: no. | |
| timezone | No | Optional: the user's IANA time zone, like America/New_York. When given, steps are judged against the user's exact local time. When omitted, a step is called past only once it is past in every US time zone. | |
| now_local | No | Optional: the user's current local date and time, like 2026-11-02 14:20. Wins over timezone when both are given. Most callers should pass timezone instead. | |
| weight_lb | Yes | Turkey weight in pounds, 8 to 24. Example: 14 | |
| dinner_date | No | Dinner date, YYYY-MM-DD. Default: the next upcoming turkey day (Thanksgiving, or Dec 25 once Thanksgiving has passed). | |
| dinner_time | No | Dinner time, 24-hour HH:MM. Default: 17:00. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, and the description adds substantive behavior beyond them: dates are sourced from USDA FSIS charts, oven is fixed at 325F, unstuffed birds only, and — most importantly — a step is judged "past" in the user's local frame, falling back to "past in every US time zone" when no timezone is supplied, with the plan disclosing that in a clock 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 first sentence front-loads what the tool does and the second enumerates the output rows, which is good structure. The three timezone-related sentences overlap somewhat and "The plan says so in a clock note" is a slightly padded closing, though no sentence is wholly wasted.
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 7-parameter tool with no output schema, the description does the necessary work by naming what each plan row is and how past/future steps are labeled. It stops short of describing the concrete shape or date/time formatting of the returned plan, which an agent planning a follow-up turn would benefit from.
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?
With 100% schema coverage the baseline is 3, but the description contributes a recommendation the schema does not make ("pass an IANA timezone when you know it") and explains why the timezone matters, namely that time-dependent steps are judged in that local frame. The now_local-vs-timezone precedence it mentions largely restates 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?
"ThawDay counts back from your dinner hour and names the exact buy, thaw, brine, and roast days" states a precise verb and resource, and enumerating the full set of dated rows (buy, thaw, brine, oven at 325F, sides, rest/carve) makes clear by scope that this is the composite planner rather than the single-value sibling lookups get_roast_time or get_thaw_time.
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?
"Build the dated turkey plan for one dinner" plus "Plans unstuffed birds, 8 to 24 lb" gives a clear scenario and an explicit exclusion (not stuffed, not outside 8-24 lb), which is more than most tools offer. It never names get_roast_time or get_thaw_time as faster alternatives when only one time is needed, so the when-to-use-vs-sibling rule is left implicit.
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.
get_roast_timeget_thaw_timeplan_turkey_timelineDaily calorie target to lose, keep or gain weight, plus a weight goal timeline.
Raw to cooked weight of meat and poultry by cut and cooking method from USDA cooking yields.
Vegetable and fruit yield percentage, trim waste and how much produce to buy, from USDA refuse data.
Cups to grams for 271 ingredients with USDA and King Arthur densities, recipe scaling, oven temps.
Add one secure layer between your agents and this server.