Common Table

• 

  Live Qloo results: a fair restaurant shortlist for two very different tastes.

• 

  Current Common Table landing page and lunch planner.

• 

  Optional Groq name help is unchecked by default and requires consent.

• 

  A Qloo-verified favorite is shown for the diner’s approval before use.

• 

  How Common Table creates a shared lunch shortlist from each diner’s taste.

• 

  Live Qloo restaurant picks with a separate affinity score for each diner.

Inspiration

“Where should we eat?” is a recurring workday decision. Nearby lists tend to optimize for distance or popularity, and group chats can favor whoever suggests a place first. Common Table makes the group’s tastes visible before the team chooses.

What it does

Two to four diners enter a city and named cultural favorites. Common Table returns restaurants found in every diner’s own Qloo results, then ranks the shared options by the harmonic mean of individual affinities. Each card shows individual scores, the lowest fit, and matched taste signals or Qloo tags when available. Affinity is a model score, not a probability.

The group can request another set without current picks, remember a table locally on one device, and open a Google Maps search built from the exact restaurant name and address.

How Qloo is used

Qloo Search resolves each diner’s anchors. The server requests Qloo Insights separately for every person with restaurant and locality filters and explainability data. We intersect Qloo restaurant entity IDs, then rank shared places using their per-person Qloo affinity. We don’t invent restaurant details or claim they are open, bookable, or suitable for dietary needs.

Optional Groq name help

Groq is used only when a user opts in to help with an unmatched named favorite. If Qloo has not resolved another anchor for that diner, the server sends Groq just the unresolved favorite text, without the city or table member names. Groq can propose one possible full entity name. Qloo must verify an exact entity match, and the user must approve that displayed match before it is used. Groq does not choose restaurants, rewrite preferences silently, or bypass Qloo rate limits. Without opt-in, Groq isn’t called.

Agent interface

The hosted app exposes find_shared_lunch over MCP Streamable HTTP. Assistants can call the same Qloo-backed planner used by the web UI and receive shared places, per-diner affinities, tags, and map-search URLs.

Implementation and testing

Built with server-side Node.js, browser HTML/CSS/JavaScript, Qloo Taste AI, optional Groq name help, and MCP, deployed on Vercel. The Qloo and Groq keys remain on the server. The repository has an MIT license and setup instructions.

Fixture tests cover anchor handling, opt-in and opt-out, Qloo verification of Groq candidates, and privacy boundaries. A live production smoke check returned a three-place Bengaluru shortlist with separate affinities; live catalog results can change, and one smoke check is not a reliability guarantee.

What we learned

A favorite name can be too vague or absent from Qloo’s catalog. Treating every string as resolved creates misleading recommendations. We keep Qloo’s exact matching in control and use Groq only as a consent-based candidate helper, with a second human approval before a change.

Limits

Catalog coverage, rankings, and availability depend on Qloo. The app does not verify hours, menus, reservations, or dietary suitability. Users should confirm restaurant details directly.

Built With

• css
• groq
• html
• javascript
• model-context-protocol
• node.js
• qloo-taste-ai-api
• vercel