unhollow

unhollow

Provides semantic search over project knowledge layers (memories, wiki, docs) using local embeddings, enabling AI coding agents to recall relevant context without external API calls.

Category
访问服务器

README

unhollow

Your coding agent starts every session with a hollow memory. Unhollow it.

Unhollow is a tiny local MCP server that provides semantic search over three layers of project knowledge:

  1. Memories: session-learned facts your agent writes down as it works (hard-won fixes, decision rationale, user feedback, subtle bug causes)
  2. An AI-optimized wiki: dense, retrieval-shaped documentation of every subsystem, generated by the agent itself
  3. Living docs: your architecture plan, design docs, CLAUDE.md, whatever long-form markdown you already maintain

The agent queries all of it by meaning, not filename: memory_search("why is AGC disabled on the mic path") returns the right chunk even if no file mentions "AGC" in its name. Everything runs locally: a 45 MB ONNX embedding model on CPU and a SQLite database. Zero API calls, zero cost, nothing leaves your machine.

The name is an inheritance: this system was extracted from Hollow, a distributed E2EE chat app, where it grew organically over months of agent-driven development. What un-hollows an agent's memory deserved to carry the mark.

Why

Coding agents start every session amnesiac. Project instruction files (CLAUDE.md, AGENTS.md) help, but they have a hard size budget: they are loaded into every prompt, so they can only hold the always-relevant rules. Everything else, the deep subsystem knowledge, the "we tried that and it broke" history, the coupling that silently breaks when violated, either gets rediscovered expensively every session or gets lost.

Unhollow splits knowledge by how it should be recalled:

Layer Lives in Recalled
Always-relevant rules CLAUDE.md / agent instructions every prompt (budgeted)
Subsystem reference the wiki on demand, by meaning
Session learnings memory files on demand, by meaning
Design intent your existing docs on demand, by meaning

This setup has been battle-tested on Hollow (Flutter + Rust, desktop/mobile, ~50 wiki files, hundreds of memories). It is the difference between an agent that re-derives the architecture every morning and one that says "that's covered in couplings_gotchas.md, and there's a memory saying we already tried that."

How it works

