Linklore MCP

What linklore/linklore-mcp MCP server does

The linklore/linklore-mcp MCP server provides an agent-operated memory layer for software projects. It separates records into two types: lore for decisions, pitfalls, and journal-style knowledge, and docs for specifications and plans. Both types can be connected to source files and to one another, allowing an agent to recover context around a code area or follow a document sequence.

Entries remain in the project’s .linklore directory, backed by a local SQLite store. The local-first setup does not require an account to begin. Agents can create, search, edit, supersede, trash, restore, and inspect the history of records through MCP tools. A session-start brief reports open items, recent activity, and hotspots so an agent can load relevant context before changing code.

How it works

Install the published llre package and run it through uvx; the repository itself is not the standalone build target because some core modules are distributed as compiled extensions. Register the process in an MCP client, initialize the project once, and then let the agent use the tools during its normal coding loop.

The show tool supports searches by text, tag, status, file, source, and time period. doc_flow renders a document’s ordered chain, doc_map shows the document link network, and doc_rollup gathers lore connected to a document into a draft summary. status uses git-diff information to identify possible code-to-document drift. doctor checks project data integrity, while cleanup finds likely duplicate entries.

Links can be mutual relationships, ordered document flow, supersession relationships, or stored verdicts that mark items as unrelated or distinct. This supports both knowledge retrieval and maintenance of evolving specifications.

Setup and configuration

For the linklore/linklore-mcp MCP server, add an MCP entry that runs uvx llre. For example, an MCP configuration can use uvx as the command and llre as its argument. Cursor and Windsurf are explicitly listed as usable MCP clients in the setup guidance. After registration, run uvx llre init from the project root, or call the init tool to create the local footprint.

Initialization may accept a blueprint, and project_dir can initialize another folder. Pinning is separate: configuring a project directory does not change the current session’s base project, so use the session pin operation when continued work should target that project.

The server can also configure external sources, identity details, and session settings. Handle, name, and email settings apply machine-wide rather than to one project. Login is not needed for local use; it is relevant to personal backup and team-sharing features.

Tools and capabilities

• Record lore and docs individually or in batches.
• Append content, replace an existing section, overwrite a body, or publish a superseding entry.
• Search by content and metadata, including file, tag, status, and time period.
• Link lore and docs, build document flows, and remove links or stored relationship verdicts.
• Back up and restore the local store through personal server push and pull operations.
• Share copies through invite-only openboxes, or move and copy items between local projects you own.
• Preview or protect destructive operations with trash, confirmation, and recovery workflows.
• Send feedback or bug reports to the LinkLore team.

Limitations and notes

The linklore/linklore-mcp MCP server’s repository is not independently buildable because compiled core modules are absent from the source tree. The published package should be used instead. The repository describes the license as Elastic License 2.0, which permits installation and organizational commercial use but restricts offering the software as a competing managed service, bypassing license-key functionality, or removing licensing notices.

Cloud backup, team synchronization, and cross-owner sharing depend on the LinkLore backend and are not part of the repository itself. Local workspace transfers use filesystem-local operations and should not be treated as a substitute for sharing with another owner or team. Permanent deletion and other destructive actions require an explicit confirmation flow.