Cura Home

Not just an assistant that answers, but one you can trust to get it right — with verified troubleshooting, warranty intelligence, and reliable service support.

Comment

Cura Home — Your Conversational Home-Care Concierge

Inspiration

Home appliances are essential to everyday life, but when something goes wrong, getting help can be surprisingly frustrating. A washing machine displays an unfamiliar error code, a refrigerator stops cooling properly, or a dishwasher refuses to start. Customers are often left searching through manuals, navigating support websites, checking warranty documents, and trying to arrange a service appointment across multiple disconnected systems.

We wanted to make this experience simpler, more conversational, and more helpful.

Cura Home was inspired by the idea that getting help with a home appliance should feel as natural as asking a knowledgeable home-care assistant for help. Instead of forcing people to navigate multiple websites or repeat the same information to different support channels, Cura Home brings appliance identification, troubleshooting guidance, warranty checks, service scheduling, and request tracking into one continuous conversation.

Our project is built for the Alexa+ hackathon, where we are exploring how conversational AI and the Model Context Protocol (MCP) can connect intelligent assistants to useful, real-world services.

Our vision is to move beyond assistants that simply answer questions and build one that can help people take meaningful action. When a user says, “My washing machine is showing error E3. Can you help?”, Cura Home should guide them from an initial problem description to relevant troubleshooting steps and, when necessary, a traceable service request.

What it does

Cura Home is a conversational after-sales assistant for home appliances. It is designed to turn an everyday appliance problem into a guided, actionable support experience.

A user can describe a problem in natural language without needing to know which support process to follow. Cura Home then coordinates the relevant tools to identify the appliance, retrieve appropriate guidance, check warranty eligibility, find service appointments, and track the resulting request.

The first milestone focuses on six core capabilities:

  1. Appliance identification — find_product

Identifies an appliance using the details provided by the user, such as its product type, model number, or other identifying information.

  1. Guided troubleshooting — get_troubleshooting_steps

Retrieves model-specific troubleshooting instructions and presents clear, safety-conscious steps. The goal is to help users understand what they can reasonably check themselves and when professional assistance is more appropriate.

  1. Warranty verification — check_warranty

Checks simulated warranty information and explains whether the appliance appears eligible for service under the available sample data.

  1. Service appointment discovery — find_service_slots

Finds available appointment windows from the service-slot dataset, allowing users to explore suitable options instead of starting a separate search.

  1. Service request creation — create_service_request

Creates a traceable service request after the user explicitly confirms the details. This ensures that consequential actions are not performed without the user's confirmation.

  1. Request tracking — get_case_status

Retrieves the status of an existing service request so that users can follow up without repeating the entire support process.

Example user experience

A user might begin by saying:

“My washing machine is showing error E3, and I don't know what to do.”

Cura Home would guide the conversation through a sequence of connected actions:

  • Identify the washing machine and establish the relevant model information.
  • Retrieve troubleshooting guidance applicable to that model and error.
  • Explain the available warranty information and any relevant limitations.
  • Find suitable service appointment windows if further assistance is needed.
  • Present the proposed service request and obtain the user's confirmation before creating it.
  • Provide a reference for the request and allow the user to check its status later.

The intended result is a single, coherent support journey rather than a collection of disconnected answers.

For the initial demonstration, appliance records, warranty information, and service appointments will use realistic sample data. These simulated integrations will be clearly identified, rather than being presented as connections to real manufacturers or service providers.

How we built it

Our architectural decision is to build a real, self-hosted MCP server first and then develop a web application that demonstrates its capabilities. The web application is the demonstration interface; it does not replace the MCP implementation.

1. A self-hosted MCP server

The backend is planned in Python using the official MCP SDK, with Streamable HTTP as the transport.

The server will expose six well-defined tools, each with typed input and output contracts, descriptive tool metadata, predictable business logic, and structured error handling.

This architecture allows an AI assistant or compatible MCP client to discover the available capabilities and invoke the appropriate tools in response to a user's request.

