A
licenseNot graded
qualityB
maintenanceProvides durable project context for coding agents, including project maps, session history, and explicit memories, all stored locally.
11 npm
7
MIT
hermes-memory-rag
by tomRumi
Provides persistent, searchable memory for Hermes Agent, enabling recall of code locations, wiki knowledge, and session learnings without being limited by the context window.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@hermes-memory-ragrecall how we fixed the memory leak in the worker"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
hermes-memory-rag
Memory for Hermes Agent that does not have to fit in a context window.
The problem this solves
Hermes keeps a small memory file that is placed in front of the model on every message, with a hard size limit. Once the limit is reached, adding a fact means deleting another one, and the deleted text is gone. That is fine for a handful of standing rules. It is not fine for the accumulated knowledge of a project.
This project keeps the knowledge elsewhere and hands the model only what is relevant to the message in front of it. Nothing has to be deleted to make room.
Related MCP server: Agent Memory Engine
What it does
Keeps facts in a local database (Chroma) on your machine. Nothing is sent anywhere.
Splits them into three sets per project, described below.
Answers three kinds of question cheaply: where is this in the code, how does this work, and what did we already learn about this.
Tells a model when its staged learnings should be merged into the project's written notes, and merges them when asked.
Exports everything to plain text files so it can be read, kept in git, and rebuilt on another machine.
The three layers
Each project gets three collections, named rag_<project>__<layer>:
layer | holds | written by |
| the project's source files, split into pieces, so "where is X" does not mean reading files |
|
| markdown pages describing how the project works — the long, written knowledge |
|
| short learnings from sessions: a root cause, a decision and why, a trap that cost time |
|
The memory layer is a staging area, not an archive. When it reaches a threshold, its notes are
merged into the wiki pages and the notes are removed. Written knowledge therefore grows in the wiki,
which is a directory of markdown files you can read and keep in git.
The tools it gives the agent
Served over MCP as a server named hermes-memory-rag:
recall(query, project="", layer="auto", top_wiki=2, top_code=3, top_memory=1) -> str
learn(text, kind="learning", project="", supersedes="") -> str
retire(node_id, reason="", project="") -> str
stats(project="") -> str
ingest_code(root, project="", rebuild=True) -> str
ingest_wiki(wiki_dir, project="") -> strrecall searches wiki, then code, then memory, and returns a bounded amount of text — two wiki
sections, three code pieces and one learning by default, 600 characters each. If it returned more,
every message would cost more. It also searches a cross-project layer last, labelled [global], so a
fact that applies everywhere is reachable without being filed under a project.
learn is idempotent: storing the same text twice changes nothing. When staging reaches ten notes
it reports that a merge is due.
Nothing is deleted
Facts get out of date. The tempting move is to overwrite or delete, which is how a memory system loses the very thing it exists to keep. Instead every note carries a status, and recall returns only live ones:
status | meaning | how it happens |
| current, returned by recall | every write |
| something replaced it; |
|
| withdrawn; nothing replaced it |
|
| moved out of the way when staging overflows | automatic, past the cap |
A replaced or withdrawn fact stays in the store with its text intact, so the change is reversible and
you can still read what the earlier belief was. Recall prints a short id for memory hits — that is
what you pass to supersedes or retire. An unknown or ambiguous id changes nothing and says so,
because marking the wrong fact is worse than doing nothing.
This is also why the staging cap no longer destroys anything: past it, the oldest notes are marked
archived rather than dropped.
Where the data lives
~/hermes-rag by default. Override with HERMES_RAG_STORE.
Keep it on a local disk. Chroma's SQLite write lock breaks across a network or shared-virtual-machine filesystem in both directions, so a store on a mounted share will lose writes.
Settings
All optional; the defaults are the ones above.
setting | default | what it changes |
|
| where the store lives |
|
| which ollama model embeds text |
|
| where ollama is |
|
| where the markdown pages live |
|
| notes allowed in the staging layer before the oldest are dropped |
|
| when a merge is reported as due |
|
| characters allowed per returned hit |
|
| largest piece of text sent to the embedder |
| empty | comma-separated directories whose generated JSON should never be indexed |
|
| which project a directory belongs to |
|
| the model that merges notes into the wiki |
If your project keeps generated JSON indexes or caches in a directory of their own, add it to
HERMES_RAG_SKIP_JSON_DIRS. They are worthless for searching and, because JSON is dense, a
4500-character piece of it can exceed the embedding model's limit.
Which project am I in?
Left alone, the engine names a project after the working directory it happens to be in. That is wrong often enough to matter: two projects can share a directory name, and a session's working directory is not necessarily the project being discussed. A small file removes the guess:
# ~/.hermes/projects.yaml
- path: /home/me/code/site-a
project: site-a
- path: /home/me/code/api-server
project: apiThe longest matching path wins, so a directory inside another can name its own project. With no file, or no match, the directory's name is used as before.
Requirements
Python 3.11 or newer
ollama with
nomic-embed-textpulled (274 MB) — everything is embedded and searched locallyoptionally
granite4:3b(2.1 GB) for the merge step; without it the merge falls back to appending the notes under a heading
Two limits worth knowing, both from nomic-embed-text: it has a hard 2048-token ceiling, and ollama
truncates longer input silently. This is why ingest splits text at 4500 characters and the wiki
pages are split at headings.
Backup and restore
python scripts/export_store.py --out backup.jsonl
python scripts/restore_store.py --in backup.jsonl --store ~/hermes-rag --force
python scripts/compare_stores.py --a ~/hermes-rag --b /tmp/rebuilt --collection rag_myproject__wiki --query "..."export_store.py writes two files:
backup.jsonl— every fact's text and its labels. Readable, diffable, worth keeping in git.backup.embedding-numbers.jsonl— for every fact, the list of numbers the search compares.
The second file exists because of something measurable: different parts of the store keep their number lists differently — some as the model produced them (list size around 20), some resized to 1. Distance between two lists is measured in a way that notices the difference, so recomputing the numbers from the text does not reproduce the original search order for the resized parts. The first result usually survives; the second and third can swap. Carrying the numbers makes a restore exact, and makes it seconds instead of minutes.
restore_store.py refuses to run when the export was made with a different embedding model, rather
than quietly producing a store that answers differently.
A store written by an older version of this project has notes with no status. scripts/migrate_status.py
fills that in — dry run by default, --apply to write. It only adds fields: nothing is rewritten or
removed, and running it twice changes nothing.
What it stores, and privacy
Everything stays on your machine. Nothing is uploaded. But be clear about what the store contains:
the learnings you deposit, your wiki pages, and excerpts of your project's source files. Treat
~/hermes-rag like a copy of your notes and parts of your code — back it up if it matters, and keep
it out of any repository.
Status
Built and testable: the server (recall, learn, retire, stats, ingest), the status model that makes replacement and withdrawal reversible, the cross-project layer, project attribution from a file of paths, and the scripts for merging, migrating, exporting, restoring and comparing.
Not built yet: the installer, the part that retrieves memory before each message and mirrors the agent's own memory file, the desktop window, and the scheduled jobs. The layout above is the shape the rest will fit into.
Licence
MIT.
Available Tools
6 toolsingest_codeA
Index a repo's source files into the project's code layer. Skips vendored/binary/hidden dirs; deterministic IDs make unchanged chunks idempotent; rebuild=True drops stale chunks of edited files.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| root | Yes | ||
| project | No | ||
| rebuild | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.3/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses meaningful behavioral details: skipped directories (vendored/binary/hidden), deterministic IDs enabling idempotency, and that rebuild=True drops stale chunks. This goes well beyond the tool's name.
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 dense sentences with no filler. The main action is front-loaded, followed by concise, high-value behavioral notes. Every clause earns its place.
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?
With an output schema present and no annotations, the description covers core behavior, idempotency, skip rules, and rebuild side effects. The main gap is the lack of explanation for the root and project parameters, but the overall context is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds useful semantics for rebuild ('drops stale chunks') but leaves root and project unexplained. With three parameters, covering only one is insufficient.
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 names a specific verb and resource: 'Index a repo's source files into the project's code layer.' This clearly defines the tool's function and distinguishes it from the sibling ingest_wiki by specifying repo source files rather than wiki content.
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?
It gives clear context: this tool is for indexing repository source files into the code layer. It does not explicitly state when to avoid it or name alternatives, but the contrast with ingest_wiki is implied through 'repo' vs. wiki.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ingest_wikiB
(Re)index a code-wiki directory (markdown) into the project's wiki
layer. Heading-aware chunking keeps ## sections atomic.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | ||
| wiki_dir | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
B3.3/5.0
Behavior2/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 does reveal the heading-aware chunking behavior and the '(Re)index' wording hints at re-running over existing content, but it does not state what happens to previously indexed data, whether the operation is safely idempotent, or whether existing wiki-layer content is replaced or removed. This is a significant gap for an ingestion/mutation 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?
Two sentences, both purposeful. The first front-loads the action and target, the second immediately provides relevant chunking behavior. There is no filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists and can describe return values, the description is not complete enough for correct invocation: parameter semantics are incomplete for `project`, usage guidance is only implicit, and the mutation/overwrite behavior is undisclosed. An agent would need external knowledge or guesswork to use this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning to the parameters. It clarifies that wiki_dir should point to a markdown code-wiki directory, but it says nothing about the `project` parameter, which remains ambiguous despite having a default. This leaves one of the two parameters essentially undocumented.
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 opens with a specific verb and resource: '(Re)index a code-wiki directory (markdown)' into a defined target, the project's wiki layer. The 'markdown' qualifier and 'wiki layer' clearly differentiate this from the sibling tool ingest_code. An agent can immediately understand what this tool is for.
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 the tool is for markdown wiki directories, which suggests when to reach for it versus ingest_code, but it never explicitly states a when-to-use condition or names alternatives. The usage context is inferred rather than made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
learnA
Deposit ONE learning into the project's episodic memory (staging area). kind may carry a module prefix for consolidation routing, e.g. 'rag:gotcha' or 'config:decision'. Learnings only — routine actions are logging, not learning, and belong in session transcripts.
supersedes names an existing note (the short id recall prints, or a unique
prefix of it) that this one replaces. The old note is marked as replaced and
stops being returned, but is kept, so the change is reversible and you can
still see what the earlier fact was. Use it instead of rewriting history.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | learning | |
| text | Yes | ||
| project | No | ||
| supersedes | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.1/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 disclosure burden. It reveals staging-area semantics, the single-item limit, and the reversible replace behavior of `supersedes` (old note kept, marked as replaced, stops being returned). It does not discuss auth, rate limits, or failure modes, but the core behavioral traits are well covered.
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 dense but efficient: the main action is front-loaded, the scope rule is one sentence, and the `supersedes` paragraph earns its length by explaining reversible behavior. No filler or redundant restatement.
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?
An output schema exists, so return-value details are not required in prose. The description covers purpose, exclusions, `kind` routing, and `supersedes` semantics. The only noticeable omission is the `project` parameter, which is not explained despite being part of the tool's inputs.
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?
Schema description coverage is 0%, so the prose is the only source of parameter meaning. It adds strong semantics for `kind` (module prefix examples like 'rag:gotcha') and `supersedes` (how to address an existing note and what replacement does). `text` is implied, but the `project` parameter is never explicitly mapped or explained, leaving a small but real gap.
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 opens with a specific verb and resource: 'Deposit ONE learning into the project's episodic memory (staging area).' It also sets a clear scope with 'Learnings only,' which separates it from routine logging. It does not explicitly name sibling tools like recall or ingest_code, so it stops just short of a full 5.
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 gives an explicit when-not-to-use rule: routine actions are logging, not learning, and belong in session transcripts. It also advises using `supersedes` instead of rewriting history. However, it does not name alternatives among the sibling tools, so the guidance is useful but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recallA
Layered context recall for a project: wiki (map) → code (detail) →
memory (prior session learnings). Bounded output; honest per-layer status.
project defaults to whatever the projects file says the working directory
belongs to, falling back to its name; layer = auto|wiki|code|memory.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| layer | No | auto | |
| query | Yes | ||
| project | No | ||
| top_code | No | ||
| top_wiki | No | ||
| top_memory | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the transparency burden and provides useful behavioral detail: output is bounded, per-layer status is reported honestly, and project resolution defaults to the projects file with a fallback. It stops short of describing auto-layer behavior or side-effect guarantees, but recall semantics imply read-only use.
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?
Three sentences with no filler; the layered pipeline is stated first, then behavioral guarantees, then parameter behavior. Every sentence contributes information beyond the schema.
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 description covers the core workflow and project/layer resolution, and an output schema exists to cover return shape. However, the top_* parameters and the meaning of `auto` are left to inference, which is a gap for a tool with no annotations and 0% schema description coverage.
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 has 0% description coverage, so the description must compensate. It meaningfully explains `layer` values and the `project` default, but the top_code/top_wiki/top_memory parameters are not explicitly linked to output counts, and `auto` behavior is not detailed.
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 states a specific retrieval action ('recall') over a clear resource ('project context') and defines the three layers in order (wiki → code → memory). This makes it distinguishable from the sibling ingest/learn/retire tools without needing their schemas.
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 intended use is clear: retrieve layered context for a project, optionally restricting by layer. It does not explicitly name alternatives or when-not conditions, but the context is specific enough for an agent to select it over write-oriented siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
retireA
Withdraw a memory note that nothing replaces — a fact found to be wrong, or one that no longer applies. The note stays in the store (so the withdrawal is reversible and the history readable) but recall stops returning it.
node_id is the short id recall prints, or any unique prefix of it. An
ambiguous or unknown reference changes nothing and says so.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | ||
| node_id | Yes | ||
| project | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does well: it discloses that the note remains in the store, that withdrawal is reversible, that history stays readable, and that recall stops returning the note. It also states that ambiguous/unknown references change nothing and say so. It omits permission or authentication details, but those are not essential for basic invocation.
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 tight and well-organized: the first paragraph establishes purpose and behavioral outcome, and the second paragraph focuses on parameter semantics. Every sentence contributes meaningful information with no repetition of schema details or filler.
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?
For a tool with no annotations and zero schema description coverage, the description covers the core behavior and the critical node_id parameter well. However, it leaves reason and project unexplained, and while an output schema exists, the agent is still missing enough parameter context to confidently construct calls that use those fields. Overall it is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all parameters. It thoroughly explains node_id (short id from recall, unique prefix, ambiguous/unknown behavior), but reason and project are completely undocumented in both the schema and the description. This leaves two of three parameters underspecified.
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 a specific verb ('Withdraw') and resource ('a memory note') and clearly scopes it to facts that are wrong or no longer apply. It also distinguishes the tool from siblings by explaining how recall stops returning the note, so an agent can tell retire apart from recall and learn.
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 gives clear criteria for when to use the tool: when a fact is wrong or no longer applies. It also explains the behavior for ambiguous or unknown references. It does not explicitly name alternatives like 'use recall to find the node_id' or 'use learn to add a note,' so some exclusion guidance is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
statsC
Layer counts + wiki-earn suggestion for a project. The suggestion rule: (≥3 sessions AND ≥5 learnings) OR (≥3 architecture-phrased recalls) on a project with no wiki → suggest generating the wiki.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| project | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
C2.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects and behavior. It reveals that the tool may suggest wiki generation based on session/learning/recall thresholds, which is useful, but it does not state whether the tool is read-only, makes changes, or how it behaves with an unspecified or empty project. No contradiction with annotations exists because there are none.
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 compact and front-loads the core deliverable before diving into the suggestion rule. The second sentence is a dense but well-structured rule. However, the use of undefined terms like 'layer counts' and 'wiki-earn' means brevity comes at the cost of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description omits essential context such as what 'layer counts' refers to, when this tool is the right choice, and what 'wiki-earn' means. The suggestion rule is the only concrete contextual detail. For a one-parameter tool this is passable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the 'project' parameter itself. It mentions 'for a project' and 'on a project with no wiki,' which clarifies that the parameter selects a project, but it does not explain the default '', what format is expected, or what happens with an empty value. Coverage is inadequate given zero schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says the tool provides layer counts and a wiki-earn suggestion, and it gives the precise rule for when to suggest wiki generation. However, 'layer counts' and 'wiki-earn' are undefined jargon, and there is no explicit verb like 'returns' or 'computes,' so the purpose is only moderately clear. It does differentiate from sibling ingest/recall tools by being a stats/analysis operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to call this tool versus siblings like recall, learn, or retire. The suggestion rule hints at a monitoring/health-check use case, but that is left to inference. There are no explicit alternatives or exclusions.
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.
6 tool updates
v0.1.0- First observed
ingest_code - First observed
ingest_wiki - First observed
learn - First observed
recall - First observed
retire - First observed
stats
TDQS
A3.6/5.0
Scored across 6 tools
Disambiguation5/5
Each tool targets a distinct operation: recall retrieves, learn writes, retire soft-deletes, stats summarizes, and ingest_code/ingest_wiki index different source types. There is no meaningful overlap or ambiguous boundary between them.
Naming Consistency3/5
Most names are lowercase and readable, but conventions are mixed: recall/learn/retire are bare verbs while ingest_code/ingest_wiki use verb_noun, and stats is a noun rather than an imperative verb. The pattern is not uniform, though it is still easy to parse.
Tool Count5/5
Six tools is a well-scoped size for a memory/RAG server; each tool earns its place by covering a distinct lifecycle step. The count is neither bloated nor too thin.
Completeness5/5
The tool surface covers the full cycle: ingesting wiki and code, storing learnings, recalling context, soft-withdrawing obsolete notes, and inspecting project state. Update is handled through learn/supersedes and re-ingestion, so there are no obvious dead ends.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Project memory, semantic code search, and grounded agent context.
Project memory for coding agents: requirements, decisions, code graph and delivery telemetry.
Universal persistent memory and knowledge retrieval layer for AI agents and LLMs.
Related MCP Servers
- AlicenseAqualityCmaintenanceProvides coding agents with persistent, evidence-backed project memory and knowledge across sessions, using a structured memory tree and local knowledge base.6124MIT
- AlicenseBqualityCmaintenanceProvides persistent local memory for AI coding sessions, enabling agents to save and retrieve project context across different tools and sessions.16MIT
- FlicenseNot gradedqualityBmaintenanceEnables multiple Hermes agents to persist and retrieve shared knowledge via a local graph-based memory system, supporting hybrid search, entity context exploration, and memory management.-