Dish Decider

Everyone’s AI has a seat at the table. DishDecider lets agents coordinate on one shared plan, catch conflicts, and make smarter choices together—with WebMCP.

Comment

Inspiration

Every group event has the same failure mode: five people bring chips, nobody brings a main course, and somebody blows the budget — and nobody notices until it is already awkward to fix. That is not really a communication problem; it is a coordination problem. Group chats and shared spreadsheets still rely on someone manually cross-checking everyone's plans.

WebMCP made us wonder: what if every participant's own AI agent could act on the same live shared plan instead of every assistant working in isolation? Agents could understand what each person wants, see what has already been claimed, and catch conflicts before they are committed. That is the idea behind DishDecider.

What it does

DishDecider is a shared event planner. One person creates an event with a budget cap; anyone with the link can join with just a name and dietary restrictions — no account required.

Participants can claim dishes manually or simply tell their agent what they want in natural language, such as "I'm broke this week" or "I want to impress but only have 20 minutes." The agent turns that request into structured constraints and recommends a specific dish.

The core feature is shared-state conflict resolution. If a proposed dish duplicates an existing choice, violates a participant's dietary restriction, or pushes the group over budget, the system detects the conflict, explains why in plain language, and suggests an alternative. Every action is visible in the shared event and recorded in an activity log. After the event, a recap shows computed metrics such as total spending, conflicts resolved, and suggestion acceptance rate.

How we built it

We built four WebMCP tools, registered through document.modelContext.registerTool:

  • interpret_intent — converts open-ended requests into structured constraints
  • suggest_item — recommends an item using those constraints and the current event state
  • resolve_conflict — validates a proposal against live shared state and identifies conflicts
  • explain_tradeoff — compares valid alternatives and explains the reasoning

All four route through a consolidated reasoning endpoint backed by an LLM, with Zod-validated structured output and a deterministic fallback so the application remains functional if a model call fails.

Event state is stored in Supabase, with realtime subscriptions so every participant sees updates without refreshing. The application is deployed on Vercel.

Challenges we ran into

Our biggest challenge was proving that WebMCP itself actually worked. It is easy to write registerTool calls and assume they are working; it is much harder to verify that a browser-native agent can actually discover them.

We tested this directly in Chrome Canary with WebMCP enabled. document.modelContext returned a live ModelContext object, and document.modelContext.getTools() resolved with all four tools and their definitions. That was the point where the project went from "this should work" to "we can prove it works."

We also hit a frustrating deployment issue when our LLM provider deprecated the model we were using. The actual fix was small, but a stale deployment initially kept serving old code, making the problem much harder to diagnose. It taught us to verify the actual deployed commit and runtime behavior, rather than assuming a successful push means the newest code is live.

Accomplishments that we're proud of

We are proud that DishDecider is not just a UI calling an AI API — it is a genuinely agent-native page with a browser-discoverable WebMCP tool registry.

We also got real multi-participant conflict resolution working across separate sessions: two participants, two agents, one shared event, and a genuine conflict detected and resolved with a specific explanation. The result is visible to both participants in real time rather than being a scripted demo.

What we learned

We learned that "does it work?" and "did we verify it works?" are very different questions. With an experimental standard like WebMCP, assumptions can easily look correct until you test the actual browser behavior.

We also learned that building an agentic application is not just about getting an LLM to produce a good answer. The interesting engineering problem is connecting that reasoning to structured tools, shared state, validation, and observable actions.

What's next for DishDecider

The underlying pattern is not specific to potlucks. Multiple people independently contributing to a shared, constraint-aware plan could also apply to roommate expense management, group trip planning, or gift coordination.

Longer term, we would like to test DishDecider with a real external WebMCP-aware agent completing the workflow through natural conversation. That would take the project from proving that our tools are technically discoverable to proving the full agent → tool → shared state → resolution loop end-to-end with an independent agent.

Built With

Share this project:

Updates

Submission history