memories/*.md ─┐
wiki/*.md ─────┼─> chunker ─> local ONNX embeddings ─> sqlite-vec
docs (plans,   ┘   (split by      (all-MiniLM-L6-v2,      (vector search,
 CLAUDE.md...)      ## headings)    384-dim, CPU)           incremental upsert)
  • Chunking: wiki files and docs split at ## headings; each section is one retrieval unit. Memory files are one chunk each, with their frontmatter name and description prepended for better embedding quality.
  • Incremental reindex: chunks are content-hashed; memory_reindex() only re-embeds what changed, so it runs in seconds.
  • Three MCP tools: memory_search(query, limit), memory_reindex(force), memory_stats().

Quickstart

  1. Copy this repo into your project (e.g. tools/unhollow/) or clone it standalone.

  2. Install dependencies (Python 3.10+):

    pip install -r requirements.txt
    
  3. Configure: copy unhollow.config.example.json to unhollow.config.json and set your paths. Relative paths resolve against the config file. All keys are optional; sources that don't exist are skipped.

    {
      "memory_dirs": ["~/.claude/projects/YOUR-PROJECT-SLUG/memory"],
      "wiki_dir": "wiki",
      "docs": ["../../CLAUDE.md", "../../docs/ARCHITECTURE.md"]
    }
    
  4. Register the MCP server in your project's .mcp.json (Claude Code) or your agent's MCP config:

    {
      "mcpServers": {
        "unhollow": {
          "command": "python",
          "args": ["-u", "tools/unhollow/server.py"],
          "env": { "PYTHONUNBUFFERED": "1" }
        }
      }
    }
    

    On first run the server downloads the embedding model (~45 MB, one time) into models/.

  5. Generate the wiki: paste prompts/generate-wiki.md into your agent at the repo root. This is the highest-leverage step; the prompt encodes everything we learned about making documentation that retrieves well.

  6. Build the index: ask your agent to run memory_reindex().

  7. Make the agent actually use it (do not skip this): paste the block from prompts/agent-instructions-snippet.md into whatever your AI always reads — CLAUDE.md, AGENTS.md, Cursor rules, a custom system prompt. It teaches the agent to search before designing, arguing, or re-investigating, and to reindex after writing. Without it the server sits unused.

What's in this repo

server.py, chunker.py, embedder.py, store.py, config.py   # the MCP server (~400 lines total)
unhollow.config.example.json                              # config template
wiki/                                                     # your generated wiki goes here
prompts/generate-wiki.md                                  # the wiki-generation prompt (start here)
prompts/agent-instructions-snippet.md                     # paste-into-CLAUDE.md block that makes the agent USE the tool
prompts/memory-conventions.md                             # memory file format + index discipline
skills/compush/SKILL.md                                   # session wrap-up skill (see below)

The workflow that keeps it alive

Stale documentation is worse than none. The included compush skill (skills/compush/) is an end-of-session routine for Claude Code: copy it to ~/.claude/skills/compush/ or .claude/skills/compush/ and say /compush when wrapping up. It walks the agent through:

  1. Save/update memories (search first, update instead of duplicating)
  2. Update wiki files the session's changes touched
  3. Touch agent instructions only if a durable rule changed (hard budget enforced)
  4. Reconcile living docs against what the session touched, nothing more
  5. Commit and push (files staged by name)
  6. Reindex

Each step is scoped to the current session, so it stays fast and never turns into an audit.

FAQ

Does it need a GPU or API key? No. Embeddings run on CPU via onnxruntime; a full reindex of a ~2 MB corpus takes well under a minute, incremental reindexes take seconds.

Is my code sent anywhere? No. The only network access is a one-time model download from HuggingFace. Search and indexing are fully local.

Can I use a different embedding model? Yes: set hf_model_id, embedding_dim, and max_tokens in the config. The default (all-MiniLM-L6-v2) is a good speed/quality tradeoff for chunk-sized text.

What if I don't use Claude Code? The server is plain MCP over stdio; any MCP-capable agent can use it. The memory directory format is just markdown with frontmatter, usable from any agent that can write files.

Why not just grep? Grep finds words; this finds meaning. "Why do messages arrive out of order" retrieves the Lamport-clock section even though it shares no words with it. Use both.

License

MIT

推荐服务器

Baidu Map

Baidu Map

百度地图核心API现已全面兼容MCP协议,是国内首家兼容MCP协议的地图服务商。

官方
精选
JavaScript
Playwright MCP Server

Playwright MCP Server

一个模型上下文协议服务器,它使大型语言模型能够通过结构化的可访问性快照与网页进行交互,而无需视觉模型或屏幕截图。

官方
精选
TypeScript
Magic Component Platform (MCP)

Magic Component Platform (MCP)

一个由人工智能驱动的工具,可以从自然语言描述生成现代化的用户界面组件,并与流行的集成开发环境(IDE)集成,从而简化用户界面开发流程。

官方
精选
本地
TypeScript
Audiense Insights MCP Server

Audiense Insights MCP Server

通过模型上下文协议启用与 Audiense Insights 账户的交互,从而促进营销洞察和受众数据的提取和分析,包括人口统计信息、行为和影响者互动。

官方
精选
本地
TypeScript
VeyraX

VeyraX

一个单一的 MCP 工具,连接你所有喜爱的工具:Gmail、日历以及其他 40 多个工具。

官方
精选
本地
graphlit-mcp-server

graphlit-mcp-server

模型上下文协议 (MCP) 服务器实现了 MCP 客户端与 Graphlit 服务之间的集成。 除了网络爬取之外,还可以将任何内容(从 Slack 到 Gmail 再到播客订阅源)导入到 Graphlit 项目中,然后从 MCP 客户端检索相关内容。

官方
精选
TypeScript
Kagi MCP Server

Kagi MCP Server

一个 MCP 服务器,集成了 Kagi 搜索功能和 Claude AI,使 Claude 能够在回答需要最新信息的问题时执行实时网络搜索。

官方
精选
Python
e2b-mcp-server

e2b-mcp-server

使用 MCP 通过 e2b 运行代码。

官方
精选
Neon MCP Server

Neon MCP Server

用于与 Neon 管理 API 和数据库交互的 MCP 服务器

官方
精选
Exa MCP Server

Exa MCP Server

模型上下文协议(MCP)服务器允许像 Claude 这样的 AI 助手使用 Exa AI 搜索 API 进行网络搜索。这种设置允许 AI 模型以安全和受控的方式获取实时的网络信息。

官方
精选