Skip to main content
Glama
Jessinra

Lorekeeper

by Jessinra
OverviewSchemaRelated ServersScoreDiscussions
Local

docs

pip install lorekeeper-mcp && lorekeeper setup && lorekeeper

Your agent remembers across sessions — and the memory gets better, not just bigger. Local. No API keys. No sign-up. Free to run forever.

Why Lorekeeper

Every AI agent session starts blank. You re-explain context, re-state preferences, re-teach patterns — every single time.

Files like CLAUDE.md and .cursorrules help, but they're hand-maintained, can't search themselves, and grow stale. Cloud services work, but your session data leaves your machine and you're paying per API call. Libraries are powerful, but you're writing the integration yourself.

Lorekeeper is a different shape: a local MCP server you pip install once. It connects to your existing agents, stores memories in SQLite on your own disk, and starts improving with every session:

Agent uses a memory → rates it useful or not →
scores adjust automatically → weak memories decay →
strong memories surface more often → search gets sharper

A fresh install and a six-month-old install are genuinely different products. The longer you use it, the less noise you get — and the more your agents feel like they actually know your codebase.

Related MCP server: supermem

Quick Start

3 minutes, zero configuration:

# 1. Install
pip install lorekeeper-mcp

# 2. Configure your agents (auto-detects Hermes, Claude Code, Cursor)
lorekeeper setup

# 3. Start the MCP server
lorekeeper

lorekeeper setup scans for installed agents and injects the MCP entry, agent prompt, and bundled skills automatically. Use --check to preview without writing. Run lorekeeper --help or lorekeeper --version to verify the install.

Then ask your agent:

"Remember that I prefer curl -vX GET for debugging endpoints."

It calls lore_remember → memory stored. Next session:

"What's my preferred debug command?"

It calls lore_search → memory retrieved. ✅

Full walkthrough → docs/quickstart.md

Features

What

How

Hybrid search

Semantic vectors + BM25 keyword + time-decay + usage frequency + memory score — all ranked by a weighted formula

Self-improving

lore_update feedback adjusts scores. Bad memories fade (<2 confidence + not useful → soft-delete). Good ones rise.

Auto-linking

New memories are automatically linked to their closest semantic neighbor. A lightweight knowledge graph forms without effort.

Duplicate detection

New inserts are checked against existing memories. Near-identical content is blocked (override with force=true).

Dashboard

Full web UI — browse, search, edit, delete. Seven tabs including backup/restore with dedup preview.

Universal MCP

Works with Claude Code, Cursor, Hermes, Copilot, OpenCode — any MCP-compatible agent.

Local-first

Your data stays on your machine. SQLite + LanceDB. No cloud dependency, no API keys.

Namespaces

Multiple agents share one store with isolated namespaces. Writes go to your namespace; reads include the shared pool.

Reflection

Agents auto-extract learnings from sessions. Discoveries and lessons become searchable memories.

Use Cases

Staying in context across sessions

You set up your auth layer on Monday. Wednesday, a different agent starts fresh with no idea. With Lorekeeper, it already knows the middleware path, the token format, and which test covers the edge case — because you told it once.

"Remember that our JWT uses jose middleware in src/middleware/auth.ts
 and refresh tokens expire in 7 days."
→ lore_remember stores it
→ Every future session, on any agent: already in context

One memory pool, multiple agents

Claude Code for review, Cursor for implementation, Hermes for planning — they shouldn't each start from zero. Lorekeeper namespaces let them share one store. One agent's discovery becomes every agent's knowledge.

→ Engineer agent notes a performance quirk in the search service
→ lore_remember stores it under the shared namespace
→ PM agent surfaces it during sprint planning
→ No briefing, no copy-paste

Cross-session debugging

You fixed a subtle CORS bug three weeks ago and your agent helped. Neither of you remembers the details.

"What did we figure out about the CORS issue?"
→ lore_search returns the root cause, the fix, and the context around it

Project onboarding

New repo, new agent session. Instead of re-explaining the architecture, you run a few lore_remember calls after the first session. The next session — and every agent after it — starts with the right foundation.

"Remember: the payment service requires X-Idempotency-Key on all POST requests."
→ Claude Code, Cursor, and Codex all read from the same store

