Mise

A dinner-party studio that shares one live table with ChatGPT. The page registers WebMCP tools, the agent plans and shops, and only the host can lock the menu.

Comment

What it is

Mise is a dinner-party planning studio that shares one live table with ChatGPT. The host opens the site, the agent works the same page, and both edit the same record: brief, guest list, menu, seating chart, market list, and run of show. Every party is a /p/{id} share link backed by D1 on ChatGPT Sites. No accounts. Anyone with the link, including ChatGPT, edits the same party.

How WebMCP is used

The page registers 25 core tools on document.modelContext, plus 3 read-only lens tools that register while their panel is open. Source: tools.ts

The tools are the app, not decoration. set_event_brief, add_guest, propose_menu, substitute_dish, auto_seat, generate_shopping_list, and generate_run_of_show write the state the studio renders. get_workspace_state gives the agent the same view the human has. Destructive tools, lock_menu and send_invites, open a confirmation dialog in the page. The agent asks, only the host can finish.

Mise also publishes a remote MCP server at https://mise-studio.ruddro-roy.chatgpt.site/api/mcp. Add it in ChatGPT Developer mode (no auth) and ChatGPT gets 13 tools against the same D1 parties. In the demo video, ChatGPT calls create_party and returns a share link that is still live.

Concurrent writes are handled. A save that lost a race gets a 409 and retries once against the latest record.

How we built it

Vite, React, and Tailwind for the studio. A Hono worker on ChatGPT Sites with D1 for party storage, schema managed with Drizzle migrations. A WebMCP polyfill implements registerTool, getTools, executeTool, and toolchange in browsers without native support, so the in-page Sous-chef runs the same tools everywhere. The remote MCP server speaks Streamable HTTP and negotiates protocol 2025-06-18.

Challenges

The hard problems were concurrency and consent. Two writers on one record meant building a save queue with 409-and-retry-once semantics, and a 2-second poll that only applies remote state when local edits are clean. Consent meant making lock_menu wait on a dialog only the host can click, and getting that to survive the race between the confirm click and the dialog close event.

How to judge it

  1. Open the live site. A fresh party is created and its id goes in the URL.
  2. Ask the Sous-chef: "Plan Saturday dinner for 8. Two guests are vegan. Maya has a nut allergy. Budget is $90. Italian, warm and unfussy." Watch the panels fill as the tools run.
  3. Say "book it". The page opens a confirmation dialog. Confirm it and the menu locks.
  4. Refresh. The /p/{id} party and its state persist.
  5. Optional: add https://mise-studio.ruddro-roy.chatgpt.site/api/mcp as a remote MCP server in ChatGPT Developer mode, run create_party, and open the returned share URL.

The party created in the demo video is still live: /p/81065ff59c

What's next

RSVP links so guests answer the invite on their phone and the seating chart updates from their answer. A bigger dish catalog with per-store pricing so the market list carries real totals. Multi-party memory, so the agent can reuse what worked from the last dinner when it plans the next one.

Built With

  • chatgpt-sites
  • cloudflare-d1
  • drizzle
  • hono
  • mcp
  • react
  • tailwindcss
  • typescript
  • vite
  • webmcp
Share this project:

Updates