We are targeting the MCP specification version 2025-11-25 or later, in accordance with the Alexa+ hackathon requirements. We will validate the precise version and transport compatibility against the current Amazon documentation during implementation.

2. A web-based conversational experience

The planned frontend uses React and Vite to provide a conversational interface with:

  • A chat interface and conversation history.
  • Structured appliance and troubleshooting results.
  • Warranty information and service appointment options.
  • Clear confirmation steps before creating a service request.
  • Service request references and status information.

The frontend will connect to the actual MCP server through an MCP client. It will discover and invoke the same tools exposed by the backend instead of independently reimplementing the business logic.

This separation makes the application easier to test and keeps the domain logic reusable across compatible clients.

3. Domain data and service workflows

The first version will use realistic sample datasets covering appliance models, troubleshooting information, warranty eligibility, available service slots, and service request records.

The business rules will be deterministic wherever possible, so that the same inputs produce predictable results and the workflow can be tested reliably.

The design also separates simulated services from potential future integrations with manufacturer catalogs, warranty systems, and service providers. This will allow us to introduce real integrations incrementally without redesigning the entire application.

4. Testing and verification

We plan to verify the implementation in stages:

  • Confirm that the MCP server starts locally over Streamable HTTP.
  • Verify tool discovery through tools/list.
  • Test valid and invalid tool inputs.
  • Check error handling, repeated calls, and request-creation behavior.
  • Ensure that the web application invokes the actual MCP tools.
  • Verify that creating a service request requires explicit user confirmation.
  • Document the setup process, environment variables, architecture, and demonstration steps in the repository.

We will use the standard MCP Inspector for protocol-level testing and Amazon's Local Inspector, where available, for Alexa-oriented rendering and readiness checks. These tools serve different purposes and will be treated accordingly.

Our implementation approach is guided by a simple principle: the project should be independently runnable and testable even when access to the live Alexa+ Builder environment is unavailable.

Challenges we ran into

One of the main challenges is designing an assistant that does more than generate plausible-sounding responses. A useful home-care assistant must retrieve the right information, use the correct tool, maintain a coherent workflow, and handle incomplete or invalid inputs without misleading the user.

We identified several challenges that shape our implementation.

Connecting natural language to reliable actions

Users may describe the same appliance problem in many different ways. The assistant needs to identify the information required for each operation and call the appropriate tool with validated arguments.

We are addressing this by defining clear tool contracts, descriptive tool names, structured inputs, and deterministic domain logic.

Making the workflow feel continuous

Appliance identification, troubleshooting, warranty verification, and service scheduling are naturally related, but they are often handled by separate systems.

Cura Home needs to coordinate these steps while preserving relevant context and avoiding unnecessary repetition. We are designing the tools as parts of one end-to-end workflow rather than isolated demonstrations.

Maintaining safety and user control

Troubleshooting instructions must be appropriate to the appliance and must not encourage users to perform dangerous repairs. The assistant also needs to distinguish between guidance a user can follow safely and situations that warrant professional assistance.

Similarly, creating a service request is a consequential action. The application will require explicit confirmation before creating one and will provide a traceable result afterward.

Working within Alexa+ access constraints

The Alexa+ MCP Toolkit is available to select partners, and the documented onboarding and deployment process depends on access to the relevant environment.

We do not currently have the required Alexa+ Builder integration access. Consequently, we cannot claim that Cura Home is already deployed, certified, or connected to the live Alexa+ service.

Our approach is to build and test the MCP server independently, demonstrate its functionality through our own web application, and prepare the integration package for Alexa+ testing when access becomes available.

Demonstrating real functionality with simulated services

A prototype cannot always connect to production manufacturer databases, warranty providers, or service networks. However, simply displaying mock answers would not demonstrate the value of MCP.

We are addressing this by implementing actual tool calls and executable business workflows over clearly identified sample data. This allows reviewers to verify the integration architecture and behavior without confusing simulated service data with live external integrations.

Accomplishments that we're proud of

One of our most important accomplishments so far is establishing a clear, implementation-focused architecture instead of relying on a UI-only prototype.