Who It's For

You, if you use:

  • Claude Code and want it to remember project context between sessions

  • Cursor and want persistent agent memory

  • Hermes, OpenCode, Codex CLI, Copilot CLI, or any MCP-compatible agent

  • Multiple agents and want them to share knowledge

Not for you yet, if:

  • You need team RBAC, audit logs, or SSO (coming post-beta)

  • You're building a consumer AI app (we're agent-first, not API-first)

  • You don't use AI coding agents (Lorekeeper is an MCP tool)

How It Compares

There are great tools in this space — each makes different trade-offs. Here's where Lorekeeper sits:

File-based

Cloud services

Docker servers

Library (Mem0)

agentmemory (Node)

Lorekeeper

Setup

Built-in

API key + cloud config

docker compose

Write integration code

npx agentmemory

pip install

Data

Local

Cloud

Local

Your call

Local

Local

Search

grep

Vector

Vector

Vector

Hybrid

Hybrid + time-decay + usage + score

Self-improving

❌

❌

❌

❌

❌

✅ Quality loop

Knowledge graph

❌

Paid

❌

Paid

❌

✅ Free auto-link

Dashboard

❌

✅

❌

❌

Viewer

✅ Full web UI

Dependencies

None

~300MB

~2GB

~1.4GB

~200MB

~1.4GB (embeddings)

Built by agents

❌

❌

❌

❌

❌

✅ Dogfooded daily

Cloud services and Docker-based solutions are strong choices for teams or production apps. Lorekeeper is optimised for the other end: solo developers and agent workflows where zero ops, zero cloud, and a self-improving store matter most.

Dependency note: ~1.4GB is from the sentence-transformers embedding model (PyTorch). This is the same weight class as any local embedding solution. We're honest about it.

MCP Tools

Lorekeeper exposes 10 MCP tools covering the full memory lifecycle:

Tool

Purpose

lore_search

Hybrid semantic + keyword search with relevance scores

lore_remember

Fast one-shot memory save (auto-titles, auto-links)

lore_insert

Bulk structured insert with custom scores and links

lore_update

Feedback loop — rate memories, drive quality

lore_forget

Soft-delete wrong or outdated memories

lore_reflect

End-of-session: extract learnings, auto-save discoveries

lore_processed_sessions

Check which sessions are already processed

lore_recommend_links

Suggest candidate links between related memories

lore_get_suggestions

List pending link suggestions from the sweep engine

lore_review_suggestion

Accept or reject one or more link suggestions (batch)

Full API reference → docs/api-reference.md

Dashboard

A local web UI to browse, search, edit, and manage your memory store.

lorekeeper-dashboard
# → http://127.0.0.1:7777

Seven tabs:

Tab

What it does

Memories

Sortable table with live filter — title, score, confidence, usage, dates

Detail

Edit a memory's content, manage its links, soft-delete or hard-delete

Links

Browse the knowledge graph — source → relation → target

Query

Ad-hoc semantic + keyword searches with per-result score breakdown

Sessions

All processed agent sessions with extracted learnings

Config

Live tuning of search weights, quality thresholds, limits

Backup

Export/import memories as JSON with dedup preview

Suggestions

Review AI-generated link candidates from the sweep engine — accept or reject one-by-one or in bulk

Suggestions Tab

The Suggestions tab surfaces link candidates generated automatically by the background sweep engine. Each candidate is a pair of memories the engine considers related, scored by cosine similarity, BM25 keyword overlap, entity co-occurrence, and temporal proximity.

Workflow:

  1. The sweep engine runs on a configurable interval (LORE_SUGGEST_INTERVAL_HOURS, default 12).

  2. Candidates appear in the Suggestions tab, sorted by score (highest first).

  3. Click ✓ (or select multiple rows + Accept Selected) to create a permanent link between the two memories.

  4. Click ✗ (or Reject Selected) to dismiss — rejected pairs are never re-surfaced by future sweeps.

  5. Use Trigger Sweep on the Config tab to run the sweep immediately instead of waiting for the interval.

Sweep configuration (via LORE_-prefixed env vars or the Config tab):

Setting

Default

