CoHabby Living

A compatibility-first roommate finder where your browser agent does the structured work through six WebMCP tools, and you keep every human decision.

Comment

Inspiration

Finding a roommate is easy. Finding someone you can actually live well with is hard, and it shapes daily life for a lot of people: traveling nurses, single parents, new graduates, retirees, interns. Rooms are easy to list. Compatibility is what nobody helps with.

CoHabby puts the person first and the room second. I also believe good technology should make people more human, not more mechanical. WebMCP made that concrete: the page can hand an agent real tools and still keep the meaningful decisions on the human side of the screen.

CoHabby is already a live product with real users on the web, iOS, and Android. This challenge build is a separate, new codebase, but the problem it targets and the people it serves are the same.

What people and agents do together

Six small WebMCP tools share one page with the person:

  • get_living_context reads the visible state (the only read-only tool)
  • stage_living_brief stages a living plan from everyday habits
  • find_compatible_rooms brings Maya, Jordan, and Sam onto the page, person first
  • explain_synergy_match opens the Synergy Lens: a 92 score, 88% evidence, three practical reasons
  • compare_shortlist lays two people side by side across six dimensions of daily life
  • prepare_introduction drafts an editable first hello from facts already on the page

Three actions are deliberately not tools: approving the plan, editing the hello, and confirming the introduction. The public tests assert that apply_living_brief and confirm_introduction do not exist. The agent prepares everything. The last click stays with the person.

Why WebMCP fits

Roommate matching is structured work with a few consequential decisions in between. WebMCP lets the page describe each step precisely, so the agent completes it reliably instead of guessing at the UI, and every result renders where the person can see it. Agent and human read the same state, which advances visibly from v1 to v9.

How I built it

Next.js and TypeScript. Every tool has a strict JSON Schema input (bounded enums, patterns, additionalProperties: false) and a separate output schema, so nothing reaches the agent that a person could not see. Each call runs under a combined abort signal: cancel it and it rolls back to its checkpoint and commits nothing. A tool resolves only after the page acknowledges the new state has rendered, so "done" always means "visible." The live footer prints the deployed revision, the repo is MIT, and the judged source is pinned to an immutable tag. Fixtures and Synergy scores are fictional demo data, and the film says so.

This WebMCP app is entirely new work created during the submission period (repository started Sept 1, 2026; every commit is dated inside the window). It shares no code with CoHabby's existing web and mobile products. Only the brand, the mission, and the roommate-compatibility concept pre-date the challenge; CHALLENGE_WORK.md in the repo documents the separation.

Challenges and what I learned

The hardest call was the human boundary. Making everything a tool would have looked more autonomous. It also would have let an agent introduce you to a stranger without asking. The hardest engineering was render acknowledgement: agents move faster than browsers paint, and a tool that returns before its result is on screen creates a page the person and the agent disagree about.

The lesson: small, bounded tools with visible results beat one clever tool, and the best agent-native page is the one where you can tell exactly what the agent did and what you decided.

Built With

Share this project:

Updates