We have identified the core workflow, defined the six MCP capabilities required for the first milestone, reviewed the relevant Alexa+ development resources, and documented the major implementation and verification steps.

We are particularly proud of the following design decisions:

  • A real MCP-first architecture: The backend is intended to expose working tools over Streamable HTTP, making MCP a functional part of the project rather than a technology mentioned only in the documentation.
  • A complete support journey: The six tools cover the path from identifying an appliance problem to troubleshooting, checking warranty eligibility, arranging service, and tracking the request.
  • Explicit user confirmation: The service-request workflow includes a confirmation step before an action is performed.
  • Independent testability: The backend and demonstration client are designed to work without depending on live Alexa+ Builder access.
  • Transparent integration boundaries: Simulated data will be clearly labelled, and future Alexa+ deployment will not be represented as completed until it has actually been tested.
  • A practical path to expansion: The architecture can accommodate additional appliance categories and real service integrations as the project matures.

These accomplishments establish the foundation for implementation. The MCP server, web application, and automated tests are the next development deliverables; we will validate and demonstrate them as they are built.

What we learned

Our research and architectural planning reinforced several important lessons about building useful AI-powered applications.

MCP is more than a way to connect tools. It provides a structured interface through which an AI client can discover capabilities and invoke them using defined contracts. Designing those contracts carefully is essential to making the application reliable.

A conversational interface is only as useful as the actions behind it. A fluent answer is not enough when a user needs an actual service appointment or a trackable support request. The underlying workflow must produce structured, verifiable results.

Clear separation of responsibilities makes a project easier to test. Keeping the conversational frontend, MCP client, server-side business logic, and domain data separate allows each component to be developed and verified independently.

Safety and confirmation should be part of the architecture. They should not be added as an afterthought. Safe troubleshooting, input validation, clear limitations, and explicit confirmation for consequential actions are important parts of the user experience.

Simulated data can support a meaningful prototype when it is transparent. Realistic sample data allows us to demonstrate complete workflows and test tool behavior without claiming integrations that do not exist.

Finally, we learned to distinguish building a valid MCP application from completing an Alexa+ integration. A working local MCP server is an important milestone, but it does not by itself prove successful Alexa+ deployment, end-to-end testing, certification, or publication.

What's next for Cura Home

Our immediate priority is to turn the documented architecture into a working, independently testable product.

Phase 1: Implement the MCP server

We will build the Python server using the official MCP SDK and Streamable HTTP. The first release will expose all six tools, use typed contracts, return useful structured errors, and implement the core appliance-support workflows using sample data.

Phase 2: Build the web demonstration application

We will develop the React/Vite frontend and connect it to the actual MCP server. The interface will demonstrate a complete conversation, from an initial appliance complaint to a confirmed service request and subsequent status lookup.

Phase 3: Test and document the experience

We will add automated tests for successful operations, invalid inputs, failures, and repeated calls. We will verify tool discovery, confirm that the frontend invokes the real tools, and ensure that request creation requires user confirmation.

The repository will include setup instructions, architecture documentation, environment-variable guidance, sample data details, and a reproducible demonstration workflow.

Phase 4: Prepare Alexa+ integration

When the required developer access is available, we will prepare and deploy the Alexa+ MCP add-on, test the experience in the supported simulator or on an eligible device, address any compatibility and certification requirements, and pursue publication through the appropriate process.

Until that access is available, our focus will remain on independently verifying the MCP implementation and documenting any limitations clearly.

Phase 5: Expand the concierge experience

Once the initial workflow is stable, we can explore real manufacturer and service-provider integrations, broader appliance coverage, richer visual results, and improved personalization.

Our longer-term vision is for Cura Home to become a dependable conversational entry point for household appliance support: an assistant that helps people understand problems, make informed decisions, arrange the right assistance, and follow through without unnecessary friction.

Our goal is simple: turn “Something is wrong with my appliance” into a clear next step and a support journey the user can trust.

Built With

Share this project:

Updates

Submission history