Description

LORE_SUGGEST_INTERVAL_HOURS

12

How often the sweep runs (hours)

LORE_SUGGEST_MIN_SCORE

0.55

Minimum weighted score to surface a candidate

LORE_SUGGEST_MAX_CANDIDATES

500

Maximum candidates per sweep run

LORE_SUGGEST_TTL_DAYS

30

Days before unreviewed suggestions are pruned

Lorekeeper Query tab — hybrid search with scores

Built by Agents, For Agents

Lorekeeper is developed using AI agents — Claude Code, Hermes, and our own agent team. The development cycle is itself a working demo of what it does:

agent builds a feature → uses Lorekeeper to capture what it learned →
searches those memories next session →
builds the next feature with the context already there

This isn't a marketing line. Every tool schema, return type, and workflow in Lorekeeper was shaped by agents using it daily — not by humans reading specs. When something was annoying to use, we changed it. When search returned noise, we tuned the weights. The product is what it is because the agents that build it depend on it.

The agentic development loop documented in this repo is how we actually work — and it's what Lorekeeper is designed to support for you.

For Developers

Clone, run from source, or contribute:

git clone https://github.com/Jessinra/Lorekeeper.git
cd Lorekeeper
bash scripts/setup.sh
# Tests
uv run pytest

# Lint
uv run ruff check src tests

# Type check
uv run mypy src

# Dashboard dev
uv sync --extra dashboard
uv run lorekeeper-dashboard

Project Layout

src/lorekeeper/
├── __main__.py          # Entrypoint — init_service() + mcp.run(stdio)
├── server.py            # FastMCP tool definitions (8 tools)
├── config.py            # Settings (pydantic-settings, LORE_ prefix)
├── models.py            # Pydantic models
├── dashboard/           # Web UI (FastAPI + uvicorn)
└── services/
    ├── orchestrator.py  # MemoryService — coordinates sub-services
    ├── memory_engine.py # Vector store abstraction
    ├── lancedb_engine.py# LanceDB backend
    ├── link_store.py    # SQLite — memories, links, suggestions
    ├── keyword_index.py # BM25 index
    ├── search.py        # Hybrid ranking
    └── ...

Key Configuration

All settings via LORE_-prefixed env vars or the dashboard Config tab:

Variable

Default

Description

LORE_DATA_DIR

~/.lorekeeper

Data directory (SQLite + vectors)

LORE_NAMESPACE

shared

Agent namespace — writes scoped, reads union with shared

LORE_SEARCH_LIMIT

5

Default result count from lore_search

LORE_LINK_TOP_M

10

Max candidates returned by lore_recommend_links

LORE_LINK_SCORE_THRESHOLD

0.3

Minimum score for link candidates to surface

LORE_LINK_TEMPORAL_TAU_DAYS

30

Decay half-life for temporal proximity scoring (days)

Full list → src/lorekeeper/config.py and CLAUDE.md.

Performance

All 500 LongMemEval-S questions, default hybrid weights (sem=0.45, kw=0.30):

Metric

Value

Latency

R@1

84.6%

32.9 ms/query

R@3

93.6%

R@5

96.6%

R@10

98.8%

Full per-category breakdown → docs/research/2026-06-11-retrieval-benchmark-results.md

License

Apache-2.0 — see LICENSE.

Built by agents, for agents. Manifesto · Strategy

Last verified: 2026-06-20

Available Tools

10 tools
lore_forgetA

Soft-delete one or more memories by ID.

Memories are marked soft_deleted=1 and excluded from future search results. This is reversible at the DB level but no undelete tool is exposed in v1.

ParametersJSON Schema
NameRequiredDescriptionDefault
reasonNoWhy this memory is being forgotten. One of: ``"duplicate"``, ``"hallucinated"``, ``"outdated"``, ``"expired"``, ``"unspecified"``.unspecified
memory_idsYesList of lore_ids to forget. Must not be empty.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses the soft-delete behavior, the marking of soft_deleted=1, exclusion from search, and the fact that undeleting is only possible at DB level.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words, front-loaded with the main purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a delete operation, the description covers the action, side effects, and a key behavioral note (no undelete tool). Output schema is present, so return values need not be explained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema covers 100% of parameters with descriptions. The tool description adds no new information about parameters beyond the schema, meeting the baseline but not exceeding it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'soft-delete' and the resource 'memories by ID', distinguishing it from sibling tools like lore_insert or lore_search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the effect (soft deletion, exclusion from search) and notes irreversibility via tool, but does not explicitly advise when not to use it or compare to alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lore_get_suggestionsA

