Forem: Patt S

I Made My Family Dinner AI's Problem — Part 2: Now the Whole House Is In On It

Patt S — Mon, 27 Apr 2026 18:23:09 +0000

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:

n8n bridge — reads the family's Home Assistant shopping list
Meal planner skills — generates the week's grocery needs
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?

I Made My Family Dinner AI's Problem

Patt S — Fri, 17 Apr 2026 19:26:05 +0000

"Hey guys, what do you want for dinner?"

"Whatever."

You know what comes next. You make the "whatever." Then it's "I don't want that."

I cook for three people. I have food allergies. There's a kid whose favorite meal changes daily. And then there's the one who claims he's not "picky." Everyone has opinions. Nobody wants to decide. But somehow it's still my job to figure it out — standing in the kitchen at 5 pm trying to remember what we had yesterday, while mentally filtering out tree nuts, no-go vegetables, and whatever my kid has decided she hates this week.

I was spending more time planning meals than cooking them. So I did what any reasonable, slightly fed-up person would do — I made it AI's problem.

Starting With the Boring Part (That Turned Out to Be Everything)

The first thing I did with Claude wasn't ask it to generate a meal plan. It was to build a preference system.

I know — going through "what do you eat, what can't you eat, what do you hate" for three people feels like paperwork. But this is the part that actually matters. I sat down and worked through a structured document that captured all the rules: who eats what, who's allergic to what, who hates what, what's preferred over the others. But beyond the profiles, I also had preferences as a cook — rules so I don't end up making three different dishes every night:

One protein per meal for everyone. One protein, slightly different sides, different carb bases.

Cook once, eat twice. Every dinner is cooked at 1.5x. Leftovers become the next day's lunch — no cooking, just reheat and assemble. This alone saves me probably 5 hours a week.

Sunday batch cooking. I order groceries once a week to cover most of what we need. Sous vide proteins on Sunday — that covers Sunday through Thursday. Light prep on some vegetables to cut down weekday cook time. Friday is seafood, Saturday is grill night with fresh beef. Two trips to the meat counter per week, at most.

All of this lives in a single meal_preference.md file. It includes dietary profiles, a sauce library, base recipe templates (grain bowls, taco night, stir-fry night, chicken parm night), pantry staples, and a "previous weeks" section so we never repeat a menu.

The technical decision here

I kept everything in markdown — no database, no app. Markdown is the format that works best as context for an LLM. The preference file is the prompt, essentially.

From Conversations to Skills

With the preference system in place, I gave Claude the file and said "give me a meal plan for this week." What came back respected every rule — no tree nuts, no asparagus, spice split between the adults and the kid, sous vide proteins used within their 4-day storage window. Not a generic recipe dump. A real plan.

But here's where it got interesting. I run everything through Claude Cowork, and the first few meal plans weren't perfect. I'd say "swap out Wednesday, my kid won't eat that" or "we need more variety in the sides" or "the leftover flow doesn't work if Thursday is a stir-fry." Each of those conversations taught me what the instructions needed to say more clearly.

So I turned those conversations into skills — reusable instruction sets that Claude loads every time. There's a meal planner skill, a weekly prep schedule skill, a shopping list skill. Each one is basically the distilled version of every correction and refinement from past conversations.

This is why skills matter: without them, every conversation starts from zero. I'd have to re-explain the rules, the preferences, the cooking strategies — every single time. Skills are how the system remembers. They're the difference between "AI that helps once" and "AI that gets better every week." When I improve a skill based on a conversation, every future session benefits. The knowledge compounds.

I could have built a web app with a database. But natural language constraints are more flexible than coded business logic. "My husband is doing a keto week" is a sentence, not a schema migration.

Now, for grocery ordering — my first instinct was Claude in Chrome, just let it drive Kroger.com. It worked, technically. But 50+ items through browser automation chewed through tokens fast. Every click, every page load, every search result to process. That's what pushed us toward building a Kroger API integration instead — direct API calls are cheaper, faster, and don't break when Kroger redesigns a button.

From Meal Plan to Shopping Cart

Like I mentioned, Claude in Chrome could technically do this — but it was slow and token-heavy for 50+ items. I needed something leaner.

So we built a Kroger API integration. Kroger has a public API (developer.kroger.com) that supports OAuth2 authentication, product search, and cart operations. I had Claude build a set of Python scripts:

kroger_auth.py — OAuth2 flow to connect my Kroger account
kroger_stores.py — finds my nearest store by zip code
kroger_search.py — searches for products at my store
kroger_add_to_cart.py — adds items to my cart
shopping_list_to_cart.py — the big one: reads the shopping list, searches for each item, picks the best match, and adds everything to cart

The shopping list file was formatted specifically for Kroger's search — "boneless skinless chicken breast 4 lb" instead of "chicken breasts (8, ~4 lbs)" because Kroger's search works better with product-catalog-style descriptions.

I also had Claude generate a setup guide (KROGER_SETUP.md) in plain English so I could recreate the whole thing if I needed to.

The technical decision here

