# Lore
> Persistent memory for your AI

Lore is a hosted, model-agnostic knowledge base that any AI assistant can read from and write to via MCP (Model Context Protocol). AI assistants write structured entries during normal conversations. Users browse, edit, and own everything through a web interface.

## Key Facts
- MCP-native: connects to Claude, ChatGPT, OpenClaw, and any MCP-compatible client
- Model-agnostic: not locked to any AI provider. Users can connect multiple AI tools to the same knowledge base simultaneously.
- AI-writes, human-reads: the AI creates structured entries, the user owns and controls them
- SQLite-backed: one isolated database per user, encrypted at rest. Keyword search via FTS5 with BM25 ranking; search by meaning (semantic search) is the standard search on accounts as of 15 August 2026, with keyword-only available on request.
- Section-grained: entry bodies are stored one row per heading, so reads and edits target a single section rather than rewriting the whole entry.
- Zero LLM cost: Lore does not run AI models. Users bring their own AI provider.
- Conversational onboarding: the AI sets up the knowledge base through a conversation about the user's life and work
- Per-user operating manual: the AI reads personalised instructions (entry types, content templates, tag taxonomy, naming conventions) at the start of every session

## What Lore Is
Lore is a persistent knowledge base for AI assistants. During normal conversations, the user's AI creates structured knowledge base entries — decisions, insights, project specs, research notes, meeting summaries. The user browses and owns everything through a web interface. Lore does not replace the user's AI — Lore upgrades the AI by giving it structured, long-term memory.

## What Lore Is Not
Lore is not a chatbot. Lore is not a notes app. Lore is not a platform-specific memory feature. Lore does not run AI models, and no AI inference happens on Lore's servers. One exception: accounts with semantic search (the standard search since 15 August 2026; keyword-only available on request) have section text and search queries sent to VoyageAI to be turned into vectors and to order results; the ordering step also sends the name, type, and description of each candidate section's entry. See https://uselore.app/docs/semantic-search-and-your-data.

## How Lore Differs from Platform Memory
Platform memory features (ChatGPT Memory, Claude memory) store opaque facts that users cannot fully see, structure, or take with them. Lore stores structured, readable, editable entries organised by type, tags, and status. Lore works across all MCP-compatible AI tools simultaneously. Lore entries belong to the user.

## MCP Tool Surface
Which tools exist is decided per account. A new account sees 11 tools: the 9 core tools below, plus open_entry and review_pending_action from the MCP App, which is on for every account by default. Enabling comments adds list_comments and comment, for 13 in all. One more, resolve_pending_action, is registered with the MCP App but app-only: the widget calls it and the AI never sees it in its tool list.

The 9 core tools:
1. get_manual — Retrieve the user's KB operating manual (entry types, templates, tags, naming conventions). Called at session start.
2. list_entries — Browse entries with filters (type, status, tag, date, sort). Returns compact summaries.
3. search — Search names, descriptions, and every section heading and body; reports which section matched. BM25 ranked by default; also matches by meaning on accounts with semantic search enabled.
4. get_entry — Fetch an entry by ID: metadata plus its body as addressable sections.
5. list_sections — Browse section headings without their content, filtered by entry, tag, type, status, or date. Returns facets. Excludes Archived and Completed unless asked.
6. get_section — Read one section's full content by ID.
7. create_entry — Create a new entry with name, type, content, description, tags, status, source.
8. update_entry — Edit one section at a time (append, replace, create, delete) and update entry properties independently.
9. configure — Set up or modify the KB configuration (entry types, tags, statuses, naming conventions, content templates).

With the MCP App (on by default for every account; can be switched off per account):
- open_entry — Open an entry as a rendered widget for the human to read (MCP Apps / SEP-1865). Read-only for now: the human's edits go through update_entry. The AI gets a short receipt, not the entry; on hosts without widget support it reads the entry with get_entry and presents it.
- review_pending_action — Put a queued taxonomy removal in front of the human as a widget, with the entries it would affect, where entries on a removed status or entry type move on approval, and a countdown to its one-hour expiry.
- resolve_pending_action — Approve, reject or retire-instead. App-only: hidden from the AI's tool list and called by the widget when the human presses a button.

With comments enabled (per account; off for a new account until switched on), two more for the margin-note layer the human writes in:
- list_comments — Read the human's open comment threads, each pinned to a section.
- comment — Reply to a thread, change its status, or leave a note for the human.

Removing a tag, entry type or status is not something the AI can do. configure queues the removal and reports what it would cost; only the human, in the widget, can approve it, and an approval expires after an hour. Adding to the taxonomy already required an explicit yes — removing from it now asks in a way the AI cannot answer on the human's behalf. A status or entry type that entries still use is removed with a destination for them ({ "Draft": "Active" }): approval moves those entries and removes the old value in one step, and a removal that would leave any entry on a value that no longer exists is refused. Renaming a tag, entry type or status needs no approval: it happens in place and carries every entry with it in one step, and a rename onto a name that already exists is refused.

## Architecture
- SQLite per user, encrypted at rest with a per-user key; FTS5 keyword search
- Entry bodies stored as sections (one row per heading)
- Per-account semantic search (VoyageAI embeddings + reranking); standard on accounts since 15 August 2026, keyword-only available on request
- MCP auth: OAuth 2.1 (authorization code + PKCE, refresh rotation); the MCP URL carries no token (URL tokens are retired and no longer accepted)
- Export: the whole knowledge base as one versioned JSON file (lore-export v1), from Settings → Export in the web app or the `lore` CLI (npm package @uselore/cli: `lore login`, then `lore export`). The CLI signs in through the browser; its token can export and cannot act as an AI connection or change the account. Import is planned, not available.
- Web auth: email + password, or Sign in with Google
- All tokens and passwords hashed at rest
- HTTPS with industry-standard security headers
- CORS restricted to Lore application origin

## Links
- Website: https://uselore.app
- Documentation: https://uselore.app/docs
- How It Works: https://uselore.app/docs/how-it-works
- Getting Started: https://uselore.app/docs/onboarding
- Privacy & Security: https://uselore.app/docs/data-and-trust
- Semantic Search & Your Data: https://uselore.app/docs/semantic-search-and-your-data
- The Lore CLI (export): https://lore.uselore.app/docs/cli
- Pricing: https://uselore.app/docs/pricing
- FAQ: https://uselore.app/docs/faq