Retrieve pending link suggestions for review, sorted by quality score.

Returns the top candidates from the sweep engine's pending queue. Use lore_review_suggestion to accept or reject them.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax suggestions to return (default 20, capped at 100).
min_scoreNoMinimum weighted_score filter, 0.0-1.0 (default 0.0 = all).

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool returns top candidates from the pending queue sorted by quality score, implying a read-only operation. This is sufficient for a simple retrieval, though it does not explicitly confirm non-destructive behavior or any authorization needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, consisting of only two sentences plus a usage hint. It is front-loaded with the main purpose, and every sentence contributes value without any redundant or extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, the presence of an output schema (so no need to explain return values), and good schema coverage, the description is largely complete. It provides the core purpose, a usage guideline, and references the sibling tool. It does not cover edge cases or prerequisites, but for this straightforward retrieval, it is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both 'limit' and 'min_score' parameters already well-documented in the input schema. The description adds little beyond what the schema provides, such as noting the 'quality score' sorting. Hence, the description adds only marginal value, fitting the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Retrieve' and clearly identifies the resource as 'pending link suggestions' sorted by quality score. It distinguishes itself from the sibling tool 'lore_review_suggestion' by implying a sequential workflow, making the tool's purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells the agent to use 'lore_review_suggestion' for acceptance or rejection, providing a clear next step and some context on when this tool is appropriate. However, it does not explicitly state when not to use this tool or mention alternatives beyond the one sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lore_insertB

Insert memories and/or links into the store.

Each memory dict must include:

  • title (str, required): short unique label for the memory

  • content (str, optional): the full text to store

  • description (str, optional): brief summary

  • score (float, optional, default 5.0): initial quality score 0-10

  • source_type (str, optional, default 'observed'): provenance tag. One of: observed, inferred, user_stated, consolidated, injected.

  • links (list[dict[str, Any]], optional): inline links to create after insert. Each link dict: {target_memory_id (str, required), relation_type (str, required), reason? (str)}

Each top-level link dict must include source_memory_id, target_memory_id, relation_type, and reason.

ParametersJSON Schema
NameRequiredDescriptionDefault
forceNo
linksNo
memoriesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It states 'Insert' indicating a write operation, but lacks details on side effects, authorization needs, or whether existing memories can be overwritten (force parameter is not explained).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with bullet points and front-loads the main action. It is moderately long but each part adds value. Could be slightly more concise by removing redundant phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Provided output schema exists but description does not mention return values. Details for memories and links are thorough, but missing explanation of 'force' parameter. For an insertion tool, this is adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but description compensates well for 'memories' and 'links' parameters by specifying required fields and optional fields with defaults. However, it does not mention the 'force' parameter, leaving its role unclear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Insert memories and/or links into the store.' It details the specific structure of memory dicts and links, distinguishing from sibling tools like lore_search or lore_forget by focusing on insertion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for inserting data, but does not explicitly state when to use this tool versus alternatives like lore_update or lore_reflect. No when-not scenarios or alternative tool mentions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lore_processed_sessionsA

Return all session IDs that have been marked as processed via lore_reflect.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It states a read operation (returning IDs) but does not mention safety, side effects, or access requirements. The description is minimal but adequate for a simple retrieval tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, no wasted words. Efficient and front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 0 parameters and existence of an output schema, the description is largely sufficient. It could mention that it returns all processed session IDs, which it does. Lacks detail on potential pagination or limits, but for a simple tool it is complete enough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so schema coverage is 100%. The description confirms that no filtering is possible, which aligns with the schema. Baseline for 0 parameters is 4, and the description adds no unnecessary details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Return', the resource 'session IDs that have been marked as processed', and the condition 'via lore_reflect'. It effectively distinguishes from siblings like 'lore_reflect' which marks sessions as processed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage after 'lore_reflect' has been called, but does not explicitly state when to use or when to use alternatives. No guidance on exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lore_reflectA

