Stay Close

Your Home, Within Reach

Inspiration

Many disabled and severely disabled people cannot reliably get up to answer a door, reach a phone, inspect a home event or manage an unexpected delivery. Existing smart-home tools can provide individual signals, but the important context is often scattered across separate apps, devices and people.

StayClose was inspired by a simple question: what if the home could become easier to understand and safer to coordinate from bed, without taking control away from the resident?

The idea also came from the everyday reality of assistance dogs. A delivery driver may not know that a dog is working, a resident may need longer to reach the door, and a trusted person may need to be involved without creating an automatic or alarming escalation. StayClose brings these moments into one calm, consent-first layer.

What it does

StayClose is an accessible Alexa+ MCP companion for people who cannot always get up. It provides a bedside interface for:

• Reviewing a clear home and front-door status.

• Receiving a deliberate assistance-dog signal that starts a check-in workflow.

• Asking a trusted contact for help, with explicit confirmation before the request is recorded.

• Preparing a delivery note that tells a driver to wait, allows the resident more time and avoids distracting or feeding a working assistance dog.

• Switching to bedside mode with larger, easier-to-reach controls.

• Understanding how home, wearable, phone, messaging, care-circle and delivery services could connect through one consent layer.

The prototype has a working self-hosted MCP endpoint at POST /api/mcp. Its current tools are read_home_status, prepare_assistance_request, confirm_assistance_request, simulate_assistance_dog_signal and create_delivery_note.

The ecosystem map shows Alexa+, Ring, Apple Watch, Phone Messages, Uber Eats and WhatsApp/care circles. Alexa+ MCP actions work in the prototype. The remaining services are clearly labelled as planned adapters, roadmap items or user-controlled handoffs rather than being presented as live integrations.

StayClose is not an emergency service. It does not dispatch emergency responders, unlock doors, place orders, send SMS automatically or make medical claims.

How we built it

We built StayClose as a React, TypeScript, Vite and Express application with a self-hosted MCP server. The MCP endpoint uses JSON-RPC over Streamable HTTP, negotiates protocol version 2025-11-25, returns session headers and supports tool discovery and tool calls.

The browser experience acts as a simulated Alexa+ client. It initializes an MCP session, discovers and calls tools, then presents the results as accessible resident-facing actions. The current demo uses deterministic state and browser-session data so that the safety behavior is inspectable and reproducible without requiring Echo hardware, Ring hardware, a paid messaging provider or a delivery account.

The interface uses large controls, keyboard focus states, clear status messaging, reduced-motion support, responsive layouts and a dedicated bedside mode. The product boundary is intentionally visible throughout the experience: simulated home data is labelled, integrations have explicit statuses, and sensitive actions require confirmation.

Challenges we ran into

The biggest challenge was designing a useful accessibility product without overstating what Alexa skills, Ring APIs or emergency services can safely do. It is tempting to describe automatic emergency dispatch, dog recognition, live courier messaging or fall detection, but those claims would be unsafe and technically unsupported in this prototype.

We therefore had to separate three things clearly: what works now, what is a realistic future adapter and what must remain a user-controlled action. That led to a narrower but more trustworthy tool surface.

Another challenge was making an MCP integration feel like a real product rather than a developer demo. The solution was to connect every tool to a concrete bedside moment: understanding the door, asking for a trusted check-in, responding to a deliberate dog signal and preparing a delivery note.

Finally, accessibility could not be reduced to larger text alone. The interface needed a calm visual hierarchy, obvious next actions, reversible flows, confirmation before assistance requests, keyboard support, reduced motion and language that does not speak for or medicalise disabled users.

Accomplishments that we're proud of

We are proud that StayClose communicates its purpose immediately: it is for people who cannot always get up and it helps them understand the home, request trusted help and coordinate everyday arrivals from bed.

We built and validated an actual MCP endpoint rather than a static mock. The prototype completes initialization, exposes tools, executes calls and returns structured results using the required protocol version.

We are also proud of the explicit consent model. A dog signal does not silently contact anyone. A trusted-contact request pauses for confirmation. A delivery note can be prepared without pretending that a driver has received it. The resident remains the decision-maker.

The interconnected service map makes the future product direction tangible. It shows how Alexa+, Ring, Apple Watch, phone messaging, Uber Eats and care circles could contribute different signals or actions while StayClose provides a single, understandable coordination layer.

What we learned

We learned that accessibility features are strongest when they are tied to a specific loss of reach: the inability to get to the door, phone, switch or screen. “Hands-free” is not enough; the user also needs context, confirmation and a safe fallback.

We learned that integration design is partly about restraint. A system that clearly says “this was prepared but not sent” can be more trustworthy than one that appears more automated but leaves the user uncertain about what happened.

We also learned that MCP is a promising fit for a narrow assistant tool surface. It makes capabilities discoverable and inspectable, but authentication, consent, durable audit trails, accessibility semantics and provider permissions remain application responsibilities. MCP should be paired with strict tool definitions and a visible safety policy.

Most importantly, we learned that disabled people should be involved in co-design and testing from the beginning. A production version would need direct feedback from people with different mobility, speech, hearing, vision and cognitive access needs, as well as assistance-dog handlers and carers.

What's next for StayClose

The next step is co-design and usability testing with disabled people, assistance-dog handlers, carers and trusted contacts. We would test whether the language, confirmation flows and alert hierarchy work under stress and with different access methods.

Technically, the next release would add authenticated accounts, encrypted consent records, real caregiver notification providers, verified Ring event webhooks, a native phone and Apple Watch adapter, configurable local emergency-information guidance and carefully scoped delivery-service handoffs.

Those integrations would remain permission-based. Ring events would become readable home context; a watch or deliberate dog-device signal could request attention; a phone could hand off to its native SOS and contact tools; and a delivery provider could receive a user-approved note. None of these should silently unlock, dispatch, order or escalate without the resident's clear intent.

Our long-term goal is for StayClose to become a dependable accessibility layer across the devices and services a person already uses: calm enough for everyday life, explicit enough for safety-critical moments and always designed around the resident's agency.