FeastFlow cooking times

Plan a roast dinner

plan_roast_dinner

Read-onlyIdempotent

A timeline for a whole roast dinner (Sunday roast, Christmas dinner or Thanksgiving), worked back from the serving time: when to take the meat out of the fridge, heat the oven, put it in, turn the oven up for the sides, and when each side goes on. Also lists what can be done the day before.

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": {
      "main": "<main>",
      "weight": "<weight>",
      "serve_time": "<serve_time>"
    },
    "name": "plan_roast_dinner"
  }
}

Input Schema

Name	Required	Description
`main`	Yes	The main roast. crown is a turkey crown.
`unit`	No	kg (default) or lb.
`sides`	No	Optional sides: roastPotatoes, yorkshires, pigsInBlankets, stuffing, rootVeg (roast parsnips and carrots), cauliflowerCheese, greens, carrots, breadSauce, mash, dressing (baked stuffing), greenBean (green bean casserole), sweetPotato (sweet potato casserole), macCheese, rolls, corn, cranberry, pie, gravy. Plain names such as "roast potatoes" work too.
`method`	No	Turkey only: uk (190°C) or usda (325°F). Defaults to usda when the weight is in lb.
`weight`	Yes	Weight of the meat, in the unit given by unit.
`doneness`	No	Optional. beef: rare, medium or well. lamb: pink or well.
`serve_time`	Yes	Serving time as HH:MM in 24-hour time, e.g. 14:00.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 9, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare this a read-only, idempotent, closed-world computation, so the safety profile is covered. The description earns extra credit by disclosing the shape of what comes back — an ordered timeline anchored on serve_time plus a day-before prep list — 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the deliverable, then the enumerated timeline steps, then the supplementary day-ahead list. No filler and the ordering mirrors how an agent would reason about the result.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a deterministic scheduling tool with a fully documented 7-parameter schema and no output schema, the description covers both the purpose and the returned structure well. Only minor gaps remain, such as whether the timeline is time-ordered text or structured entries and what happens with unsupported side names.

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 description adds no parameter-level meaning at all; everything about main, weight, sides, method and serve_time lives in the schema, which has 100% coverage. With the schema fully documented and doing the heavy lifting, the baseline of 3 applies.

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?

States a specific deliverable: a timeline for a whole roast dinner worked back from the serving time, enumerating the events it schedules (fridge out, oven on, oven up for sides, sides in) plus a day-before list. That scope clearly separates it from single-item siblings like roast_cooking_time or turkey_thawing_time, though no sibling is named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The multi-dish framing ("whole roast dinner", "Sunday roast, Christmas dinner or Thanksgiving") implies when to reach for this over the per-item time tools, but there is no explicit statement of when to use it versus roast_cooking_time or side_dish_times, and no prerequisites or limitations are given.

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

All FeastFlow cooking times tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?