Caremesh

An MCP server that lets Alexa+ log check-ins, medication, and care tasks for a loved one, then delivers a Bedrock-generated daily summary and flags anything missed.

Comment

Inspiration

Informal caregiving is coordination work, and it's usually invisible. An adult child checking in on a parent, siblings splitting medication reminders, a home aide covering a rotating schedule: that coordination tends to live in scattered text threads, sticky notes, or someone's memory. There's no shared, low-friction record of "did the check-in happen today" or "was the medication actually taken," and gaps only surface after they've already caused a problem.

Caregiving apps that solve pieces of this already exist and some are genuinely good: Caring Village, Medisafe, CaringBridge. So the interesting question for this hackathon wasn't "does this problem need solving," it was "what changes if the interface isn't an app at all." Every one of those products still asks a tired caregiver to remember to open something and tap through it. I wanted to see what it looks like when logging a check-in or a missed dose is just a sentence you say out loud to an assistant you're already talking to. Because it's built as an MCP server rather than a proprietary integration, the same tools work with any MCP-aware agent, not just whichever one I happened to build for.

What it does

Caremesh is a self-hosted MCP (Model Context Protocol) server for the Alexa+ track. It exposes ten tools an Alexa+ agent (or any MCP client) can call: log_checkin / log_medication to record events by voice, add_care_task / list_care_tasks for a shared to-do list, get_daily_summary, a natural-language summary generated by Amazon Bedrock, get_alerts, and four household-level tools (add_household_member, list_household_members, get_household_summary, get_household_alerts) giving the same coverage across everyone a caregiver looks after at once. The MCP layer also means it isn't locked to Alexa+: any MCP-compatible client can drive the same tools.

How I built it

TypeScript + Node, using the official @modelcontextprotocol/sdk with the Streamable HTTP transport (spec 2025-11-25). Amazon's own Alexa+ resources page links directly to that spec, which confirmed this was the right path rather than a workaround. Bedrock's Converse API turns structured events into a caregiver-facing summary, with a local deterministic fallback whenever AWS credentials aren't present, so the server is always demoable but the Bedrock integration is real, not decorative. Data lives in Amazon DynamoDB (four tables), with DynamoDB Local standing in for it in dev/CI so nothing needs real AWS credentials just to build and test. /mcp sits behind an optional bearer-token check for once this is actually deployed publicly. Beyond the core server: a full test suite, CI on every push, a Dockerfile, and deployment docs for Amazon ECS Express Mode.

Challenges I ran into

The most interesting one wasn't code, it was discovering mid-build that AWS App Runner, my original deployment target, is closed to new customers. AWS's own migration docs pointed to Amazon ECS Express Mode as the replacement, so I pivoted the deployment story there instead, which meant learning the real create-express-gateway-service CLI surface, including how to wire an IAM task role so the container can call Bedrock and DynamoDB without embedding credentials. The other recurring friction was tooling versions: MCP Inspector v1 (still what npx @modelcontextprotocol/inspector installs without @latest) defaults to a STDIO transport with an unrelated placeholder command, which looks like a connection failure rather than a wrong default until you know to switch it.

Accomplishments that I am proud of

  • A fully working, spec-compliant MCP server, verified end-to-end with a real JSON-RPC handshake, MCP Inspector, and a scripted demo client, not just "it compiles."
  • Catching that AWS App Runner is closed to new customers before building a whole submission around a deployment target that would have failed at the finish line.
  • Making the AI integration honest: get_daily_summary's response always states whether it actually used Bedrock or fell back locally.
  • Realizing mid-build that a JSON file store would silently lose all data on every ECS redeploy (Fargate's filesystem is ephemeral) and swapping to DynamoDB before that became a live-deployment surprise.
  • Getting the whole repo to a genuine open-source bar: tests, CI, lint/format, issue templates, Dependabot, architecture docs, rather than a single-file hackathon script.
  • Adding bearer-token auth in front of /mcp before the first real public deployment, not after.
  • Building multi-person household support without duplicating the per-person logic.

What I learned

That the MCP ecosystem's tooling is genuinely usable but still has real rough edges around defaults and versioning. And that designing the Bedrock integration to degrade gracefully made the whole project easier to build, test, and demo incrementally.

What's next for Caremesh

I'd like to register an actual Alexa+ Agent Skill once that path opens up. I also thought seriously about taking add_care_task items like "call the doctor" further and having Caremesh actually place the call. I decided against it, not because it's hard to code, but because it's a completely different project hiding behind a familiar-sounding feature name: a real outbound call means a phone number, something like Amazon Connect or Twilio, an actual script, and consent/robocalling compliance, which isn't a detail you bolt on afterward. That stays an idea for later, done properly, rather than a feature I half-built to check a box.

Built With

Share this project:

Updates

Submission history