Homefix Concierge

Home-maintenance concierge that turns a repair request into a persistent, live, user-approved Taskrabbit handoff

Comment

About the Project

Inspiration

Home repairs are often small but stressful. A leaking tap, broken shelf, or electrical issue can interrupt a person's day, and the details needed to get help are easy to forget or repeat.

We wanted to build a home-maintenance assistant that felt natural in a voice-first environment while still giving users a clear visual surface for important decisions. HomeFix Concierge was inspired by the idea that an assistant should remember a user's household context, help organize multiple repairs, find relevant services, and guide the user to a real provider without pretending that a booking happened when it did not.

This made HomeFix a natural fit for the Alexa+ track. Alexa+ can provide the conversational and voice interaction, while the HomeFix MCP App provides durable state, structured tools, live provider information, and a screen-supported workflow for reviewing options and approving an external handoff.

What it does

HomeFix Concierge is a self-hosted MCP App for coordinating household repairs.

The user can:

  • Sign in through Supabase OAuth.
  • Create one private household and save non-sensitive home context.
  • Describe and organize repair requests.
  • View open repairs and previous activity.
  • Discover supported Taskrabbit services through Composio.
  • Retrieve live service availability, pricing, and scoping information when available.
  • Compare returned options against time, location, and budget preferences.
  • Prepare a validated Taskrabbit booking deep link.
  • Explicitly choose Continue to Taskrabbit through the host.
  • Return later and report whether the repair was booked, cancelled, completed, or still unresolved.

HomeFix keeps the distinction between a handoff and a booking clear. Opening a provider link does not prove that a booking was completed, so the application records the handoff as opened and waits for a user-reported outcome.

How we built it

We built HomeFix as one TypeScript MCP server with one React MCP App View. The server is deployed to Manufact Cloud and communicates with a connected MCP host over Streamable HTTP using MCP 2025-11-25.

The main technologies are:

  • mcp-use for the MCP server, typed tools, OAuth provider integration, View binding, Inspector, build, and deployment.
  • React and mcp-use/react for the interactive HomeFix dashboard and MCP App bridge actions.
  • Supabase Auth for OAuth 2.1 authentication, dynamic client registration, and verified user identity.
  • Supabase Postgres and REST for household, profile, repair, handoff, outcome, and activity persistence.
  • Composio for per-user Tool Router sessions and live Taskrabbit MCP capability discovery and execution.
  • Zod for narrow tool input and output schemas.
  • The official MCP TypeScript client for protocol, tool discovery, authentication, and deployment checks.

The server is organized around a few important boundaries:

  1. MCP tools receive authenticated requests and return model-readable content plus typed structuredContent for the View.
  2. Repository methods resolve household ownership from the verified Supabase identity instead of trusting caller-supplied IDs.
  3. The Taskrabbit adapter discovers actual Composio tool schemas and normalizes only fields returned by the provider.
  4. The View stores only temporary interface state. Durable business state remains in Supabase.
  5. Every external handoff requires an explicit user action.

We also added request-size limits, rate limiting, outbound timeouts, state-transition validation, idempotency handling, activity redaction, provider-result expiry, and compiled-View secret scanning.

Challenges we ran into

Making the integration truthful

The most important challenge was avoiding a convincing-looking demo that used invented prices, availability, provider links, or booking states. HomeFix therefore treats live provider data as unavailable when the integration is unavailable. It never replaces a failed Taskrabbit call with a fixture.

Working with a dynamic provider interface

Composio exposes live MCP tools and schemas that must be discovered rather than guessed. We built an adapter that identifies the supported-service, availability, and deep-link capabilities, maps HomeFix inputs to the discovered schemas, normalizes the response, and rejects ambiguous or unsafe results.

Preserving privacy across multiple systems

Household data is private, while the server uses a Supabase service-role credential for backend persistence. We had to make authorization explicit in every repository operation and resolve ownership from the verified OAuth user. The server sends only the location and repair details needed for a Taskrabbit query.

Designing a handoff instead of pretending to book

The provider integration creates a deep link, not a confirmed booking. We implemented separate states for prepared, opened, and user-reported outcomes so the product's language remains accurate.

Verifying the host boundary

MCP protocol tests can prove that the server is reachable and that tool schemas are correct, but they do not fully prove how a particular host renders the View or handles external links. We added automated protocol and security checks and kept the remaining authenticated host walkthrough as an explicit final verification step.

Accomplishments that we're proud of

  • Built a real self-hosted MCP server instead of a standalone simulated web app.
  • Replaced the starter demo with a complete HomeFix MCP App View.
  • Negotiated MCP 2025-11-25 over Streamable HTTP.
  • Added authenticated, household-scoped persistence with explicit onboarding.
  • Implemented idempotent household and repair operations.
  • Added a server-side maintenance state machine that prevents invalid transitions.
  • Connected the product architecture to live Taskrabbit capabilities through Composio.
  • Preserved provider provenance, retrieval timestamps, and the 15-minute freshness rule.
  • Implemented explicit, user-approved external handoff behavior.
  • Added error handling that reports unavailable dependencies instead of fabricating success.
  • Passed typechecking, production build, unit tests, protocol checks, and View secret scanning.
  • Added an Alexa+ runtime compliance explanation and a complete open-source MIT license.

What we learned

We learned that an MCP App is more than a collection of tools. A strong implementation needs a clear contract between the host, server, View, authentication provider, database, and external services.

We also learned that reliability is largely about representing uncertainty honestly. A missing price should remain unknown, an expired result should be refreshed, an opened link should remain an opened link, and an unavailable provider should produce an actionable error.

On the engineering side, we learned the value of validating against the actual installed SDK types, keeping external integrations behind narrow adapters, testing idempotency and state transitions independently, and treating deployment and host behavior as separate verification boundaries from local compilation.

What's next for HomeFix

Our next steps are:

  1. Add richer follow-up reminders and unresolved-repair prioritization.
  2. Support additional service providers while preserving the same provenance and truthfulness rules.

The long-term goal is for HomeFix to become a calm, trustworthy home-maintenance memory: an assistant that remembers the right details, coordinates real services, and never claims more than the available evidence supports.

Built With

Share this project:

Updates

Submission history