Reflect on a completed session — save what you learned.

Minimal usage: pass session_id and summary. That's enough. The rest are extras for when you discovered something substantial.

ParametersJSON Schema
NameRequiredDescriptionDefault
topicNoDomain or topic area (e.g. ``"lore_search refactor"``).
summaryYesShort summary of what happened in the session (required).
decisionsNoKey decisions made, with rationale.
task_typeNoOptional category for the session (e.g. ``"build"``, ``"debug"``, ``"review"``, ``"design"``).
memory_idsNoIDs of existing memories this reflection relates to.
session_idYesUnique session identifier (required).
auto_insertNoWhen True (default), automatically inserts each item in ``factual_discoveries`` (score 7.0) and ``lessons_learnt`` (score 8.0) as standalone memories. Duplicate-guarded. Returns created IDs in ``memories_created``.
session_dateNoISO date string (e.g. ``"2026-06-02"``). Defaults to today.
good_patternsNoPatterns that worked well and should be repeated.
what_was_doneNoLonger narrative of the work completed.
lessons_learntNoList of lessons to propagate to future sessions.
factual_discoveriesNoNew facts to record — stored as bullet text in the reflection. Also auto-inserted as memories when ``auto_insert=True``.
user_profile_updatesNoUpdates about the user's preferences or context.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It does so by explaining the auto_insert parameter, which automatically inserts memories with specific scores and duplicate guarding. This is a significant side effect clearly communicated. However, it does not mention other potential behaviors like authorization requirements or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences that immediately convey the purpose and minimal usage. Every sentence is essential and well-structured, with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 13 parameters, 2 required, and the presence of an output schema, the description is reasonably complete. It addresses the core purpose, minimal usage, and the auto_insert behavior. However, it could be improved by noting expected return values (though output schema exists) or conditions for use versus other tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with all parameters having descriptions. The tool description adds value by emphasizing minimal usage (session_id and summary) and characterizing other parameters as 'extras', which helps prioritize. But it doesn't add significant new meaning beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool is for reflecting on a completed session and saving learnings. It uses specific verbs (reflect, save) and resources (session, summary). However, it does not explicitly differentiate from sibling tools like lore_insert or lore_remember, which might also involve saving information. The context of 'session' provides some distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear minimal usage ('pass session_id and summary') and notes that other parameters are extras for substantial discoveries. This implies when to use the tool (after a session) but does not offer guidance on when not to use it or how it compares to alternative tools like lore_insert or lore_remember.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lore_rememberA

Capture a thought instantly — one fact, one call.

Use this when you discover something worth keeping: a decision, a bug root cause, a user preference, a pattern.

Minimal effort, high reward. Your future self will find this useful.

ParametersJSON Schema
NameRequiredDescriptionDefault
thoughtYesThe fact or observation to store verbatim.
source_typeNoProvenance tag for this memory. Defaults to ``'observed'`` (extracted from conversation). Other values: ``'inferred'``, ``'user_stated'``, ``'consolidated'``, ``'injected'``.observed

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It only describes the action as 'capture instantly' and mentions 'minimal effort', but fails to disclose side effects (e.g., persistence behavior, deduplication, or auth requirements). The description is too vague for a storage operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, using short paragraphs and imperative tone. It front-loads the purpose and usage, but the motivational third paragraph is not strictly necessary. Overall, it is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is relatively simple with 2 parameters and an output schema (present but unused in description). The description does not mention return values or confirm what happens after capture. It is adequate but could be more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the tool description adds no new information beyond what the schema already explains. The baseline score is 3, and the description does not justify a higher score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the verb 'capture' and names the resource 'thought'/'fact', clearly indicating the tool's action. It distinguishes from siblings like lore_forget and lore_search by emphasizing 'one fact, one call' and storage rather than retrieval or deletion.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool: 'when you discover something worth keeping' with specific examples (decision, bug root cause, etc.). It implies when not to use it by contrasting with sibling tools, but does not provide explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lore_review_suggestionA

