How Lore Works

Connection Model

Lore exposes an MCP (Model Context Protocol) server that the user adds to their AI client's MCP configuration. The client signs in through Lore in the browser using OAuth 2.1 and receives its own access token — there is no key to copy or paste, and the MCP URL itself carries no credential. (The older style of URL with a token embedded in it is no longer accepted; a client still using one is asked to sign in again.) From that point, the user's AI assistant can read from and write to the user's knowledge base during normal conversations.

MCP is an open standard that lets AI assistants connect to external tools and data sources. Any AI client that supports MCP can connect to Lore. This includes Claude, ChatGPT (Business, Enterprise, and Edu plans), OpenClaw, and any other MCP-compatible AI client.

Architecture

Each user has an isolated SQLite database, encrypted at rest with a per-user key.
Entry bodies are stored as sections — one row per heading — so reads and edits work at section granularity rather than rewriting a whole entry.
Keyword search uses SQLite FTS5 with BM25 ranking. Search by meaning (semantic search) is the standard search on accounts, with keyword-only available on request; see Semantic Search and Your Data.
AI clients authenticate with OAuth 2.1 (authorization code + PKCE); all tokens are hashed at rest.
Zero LLM cost: Lore does not run any AI models. Lore is a database with well-designed MCP tools. The user's AI provider (Claude, ChatGPT, etc.) runs the AI. Lore stores and retrieves structured data.

The MCP Tool Surface

The tools are the complete interface between the AI assistant and the user's knowledge base, and which ones 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 further tool, resolve_pending_action, is registered with the MCP App but is app-only: the widget calls it when the human presses a button, and it is never in the AI's tool list.

get_manual

Retrieve the user's knowledge base operating manual. The AI calls this at the start of every session. The manual contains the user's entry types, content templates, tag taxonomy, status lifecycle, naming conventions, and preferences — assembled live from the database.

list_entries

Browse the knowledge base with optional filters (type, status, tag, date range). Returns compact summaries — use get_entry to read an entry in full.

search

Search across entry names and descriptions and every section's heading and body, ranked by relevance. Results report which section matched, so the AI can jump straight to it rather than re-reading the entry. On accounts with semantic search enabled, this tool also accepts a natural-language query and matches by meaning; otherwise it matches exact words. Use search for textual queries; use list_entries for structural queries.

get_entry

Fetch a specific entry by its ID — name, type, description, tags, status, source, and timestamps, plus the body as its list of sections, each with the id the AI uses to edit that section alone.

list_sections

Browse section headings across the knowledge base without their content, filtered by entry, tag, type, status, or date. Returns facets showing how the results break down, so the AI can narrow its next call instead of paginating blind. Archived and Completed entries are excluded unless asked for.

get_section

Read one section's full content by its ID. Section IDs come from list_sections, search results, or get_entry.

create_entry

Create a new entry in the user's knowledge base. The AI consults the operating manual for entry types, content templates, naming conventions, and tags. Before creating, the AI searches for existing entries on the same topic to avoid duplicates.

update_entry

Update an existing entry, one section at a time — append to a section, overwrite it, add a new one, or delete one, leaving the rest of the entry untouched. Entry properties like name, type, description, status, source, and tags are updated independently of the body.

configure

Set up or modify the user's knowledge base configuration — first-time setup as a conversational onboarding, and updates to entry types, tags, statuses, naming conventions, and content templates. Renaming a tag, type or status happens in place and carries every entry with it.

The MCP App

On AI clients that support MCP Apps, Lore can put a rendered widget in front of the human instead of text. The MCP App is on for every account by default (it can be switched off per account), and it adds two tools the AI can call, plus one it cannot.

open_entry

Open an entry as a rendered widget for the human to read, when they ask to see it. The widget is read-only for now; edits the human wants still go through update_entry. The AI gets a short receipt rather than the entry; on clients without widget support it reads the entry with get_entry and presents it instead.

review_pending_action

Removing a tag, entry type or status is not something the AI can do on its own. configure queues the removal and reports what it would cost; this tool puts that queued removal in front of the human as a widget — every entry affected, where entries on a removed status or type would move, and a countdown to its one-hour expiry.

resolve_pending_action

Approve, reject or retire-instead. App-only: the widget calls this when the human presses a button, and the AI never sees it in its tool list — which is what makes the approval the human's alone.

Comments

Comments are a margin layer on the reading interface: the human leaves a note pinned to a section — a question, or something they want changed — and the AI answers it on its next session. Accounts with comments enabled see two additional MCP tools, list_comments (read the open threads) and comment (reply, resolve, or leave a note of its own), for 13 in all. Comments are enabled per account and are off for a new account until they are switched on.

The Operating Manual

Every Lore knowledge base has a personalised operating manual assembled from the user's configuration. The AI reads the operating manual at the start of every session by calling get_manual. The manual contains:

Entry types with descriptions and content templates
Tag taxonomy (optionally organised into groups)
Status lifecycle (e.g. Draft, Active, Archived)
Naming conventions for entry titles
User preferences

The operating manual is not static. The manual is assembled live from the database every time get_manual is called. When the user or the AI updates the configuration, the operating manual reflects the changes immediately.

Data Flow

The user connects their AI client to Lore by adding the Lore MCP URL (https://uselore.app/mcp, the same for every account) to the client's configuration and signing in when the client asks.
At the start of a conversation, the AI calls get_manual to read the user's operating manual.
During the conversation, the AI creates, searches, browses, and updates entries as appropriate.
All entries are stored in the user's isolated SQLite database.
The user can browse, read, edit, and archive entries through the Lore web interface.