Filesystem MCP Server — expose your local directory to Claude (Karpathy LLM wiki for Home Assistant)

Hi everyone,

I built a Home Assistant addon that exposes a local directory to Claude
(or any LLM agent) via Model Context Protocol (MCP).

Why?

Claude was already connected to my HA via HA-MCP and to my Keenetic
router via my own Keenetic-MCP addon. It could see devices, read logs,
manage automations.

But between sessions — it forgot everything. Every chat started from
scratch.

Then Andrej Karpathy published his LLM wiki idea: a personal knowledge
base in plain markdown files, maintained by the LLM itself. No vector
databases, no RAG. Just a folder of .md files the model reads and writes
directly. 16M views on X — clearly struck a nerve.

I decided to implement this for my smart home.

What it does

The addon runs an MCP server inside Home Assistant that exposes a
directory (e.g. an external USB drive at /media/VAULT) to Claude via
Model Context Protocol.

Combined with HA-MCP and Keenetic-MCP, Claude can now:

  • Read current state of all devices and automations via HA-MCP
  • Read network info via Keenetic-MCP
  • Write structured wiki pages about your setup to the vault
  • Read them at the start of the next chat — and already know the context

The addon auto-creates the vault structure and a CLAUDE.md instruction
file on first run.

Setup overview

  1. Connect an external USB drive to your HA server
  2. Format it as ext4 with label VAULT
  3. Install Samba NAS addon (dianlight) for auto-mounting
  4. Install this addon and configure your token
  5. Expose port 3100 via your router
  6. Add the MCP endpoint to claude.ai as a custom connector

Status

  • :white_check_mark: Tested and working on amd64
  • :test_tube: Beta branch available for aarch64/armv7 (Raspberry Pi) —
    needs testers!

Links

GitHub: GitHub - st412m/ha-filesystem-mcp · GitHub
Karpathy’s LLM wiki: llm-wiki · GitHub

Would love feedback, especially from anyone who tests the beta on
Raspberry Pi or other ARM hardware!

Update: v2.2.1 — multi-arch is now stable :tada:

Back in April this thread asked for Raspberry Pi testers — and it worked. A user filed an issue with a build failure on aarch64, we tracked it down together, and after two rounds of testing on real hardware (Raspberry Pi 4, HA OS 2026.5.x) multi-arch support is now merged and released.

What's new in v2.2.1:

  • :white_check_mark: amd64, aarch64 and armv7 builds — the beta branch is gone, everything is in main now
  • Fixed an instant build failure on Supervisor 2026.04+ (it no longer substitutes a default BUILD_FROM, so the addon now ships a proper build.yaml)
  • No USB drive required anymore — new share:rw mapping means vault_path can point at HA's built-in storage, e.g. /share/vault. The USB+ext4+Samba route from the original post still works and is still recommended for dedicated storage, but on a Pi you can now skip it entirely
  • README reworked: architecture status table, both vault placement options, changelog

So the setup overview for Pi users is now just: install addon → set vault_path: "/share/vault" → set your token → expose port 3100 → add the connector in claude.ai. Two steps shorter than before.

Big thanks to the tester from issue #1 — independently building their own fork, confirming the fix on hardware twice, and suggesting the /share mapping. Open source working as intended.

armv7 builds but hasn't been field-tested yet — if you run it on older ARM hardware, reports welcome!

Neat approach to fix that problem, I have been using mem0 and obsidian to capture the memories I want, and then asking the ha-mcp to recall them. Are we fixing the same problem 2 different ways?

Yes, it's exactly the same, but without obsidian.

1 Like