Accept or reject one or more link suggestions in a single call.

Processes each suggestion independently — a failure on one does not block the rest. Suggestion rows are never deleted; status is updated to 'accepted' or 'rejected' for audit trail.

On accept: creates a real memory_links row using the suggestion's suggested_type (falls back to 'references' if None or unrecognised).

On reject: marks the suggestion as rejected. Future sweeps skip this pair.

Idempotent per item: double-accept and double-reject both return status='skipped' with an explanatory message.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionYesEither ``'accept'`` or ``'reject'``.
suggestion_idsYesList of suggestion UUIDs to process (one or many).

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses key behaviors: independent processing per item, no deletion of suggestion rows (audit trail), fallback type on accept, and idempotency with 'skipped' status. This covers all critical behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (~100 words) with a clear, front-loaded main action. Each sentence adds necessary detail without fluff. The structure (overview, process details, idempotency) is logical and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (batch processing with side effects), the description sufficiently explains independence, idempotency, status updates, and fallback behavior. An output schema exists further complementing the documentation, so no additional return value info is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the description adds minimal extra meaning beyond the schema. It confirms action values ('accept'/'reject') and that suggestion_ids can be one or many, but these are already clear from the schema types and descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Accept or reject one or more link suggestions'. This specific verb+resource combination distinguishes it from siblings like lore_get_suggestions (retrieval) and lore_recommend_links (generation).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for reviewing suggestions after retrieval, but does not explicitly state when to use this tool versus alternatives (e.g., when to use lore_get_suggestions first). No when-not or alternative tool guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lore_updateA

Rate memories and links after using them. Drives the quality signal loop.

Each memory_feedback dict: {id (str), useful (bool), confidence (int 1-10)}. Each link_feedback dict: {id (str), useful (bool), confidence (int 1-10)}.

useful=True bumps score; useful=False deducts. Confidence scales the delta. Repeated useful=False with low confidence triggers soft-delete. Call after every lore_search to keep scores calibrated.

ParametersJSON Schema
NameRequiredDescriptionDefault
link_feedbackNo
memory_feedbackNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully explains behavior: the effect of useful=True/False, confidence scaling, and soft-delete on repeated false low confidence. It omits error handling and permissions but covers core behavioral traits adequately.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Five sentences, each necessary: purpose first, then detailed feedback structure, then behavioral effects and usage advice. No fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists, the description need not explain return values. It covers parameter structure, behavioral effects, and usage context completely for a feedback loop tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description provides complete structure for both parameters, specifying keys (id, useful, confidence) and types/range. This fully compensates for the schema's lack of detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the verb 'rate' and the resources 'memories' and 'links', clearly indicating the tool's function. It distinguishes itself from siblings by specifying it drives the 'quality signal loop' and is used after lore_search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states to call after every lore_search to keep scores calibrated, providing clear when-to-use guidance. It does not include when-not-to-use or alternative tools, but the context is strong enough for correct invocation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updatesv0.4.0
    • Addedlore_get_suggestions
    • Addedlore_review_suggestion
  2. 8 tool updatesv0.3.0
    • First observedlore_forget
    • First observedlore_insert
    • First observedlore_processed_sessions
    • First observedlore_recommend_links
    • First observedlore_reflect
    • First observedlore_remember
    • First observedlore_search
    • First observedlore_update
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation4/5

Tools are mostly distinct: lore_insert and lore_remember both add memories but target different use cases (bulk vs single fact). Otherwise, each tool has a clear, separate purpose.

Naming Consistency4/5

All tools use consistent snake_case verb_noun pattern with 'lore_' prefix. The only slight deviation is 'lore_processed_sessions' where 'processed' is an adjective instead of a verb, but it still follows the overall pattern.

Tool Count5/5

With 8 tools covering insert, search, update, soft-delete, link suggestion, and session reflection, the count is well-scoped for a memory store server.

Completeness4/5

Core CRUD operations are present, plus advanced features like link recommendation and quality feedback. Missing an undelete tool but it's a minor gap that agents can work around.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jessinra/Lorekeeper'

If you have feedback or need assistance with the MCP directory API, please join our Discord server