Memory Find

What memory-find does

The memory-find MCP server provides the 🧠 Knowledge & Memory workflow as a local Go binary and one SQLite database per knowledge base. Agents can store markdown documents, record individual facts, search the resulting corpus, and retrieve source material through stable memo:// addresses. Records retain provenance, revision history, trust information, and retirement state.

Search returns a single ranked list rather than separate results for each retrieval method. It can combine word matching, identifier-aware matching, local embeddings, fact matches, and structural entity or graph retrieval when the query calls for relationships. Explain mode adds the ranking contributions, retrieval arms used, recency adjustment, exclusions, and cutoff details. The same search and explanation data is available through the read-only local web UI and terminal commands.

This fits agents that need a private knowledge base for notes, fetched documents, technical references, conversations, or verified facts. The agent must fetch external URLs itself and pass the text to the server; the server does not fetch web pages.

How it works

ingest stores markdown and treats identical content as a no-op while creating a new revision for changed content. remember records an atomic fact with evidence and validity dates. A later fact can supersede an earlier one without removing its history. forget retires documents or facts with a reason, and retired records remain addressable as forgotten but are excluded from search.

The search pipeline applies namespace, kind, source, library, version, tag, date, and minimum-trust filters before ranking. SQLite FTS5 handles stemmed keyword search and whole-identifier matching; a locally run embedding model supplies semantic similarity. Reciprocal rank fusion combines the available lists, then recency, score-gap cutoff, result limits, and token budgets shape the response. Weak semantic-only matches can be rejected so an unrelated query returns no noisy page of results.

read resolves a document, passage, or source from a memo:// address. explore follows entity mentions and their relationships. compact proposes pages, conflict work, stale content, and duplicate names, while submit stores approved derived pages with citations and can show a dry-run diff first. promote requests human approval for trust changes instead of changing trust automatically.

Setup and configuration

Run the memory-find MCP server as memors-mcp serve over stdio for a client session, or use memors-mcp serve --http when several clients need to share a server. The knowledge base is stored at ~/.memors-mcp/kb/<name>.db, or beneath $MEMORS_HOME/kb/ when MEMORS_HOME is set. MEMORS_KB selects the knowledge-base name.

The default embedding model is granite-small-r2, a 384-dimensional IBM Granite model executed locally through a pure-Go ONNX backend. On first use, the model is downloaded from Hugging Face and cached under ~/.cache/memors-mcp/models; after that, the system makes no outbound network calls. The command memors-mcp model ls lists alternatives, including the static potion model.

Tools and capabilities

The MCP interface exposes ten tools:

• ingest, search, and read manage documents and retrieval.
• remember and forget manage facts and document lifecycle.
• promote supports human-directed trust changes.
• explore traverses the entity graph.
• compact proposes knowledge-base maintenance; submit applies selected page or conflict decisions.
• status reports namespaces, model state, pending vectors, jobs, graph counts, and page counts.

The server also exposes MCP resources for documents, chunks, sources, facts, and compact indexes. Its ask prompt turns a conversation into a cited chat over search and read results. A loopback UI presents documents, provenance, histories, facts, entity neighborhoods, pages, status, lint, and the query log without changing the database.

Limitations and notes

The database is local and uses one SQLite file per knowledge-base name. The server itself does not retrieve URLs, and embedding-model download is the documented network activity. The UI is read-only. Page creation remains a proposal-and-submit workflow: compact never writes a page by itself, and derived pages become stale when cited source documents are revised or forgotten. Trust promotion also requires a human or a client interaction rather than an automatic tool-side change.