Kitchen Timer

Plan a meal

plan_meal

Make a meal plan: each dish starts at the right moment so everything is ready at the same time. Returns a link (open it on the phone in the kitchen, where the alarms ring), a QR code for that link, and the schedule. YOU do the cooking knowledge: break a recipe into dishes, each with its total cooking minutes, and put the timed moments inside a dish as steps ("simmer 20, rest 5" is a dish of 25 minutes with a step "Rest" at 20). If the person did not say when they want to eat, ASK before calling; use readyInMinutes for "we eat in 90 minutes", readyAt (an ISO date-time with a UTC offset, or local time plus timeZone) for "at 7", or startNow to start cooking now (a single timer is a one-dish plan with startNow). Keep times realistic and use only what the person gave you; at most 12 dishes and 12 hours. Dish names are plain text, no links. The reply link works for anyone who has it and the plan is deleted about a day after the meal. Tell the person the alarms ring on the phone page, not in this chat. The reply also holds a secret CONTROL KEY (starts with ktpk_): remember it for the rest of the chat, do not show it or put it in any link, and pass it with the plan's code to the control tools to keep managing this plan. Once it works you may offer the person to manage their whole kitchen from now on (⋯ → Link an agent in the app gives the connector address and a 6-digit code).

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": {
      "dishes": "<dishes>"
    },
    "name": "plan_meal"
  }
}

Input Schema

Name	Required	Description
`dishes`	Yes	What is being cooked. A single timer is one dish.
`readyAt`	No	Everything ready at this time: ISO 8601 with a UTC offset (2026-10-17T19:00:00+01:00), or without an offset when timeZone is given, or epoch milliseconds.
`startNow`	No	True: start every dish now (the longest dish sets when it is ready).
`timeZone`	No	Optional IANA time zone such as Europe/London. Only used to word the schedule text; the card and the phone show times in the viewer's own clock.
`readyInMinutes`	No	Everything ready this many minutes from now. Give exactly one of readyInMinutes, readyAt, startNow.

Output Schema

Name	Required	Description
`url`	Yes	Open this on the phone in the kitchen.
`code`	Yes
`links`	No	Each dish that starts after another dish (also on the dish as startsAfter).
`alarms`	No
`dishes`	No
`schedule`	Yes
`readyAtMs`	Yes
`expiresAtMs`	No
`serverNowMs`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 27, 2026

addedInput schema / properties / dishes / items / properties / startsAfter

Added value: +{
+  "additionalProperties": false,
+  "description": "Optional: this dish starts a while after ANOTHER dish instead of finishing with the meal, for example the potatoes 30 minutes after the chicken goes in. Starting that other dish early or late then moves this one with it. The other dish may not itself wait on this one.",
+  "properties": {
+    "dish": {
+      "description": "The other dish: its name as in this plan, or its number (1 is the first dish).",
+      "type": [
+        "string",
+        "number"
+      ]
+    },
+    "minutes": {
+      "description": "Minutes after that moment. 0 or left out: right then.",
+      "maximum": 720,
+      "minimum": 0,
+      "type": "number"
+    },
+    "when": {
+      "description": "Count from when the other dish goes in, or from when it is done.",
+      "enum": [
+        "goes in",
+        "is done"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "dish",
+    "when"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / links

Added value: +{
+  "description": "Each dish that starts after another dish (also on the dish as startsAfter).",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

First observedOct 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes far beyond the annotations: discloses that the reply link is shareable by anyone who holds it, that the plan is deleted roughly a day after the meal, that alarms fire on the phone page rather than in chat, and that a ktpk_ control key is returned and must be kept secret. It also states hard limits (12 dishes, 12 hours) that annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

Purpose and the critical 'ask before calling' rule are front-loaded, and nearly every sentence carries operational weight. It is dense and delivered as a single long paragraph with parenthetical asides, so structure could be tightened, but the length is justified by the tool's complexity.

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

Completeness5/5

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

Even though an output schema exists, the description usefully names the return payload (link, QR code, schedule) plus the secret control key, and covers retention, sharing, and where alarms actually ring. Nothing an agent needs to call this correctly or to instruct the user afterwards is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 a genuinely non-obvious conceptual model: '"simmer 20, rest 5" is a dish of 25 minutes with a step "Rest" at 20', which clarifies the relationship between minutes, steps and atMinutes. It also explains the readyAt offset/timeZone interaction and the dish-name-is-plain-text constraint, though it leaves startsAfter's chaining rules to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a concrete verb+resource ('Make a meal plan') and immediately defines the core mechanic: 'each dish starts at the right moment so everything is ready at the same time.' The creation role is clearly separated from the sibling management tools (add_dish, adjust_dish, cancel_meal), which the description refers to as 'the control tools to keep managing this plan.'

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

Usage Guidelines5/5

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

Explicitly states prerequisites ('If the person did not say when they want to eat, ASK before calling') and maps natural-language intents to the correct scheduling parameter ('we eat in 90 minutes' → readyInMinutes, 'at 7' → readyAt, 'start cooking now' → startNow). It also tells the agent when to route to the control tools and that a single timer is just a one-dish plan.

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

All Kitchen Timer 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?