I went with direct API integration instead of browser automation. I considered using something like Playwright to just drive Kroger.com, and honestly it would have been faster to build initially. But browser automation is fragile — one UI change and it breaks. The API is versioned and stable. The tradeoff is that the Kroger Cart API only supports adding items, not modifying quantities or removing things. Good enough for my use case, but worth knowing.

I also chose Python over Node for the scripts because the Kroger API's OAuth2 flow maps cleanly to Python's requests library, and I didn't need any async capabilities. Simple tools for a simple job.

The MCP Server (Where It Actually Got Good — After Some Wrong Turns)

The scripts worked. But the workflow still had friction. I'd generate a meal plan in a conversation with Claude, get a shopping list, and then have to open a terminal, navigate to the right folder, and run a bash command. It's not a lot of steps, but it breaks the flow. You go from conversational to command-line and back.

So I built a local MCP server. And the build itself was way easier than I expected — but everything around the build was where we got tripped up.

The actual code was almost anticlimactic

MCP — Model Context Protocol — is a way to give AI tools direct access to external services. The Python SDK has a decorator-based API called FastMCP that makes tool definition trivial:

from mcp.server.fastmcp import FastMCP
mcp = FastMCP("Kroger")

@mcp.tool()
def kroger_find_stores(zip_code: str, limit: int = 5) -> str:
    """Find Kroger stores near a ZIP code."""
    # ... your implementation
    return json.dumps({"stores": [...]})`

The docstring becomes the tool description Claude sees. The function signature becomes the input schema. Return a string; Claude parses it. The whole server.py is under 250 lines and covers all four tools plus OAuth token management.

If you've heard "MCP" thrown around and it sounds intimidating — it shouldn't be. The SDK does almost everything. (Full repo on GitHub)

The detour that taught me the most about working with AI

Here's where I need to be honest about a mistake — not a code mistake, a prompting mistake.

When I asked Claude to help me get the MCP server working in Cowork (Anthropic's cloud-based conversational interface), I gave it a general prompt: "I want this to work in Claude Cowork." Claude confidently laid out two elaborate paths — one involving publishing to the MCP Registry with PyPI tooling, the other involving HTTP transport with multi-tenant OAuth deployed to the public internet.

Both sounded plausible. Both were detailed and well-reasoned. Both would have been days of work.

Both were completely unnecessary.

The problem wasn't that Claude was wrong about how MCP used to work. The problem was that MCP is evolving fast, and Claude was building on training knowledge — its understanding of the ecosystem from whenever its data was last updated. Things had changed. The answer had gotten simpler, but Claude didn't know that because I didn't tell it to go check.

What I should have said was: "Before we plan anything, research the most up-to-date MCP documentation and tell me how Cowork actually connects to local servers."

The actual answer? Claude Cowork bridges to your local Claude Desktop. Register your stdio server in Desktop's config, restart, and Cowork can use it. One JSON file edit:

// ~/Library/Application Support/Claude/claude_desktop_config.json (macOS)
{
  "mcpServers": {
    "kroger": {
      "command": "python3",
      "args": ["/absolute/path/to/server.py"],
      "env": {
        "KROGER_CLIENT_ID": "...",
        "KROGER_CLIENT_SECRET": "..."
      }
    }
  }
}

Restart Desktop. Done.

This is the lesson I keep coming back to: AI will confidently build on stale knowledge if you don't tell it to check. It doesn't know what it doesn't know. Especially with fast-moving tools, the answer from six months ago might be completely wrong today. "Research the current docs first" is a better prompt than "here's what I want to build." A vague prompt plus an outdated mental model equals a very convincing plan that wastes your time.

What I'd Tell Someone Starting a Project Like This

Give the AI structure, not just questions. The preference file does most of the heavy lifting. Without it, I'd get generic meal suggestions. With it, I get plans that respect three people's allergies, preferences, and cooking realities. The quality of AI output is directly proportional to the quality of context you provide.

Close the loop to the real action. A meal plan is nice. A meal plan that turns into a shopping list that goes directly into my Kroger cart — that's the difference between a tool I use once and a system I use every week.

Build the simple thing first. Scripts → MCP server was a natural progression. I didn't design it up front — I built the simple thing, used it, felt the friction, and upgraded. Each step was useful on its own. If I'd tried to architect the final version from scratch, I'd still be planning instead of cooking.

Tell the AI to look things up before it plans. I cannot stress this enough. Especially with fast-moving tools. "Research the current docs first" saves you from confidently building the wrong thing.

The Full Pipeline Today

Preferences — meal_preference.md holds all dietary profiles, rules, recipes, and history
Meal Plan — Claude generates a personalized weekly plan from the preferences
Shopping List — Aggregated, categorized, and formatted for Kroger's catalog
Kroger Cart — Pushed directly via MCP server, no terminal required

Thursday, I generate the meal plan. Friday the groceries get delivered. Sunday is meal prep day. The whole thing takes maybe 10 minutes of my time for a week of meals for three people with completely different dietary needs.

Not bad for a markdown file and a bit of Python.

So — what's the thing eating your brain every week? How are you using AI to get through it?