In Part 1, I built a meal planning system with Claude — preference file, reusable skills, groceries pushed to my Kroger cart. It worked great. For me.

But I was still the only person in the loop.

The Tool Was Mine. The Problem Was Ours.

We already had a family shopping list on Home Assistant — a tablet in the kitchen, an app on our phones. My daughter spots we're low on applesauce? She adds it. My husband wants bread? He adds it.

But my meal planner and the family shopping list lived in two completely separate worlds. Every week I'd generate a grocery list from the meal plan, separately check what the family had added, and manually merge them before ordering.

I needed Claude to just read the Home Assistant list and merge it with the meal plan — one cart, no manual step in between.

Connecting the Dots

All our home stuff — Home Assistant, n8n, Nextcloud — runs on a server in our house. None of it is exposed to the public internet. It's just simpler that way — no security headaches, no public URLs to worry about.

Here's why that matters: Unlike Claude Code, which runs things locally, Cowork is cloud-based — so it can't just reach into my home network. Anthropic's servers have no way to resolve our internal hostnames or route traffic into our house.

I explored a couple of options — Claude's custom connectors, Cloudflare Tunnel — but they all came back to the same thing: either expose our home server to the internet, or it won't work.

Then I remembered how the Kroger MCP server from Part 1 works — it runs right on my Mac, and my Mac is already on our home network. It can reach everything in the house. I didn't need to expose n8n to the outside. I just needed something on my Mac to pass messages between Claude and n8n.

That's when two pieces clicked together. n8n has a built-in node called MCP Server Trigger that turns any workflow into an MCP endpoint. And mcp-remote is an npm package you add to your Claude Desktop config — same config file from Part 1, one more entry — that forwards calls to that endpoint over your LAN.

Claude Desktop (my Mac)
    │
mcp-remote (also on my Mac)
    │ HTTPS over LAN — never leaves the house
    ▼
n8n (home server)
    │
Home Assistant shopping list

"Remote" here means the other side of my Wi-Fi, not the internet. I built two n8n workflows behind this: one that reads the Home Assistant shopping list, one that removes items after they've been ordered.

From My Tool to Our Ecosystem

This is the part that surprised me. What started as "I need to plan dinner" has turned into something the whole family uses without even knowing the AI part exists.

My daughter and husband interact with Home Assistant — a tablet on the counter, an app on their phones. They add things to the shopping list when they notice something's running low. They don't know or care that on Thursday, Claude reads that list, merges it with the meal plan's groceries, deduplicates, and pushes everything to Kroger.

The system now has three MCP servers working together in one conversation:

1. n8n bridge — reads the family's Home Assistant shopping list
2. Meal planner skills — generates the week's grocery needs
3. Kroger MCP — adds everything to cart

The family's "we need milk" and my "we need 4 lbs of chicken breast" end up in the same Kroger cart. Nobody did any manual merging. The people using it don't even know Claude is involved — they just know there's a shopping list on the kitchen tablet.

What I'd Add to Part 1's Lessons

Your home network is an underrated AI platform. If you self-host anything, it can probably talk to Claude through this same bridge pattern. One config entry pointing at your LAN.

The best AI systems are invisible to most of their users. My family interacts with a shopping list, not with Claude. The AI is plumbing, not a product.

Let the system grow from use, not from planning. I didn't architect a "household automation ecosystem." I fixed dinner. Then I connected the shopping list. The ecosystem emerged.

So — what's running on your home network that could use a bridge?