slipbox

A query engine for markdown vaults — one SQLite index, a CLI, and an MCP server, so both you and your AI agents can search the same notes the same way.

• Frontmatter queries — sbx query filters by tags and YAML properties, with folder scoping and sorting.
• Full-text search — sbx search over note bodies (FTS5).
• Semantic search — sbx ask "what did I decide about the database schema?" returns the most relevant notes by embedding similarity (multilingual-e5-small, runs on CPU).
• Wikilink graph — sbx links shows a note's outgoing links and backlinks; sbx orphans finds isolated notes; sbx dangling finds broken [[targets]].
• Safe AI edits — agents queue typed frontmatter edits as proposals (vault_propose); nothing touches your files until you run sbx apply. Every action lands in an append-only audit log.

The index is a single .slipbox.db inside your vault. Everything is stored locally; no data leaves the machine.

Requires Rust (rustup.rs). Build from a checkout:

git clone https://github.com/imaammdev/slipBox.git && cd slipBox
cargo install --path crates/slipbox-cli
cargo install --path crates/slipbox-mcp   # optional, for the MCP server

sbx index ~/vault            # build or refresh the index
sbx stats ~/vault            # summary: files, tags, property coverage
sbx watch ~/vault            # keep the index live as files change

sbx query  ~/vault --tag scifi --tag unread --sort rating --json
sbx search ~/vault "focal point"
sbx ask    ~/vault "what did I decide about the database schema?"

sbx links   ~/vault dune            # outgoing + backlinks (name or path)
sbx orphans ~/vault                 # notes with no links in or out
sbx dangling ~/vault                # broken [[targets]], most-referenced first

sbx propose ~/vault '[{"op":"set_property","path":"Books/dune.md","key":"rating","value":10}]' --origin me
sbx proposals ~/vault && sbx show ~/vault 1
sbx apply ~/vault 1                 # writes to files — the only command that does
sbx audit ~/vault

Wikilinks resolve live at query time — exact path first, then unique note name, else shortest path among same-named notes. Creating or renaming a note re-points every link to it instantly; no reindex needed.

slipbox-mcp exposes the vault to AI agents over stdio JSON-RPC (Model Context Protocol). Nine tools:

vault_schema · vault_query · vault_search_text · vault_ask · vault_read · vault_propose · vault_proposals · vault_links · vault_orphans

For Claude Desktop, add to claude_desktop_config.json:

{
  "mcpServers": {
    "slipbox": {
      "command": "slipbox-mcp",
      "env": { "SLIPBOX_VAULT": "/absolute/path/to/vault" }
    }
  }
}

Agents get read tools plus the proposal queue. The queue is the safety line: agents can queue and list, but apply — the step that writes to files — is CLI-only, so a human pulls the trigger.

One note, Books/dune.md:

---
title: Dune
author: Frank Herbert
rating: 9
status: reading
tags: [scifi, favorites]
---

Paul joins the [[Fremen]]. See [[Books/sequels|the sequels]].

sbx index maps it to four tables in .slipbox.db (SQLite):

files — one row per note (plus size/mtime/hash used to skip unchanged files on reindex):

props — every YAML key in long format: one row per value, so lists expand (tags) and numbers get both forms. No per-key columns, so any frontmatter shape indexes without schema changes:

notes_fts — one row per note: path + body with frontmatter stripped, full-text indexed (FTS5).

links — raw wikilink targets in body order, aliases stripped, one row each:

This is why queries are plain SQL: --tag scifi and status=reading match value_text rows, rating>=4 compares value_number, and author~herbert is a substring scan — all against the same props table.

Benchmarks on a single CPU core (see crates/slipbox-core):

• index: ~0.8 s for 5k notes
• embed: ~60 ms per note chunk
• ask: ~2 s cold (model load), ~10 ms warm

TBD — no license file yet. Add one before making the repo public.