Taste Overlap

Two people, a few favourites each. Qloo's taste graph ranks places in your city for each of you and keeps the ones you would both enjoy, with the reason and in evening order.

Comment

Inspiration

Two people plan an evening in a city. One likes Radiohead and Wes Anderson, the other Taylor Swift and Studio Ghibli. If you put all four favourites into one search, you mostly get places that one of them loves and the other puts up with. We wanted the places that fit both of them, a reason for each one, and an order for the evening.

What it does

Each person enters a few favourites: artists, films, shows, books or brands. You pick a city and get up to six places:

  • Real overlaps first. A place counts as an overlap only if it ranks for person A and for person B. Picks are scored by the harmonic mean of the two affinities, so a place one person would merely tolerate drops out.
  • A reason for every pick. It comes from Qloo's own explainability, for example "driven by Radiohead 29% · Taylor Swift 24% · Wes Anderson 24%; taste fit A 85% · B 77%".
  • Honest when tastes don't meet. Qloo returns at most 20 places per call. Two tastes can share none of them, as we measured in Berlin for Daft Punk + Christopher Nolan vs Adele + Pixar. In that case the plan is filled from Qloo's list for the combined taste. Those picks are labelled combined taste and show no per-person bars.
  • An evening, not a list. Something to do first, then food, then a drink.

Without Qloo there is nothing to show. No language model picks or ranks a place.

It is also an agent tool. mcp-server.js exposes the whole plan as one MCP tool, plan_shared_evening. An assistant such as Claude Desktop, Claude Code or Cursor can call it when someone asks "where should my partner and I go tonight in Berlin?". The tool returns the explained evening as text and as structured data. In a live test from an MCP client, Berlin for Daft Punk + Christopher Nolan vs Adele + Pixar returned six places in 12.3 s.

Nothing to install: the live demo also speaks MCP at https://taste-overlap.onrender.com/mcp. In claude.ai or the Claude app you add it as a custom connector, and the assistant can plan a shared evening mid-conversation. Live test: Rome, Pink Floyd vs Audrey Hepburn, six places (five real overlaps) in 21.1 s including the free instance waking up.

How we built it

  • Qloo through the official harness. @qloo/qloo-harness runs against the hackathon endpoint. The hosted app keeps one qloo mcp process (the harness's canonical MCP adapter) running for all requests. qloo exec is the alternative transport.
  • Workflows used:
    • entity_tags once per favourite.
    • recommend (target_type: place, filter_location, explain: true) three times: for A, for B, and for both.
  • Name resolution. Ambiguous names come back as status: needs_input with ranked candidates. The app takes the top candidate, skips albums when another type is offered, retries once with the entity id, and returns that choice.
  • Stack. A dependency-free Node server, a single static page and pure overlap logic. There are 40 tests: the MCP tool server end to end, overlap maths, reasons, the MCP client's failure handling (failed initialize, crashed or stuck process, broken pipe) and an end-to-end replay of a recorded live run.
  • Hosting. Render free tier, with the key stored only as a server-side environment variable. Per-visitor and daily limits protect the event quota.

Challenges we ran into

  • Process start cost. On the free host a fresh qloo exec per call hit our 30 s timeout. With one long-running qloo mcp process, a full plan took 2.7 to 11.3 s in our local runs, and about 21 s on the hosted demo when the instance had to start first.
  • Lists that don't touch. Our first Berlin test returned zero picks because the two personal top-20 lists shared no place. Asking for more than 20 is rejected, and the per-pick explainability splits about 50/50 between the people, so it can't measure balance. The labelled top-up from the joint list was the honest fix.
  • "Harry Potter" resolved to an album. Its first candidate was an album, which contributed nothing to the recommendations. Skipping albums when a film, show or book is offered fixed it: Paris then returned six real overlaps instead of five.

What we learned

  • The harness's needs_input step is worth handling explicitly. Resolving names well matters more than any scoring trick.
  • explainability is the cheapest way to make a recommendation feel trustworthy, because the reason comes straight from the data.

What's next

  • Let users correct an ambiguous match, for example Wes Anderson the director instead of the author entity. The choice is already returned by the API.
  • Opening hours and walking distance for the evening order.

Try it

Built With

Share this project:

Updates

Submission history