Tabletime

• 

  The redesigned kitchen: a visual menu, shared kitchen settings, and a plan to review before saving.

• 

  A real repair: 19:37 serving time, ten steps adjusted, and started work held in place.

• 

  Earlier interface: the first working MCP kitchen display.

• 

  Earlier interface: the original delay-repair test, with frozen started work.

Dinner has dependencies

A recipe tells you how to cook one dish. It rarely tells you what to do when three other dishes need the same burner, the bread cannot sit around, and the lentils are running late. That coordination problem is the starting point for Tabletime.

What it does

Pick a menu, the number of cooks and burners, and a serving time. Tabletime schedules the whole dinner. You can inspect it by dish or by equipment, see which steps need your attention, and review a proposal before saving it.

The demo has four original vegetarian example recipes and 19 steps. In the recorded run, one cook and two burners can serve dinner at 19:30. When the lentils need eight extra minutes, Tabletime holds started work in place, adjusts ten remaining steps and reports the new serving time: 19:37. It does not keep promising the original deadline.

A second scenario removes the oven before cooking starts. One cook cannot satisfy this menu’s appliance and serving-window constraints. Tabletime reports that conflict and offers a verified two-cook alternative using the hob. The original plan remains active until the alternative is confirmed.

The working MCP integration

This entry uses the self-hosted MCP server route for the Alexa+ track. The Node server implements MCP 2025-11-25 over Streamable HTTP with the official SDK. The local browser display uses the official MCP client to call five real tools: kitchen_menu, read_dinner, draft_dinner, draft_repair and accept_dinner. These calls run the scheduling engine and persist state; they are not canned responses.

The server remembers the dinner across restarts. Confirmations carry an expected revision and an idempotency key, so a stale proposal cannot overwrite a newer dinner and a retry cannot apply the same change twice. An assistant can use the same tools, explain a proposal and ask the cook before accepting it.

The public browser demo runs the same solver and state machine in a Web Worker, with localStorage. It needs no account or paid API. The repository explains how to run the actual MCP endpoint locally. There is no claim of Alexa certification or testing on an Echo device.

The difficult part

The planner uses a mixed-integer model solved by HiGHS/WASM. It handles dependencies, alternative cooking methods, exclusive equipment and cook time, appliance blackouts, maximum waiting times, serving windows and continuous use of the same saucepan. A simmering pot still occupies its burner even when the cook is free.

The first optimization stage minimizes serving time; the second reduces waiting and disruption. A separate interval checker validates the result before it can become a proposal. Timeouts and proven infeasibility are different outcomes.

State handling mattered as much as scheduling. Drafting, confirmation, retries and resuming after a restart are separate operations, rather than one optimistic button that silently changes dinner.

What has been checked

The test suite matches an independently written exhaustive oracle on 36 small mixed-mode problems. All 60 fixed-seed synthetic benchmark schedules passed the independent checker; 24 were proved optimal within the time budget. The mean finish improved 4.73% over FIFO but only 0.26% over a stronger multistart baseline. That is not a claim of a new optimization breakthrough. The useful work is the model, checked repairs and complete interaction. Full inputs, code, results and limitations are in the repository.

An integration test connects the official SDK client to the HTTP endpoint, exercises proposals and confirmations, rejects stale updates, checks a foreign Origin, repairs a delay, and verifies saved state in a new server process.

Scope and next steps

This is a working prototype built during September 2026. Recipe timings and serving windows are illustrative, not results from kitchen trials. Advancing the clock explicitly simulates following the plan; no sensor observes cooking. There is no appliance control, recipe import, purchase flow or food-safety guarantee.

The next useful step is to test the recipes with cooks and replace simulated progress with explicit step-completion input. Variable oven temperatures and household authentication come after that.

Built With

• javascript
• react