Enables an optional fact-checking tool that uses an OpenAI-compatible model to judge whether memory entries contradict each other, supersede one another, or are independent.
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., "@mcp-memory remember that the release process requires a sign-off from QA"
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.
A persistent memory for AI assistants that is just a SQLite file — and costs about a fifth of what reading markdown notes does.
No vector store, no embeddings, no external service, no API key. Python,
SQLite with FTS5, stdio — the only dependency is the official mcp SDK.
Nothing leaves your machine unless you explicitly turn on the optional
fact check.
Measured over 275 real questions from 89 working sessions: 2,359 tokens
per answered question, against 11,319 for the usual one markdown file
per fact, found with grep and read whole. The gap grows as the memory
does, because every answer here is capped and grep is not. All figures
come from one installation, and the docs say where one did not hold up.
An assistant's memory usually fails in one of two ways: it is a pile of markdown files that has to be read whole to be searched, or it is a vector database that answers that something matched but never why.
This one is a ranked full-text index over short entries, with two things bolted on that turn a note pile into a memory: entries are filed on two axes — where it belongs (project) and what kind of knowledge it is (pitfall, decision, measurement, …) — and when you write something down, the tool tells you which existing entries it overlaps with, so contradictions surface instead of quietly piling up.
Related MCP server: MCPMem
Capped, calculable answers — a search returns eight preview lines
of about 1.2 KB in total instead of 4.2 KB of full text; zeige then
fetches the entries you pick, about 6,000 characters per call unless
you ask for everything. The worst case is known before you ask.
It learns from its own failures — when a search is followed by fetching an entry, that pair is remembered. Ask the same thing again and the entry that answered last time comes first. Word-for-word repeats only, and the header says when it fired.
Two filing axes — a free-text project tag and a closed, enforced vocabulary of knowledge kinds. Chronicle entries are hidden from search by default, but the header always says how many were held back.
Duplicate and contradiction hints — remember reports similar
existing entries and which numbers changed, so you can supersede
instead of accumulate.
Nothing is ever deleted — superseded entries drop out of the default view and stay findable, with a note on why and by what.
Browsing, not just searching — themen() lists projects and a
project's newest title lines for when you have forgotten the words to
search for. Capped like everything else: one page, and a line saying how
to get the rest.
Project-bound in use, not in search — the usual question is asked
inside one project, with marke=. That filter is hard, so when the best
match lies outside the project, recall names it instead of leaving you
with a plausible-looking list of the wrong entries.
Opt-in second opinion — optionally ask any OpenAI-compatible model whether two entries contradict each other or just supersede one another.
German by default, English on request — tool names, messages and
kinds are German; MEMORY_LANG=en switches all of it. The search also
matches inflected forms and compound parts ("Rangliste" finds
"Ranglisten"). Measured, that rarely changes the answer: the plain
any-term stage of the search already finds what the stems would add
(details).
Python 3.11+
The mcp SDK (requirements.txt, that's the whole list)
SQLite with FTS5 — included in standard CPython builds
Optional, for the fact check only: any OpenAI-compatible endpoint
From PyPI, as a command in its own environment:
pipx install frugal-memory # or: uv tool install frugal-memory
claude mcp add memory -s user -- frugal-memoryThe database is created on first use at
~/.local/share/frugal-memory/memory.db ($XDG_DATA_HOME if set).
frugal-memory-nachziehen is the upkeep script described in
DESIGN.md.
Or from a checkout of this repository:
python3 -m venv .venv
.venv/bin/pip install -r requirements.txt
claude mcp add memory -s user -- \
/path/to/frugal-memory/.venv/bin/python \
/path/to/frugal-memory/memory_server.pyHere the database is created as memory.db next to the script. Either way,
MEMORY_DB=/some/path.db puts it somewhere else.
-s user makes the server available in all projects; the entry ends up in
~/.claude.json. Restart Claude Code afterward — MCP servers are only
loaded at startup. The tools are then called mcp__memory__recall and
mcp__memory__remember.
For Claude Desktop, use ~/.config/Claude/claude_desktop_config.json
instead:
{
"mcpServers": {
"memory": {
"command": "/path/to/frugal-memory/.venv/bin/python",
"args": ["/path/to/frugal-memory/memory_server.py"]
}
}
}One rule matters more than any setting: one fact per call, not one
document. recall returns whole entries — store a 180 KB file as a
single entry and you get it back as a single hit, having gained nothing.
The tools alone don't tell an agent the working rules: search before
reading files, recall → zeige, exactly one kind per entry, supersede
instead of accumulate, retry in the other language. Those live in a skill
that ships with the repo (not with the PyPI package):
cp -r skills/frugal-memory ~/.claude/skills/Claude Code loads its full text only when the memory comes up; until then only the one-line description sits in context.
Each machine keeps its own memory, and each numbers its entries from 1. A session on machine A can read the memory of machine B over SSH — the server runs on B, next to its file; the database itself never crosses the network:
claude mcp add memory-b -s project -- \
ssh b /path/to/frugal-memory/.venv/bin/python \
/path/to/frugal-memory/memory_server.py --gast--gast (guest) means three things:
Read-only. The file is opened with mode=ro, and only recall,
zeige and themen are offered. The writing tools are gone, and so are
verdichten and pruefe: upkeep belongs to the owner, who can act on it. A guest's searches do
not feed the owner's search feedback either, and a guest never migrates
the schema.
Every id carries the memory's name: b#72, not #72. The name is the
host name in lower case; MEMORY_NAME overrides it.
A named id is checked, in both modes. zeige("b#72") asked of any
memory other than b is refused instead of quietly returning that
memory's own #72. Bare ids (72, #72) mean the memory being asked.
-s project keeps the three extra tool definitions out of sessions that do
not need them. The tools are then called mcp__memory-b__recall and so on.
| store an entry; reports similar existing ones and what it would supersede |
| ranked full-text search, preview by default; under |
| full text of specific entries, about 6000 characters per call; what doesn't fit is listed with the call that fetches it |
| browse: which projects exist, or one project's title lines, newest first, a page at a time |
| mark as outdated — never deletes |
| assign the knowledge kind of existing entries |
| find groups of entries that say much the same thing |
| opt-in: have a language model judge contradiction vs. newer state |
Full reference with parameters and behavior: docs/TOOLS.md.
With MEMORY_LANG=en the same tools come with English names and parameters,
see A Note on Language.
Measured on one real dataset that grew from ~900 to ~1,900 entries along the way — evidence from one installation, not a benchmark:
4.8× cheaper than reading markdown files, in real tokens, over 275 real questions (2,359 vs. 11,319 per question). The gap grows with the dataset and with file size, because reading a file is all-or-nothing: one question against a 188 KB project file costs 94,152 tokens.
89.8 % Recall@10 against the public LoCoMo dataset with a session as the unit, untuned (2026-10-19; the first run in September gave 82.3 %, and 45.1 % with a single dialogue turn as the unit).
73 % smaller returns from the preview, with a calculable worst case.
−23 % expected characters per question from the feedback loop, at 84 % vs. 73 % first-round hit rate, measured over 164 questions from 30 real sessions in a time-ordered replay — a pair only ever helps later questions, never itself. 19 questions gained, none lost.
53 % → 64 % hit rate on 47 real reformulation chains from a one-line ranking fix — found by measuring where real search sessions had failed, not by guessing. On today's dataset the same fix also costs 3 of the 117 questions that already worked, so the net is +2 of 164.
93 % of the dataset belongs to a project (1,777 of 1,907 entries),
and that is how the tool is used. Search itself does not care: general
knowledge is found as well as project knowledge (92 % vs. 96 %, a tie
under the 10 % rule). What the project filter buys is precision for
short questions — 97 % vs. 85 % found at about three words. What it
costs is everything outside the project: 40 questions about general
knowledge, asked under 22 project tags, found 0 of 880. recall now
names the better match outside the tag in 82 % of those cases, and in
70 % that line already is the entry sought; on real project questions
it fires in 7–16 %.
−83 % for a project's title index, −34 % for fetching eight full
texts, from capping themen and zeige. On 110 project questions the
cap cost not one answer.
Where a measurement did not survive a larger sample, it says so:
docs/MEASUREMENTS.md, with the raw reports in
messung/. The ranking figure above was corrected twice —
see The Ranking Fix, Corrected Twice.
all eight tools in detail | |
the two axes, the morphology, the database schema, and what was left out on purpose | |
what was measured, and the known limitations | |
the opt-in fact check: setup, what it can and cannot do | |
importing an existing folder of notes, and the damage that did | |
the eight underlying measurement reports (mostly German) |
German is the default: tool names, status messages and the kind vocabulary
(schnittstelle, fallstrick, entscheidung, messwert, arbeitsweise,
verlauf, gemischt) are German, and the search stems German and splits
German compounds.
English mode: start the server with MEMORY_LANG=en. Then
the tools are remember(text, tags, kind, supersedes),
recall(query, limit, kind, tag, full, include_superseded), show(ids),
topics(tag, limit), forget(ids, reason), classify(ids, kind),
consolidate(tag, kind, threshold, groups) and check(ids),
the kinds are interface, pitfall, decision, measurement,
workflow, history, unsorted,
every message is English,
the search uses a small English suffix stemmer ("configured" finds "configuring") instead of the German one, and does not split compounds.
The database itself does not change: kinds are always stored under their
German names and translated at the border, and German kind names are
accepted in both modes. What does change is the stem index, so the file
records the language it was built in and the server refuses to open it
with the other one. To switch an existing memory, back it up and run
MEMORY_LANG=en python3 nachziehen.py once.
Not covered by the switch: the fact-check prompt stays German (it is calibrated word for word, and adding one sentence once halved its accuracy; only its verdicts are shown in English), and so do the import script and the measurement reports. The English stemmer is new and has not been measured on real questions the way the German search has.
| MCP server, eight tools, search cascade, schema, migrations |
| stemmer and compound splitter (German; small English stemmer for |
| the English tool surface for |
| English messages, keyed by the German text |
| recomputes |
| opt-in second opinion via any OpenAI-compatible model (off unless configured) |
| measures the fact check against gold labels from the dataset |
| the hand-built and hand-found contradiction pairs |
| import a file-based memory (one-off; see docs/IMPORT.md) |
| regression net, one case per pitfall (no pytest) |
| working rules for the agent, as a Claude Code skill |
| just |
| the database — created on first use, never committed |
messung/ keeps the eight measurement reports. The scripts that
produced them and their raw data are not included: they only run against
the author's own dataset, and the raw data is a verbatim transcript of
real working sessions.
MIT — see LICENSE.
Sets the kind of knowledge for existing entries.
Meant for doing in passing: whatever recall surfaces anyway gets its kind assigned along the way. The backlog doesn't have to be sorted in one sitting.
Args: ids: One or more entry ids, e.g. "376,481". art: Exactly one of: schnittstelle (interface), fallstrick (pitfall), entscheidung (decision), messwert (measurement), arbeitsweise (way of working), verlauf (chronicle). "gemischt" (mixed) undoes the classification.
| Name | Required | Description | Default |
|---|---|---|---|
| art | Yes | ||
| ids | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It usefully discloses that it operates on existing entries and that 'gemischt' undoes the classification, but it does not cover permissions, overwrite behavior for existing kinds, idempotence, or partial batch failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence, followed by concise usage context and an Args section. The wording is efficient and every part supports correct invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple and has an output schema, so return values need not be explained. The description covers purpose, usage, and both required parameters well, though it leaves some mutation edge cases unstated because no annotations are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 parameters, and it does: 'ids' is one or more entry ids with an example comma-separated format, and 'art' is exactly one of the listed classification values, including 'gemischt' to undo classification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific verb and resource: it sets the kind of knowledge for existing entries. It is clear enough to distinguish a classification/update operation from siblings like recall or remember, but it does not explicitly name or contrast alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: it is meant to be done in passing as recall surfaces entries, and the backlog need not be sorted in one sitting. It does not explicitly state when not to use it or name a preferred alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Has a small language model judge how the named entries relate to each other.
Counterpart to verdichten (consolidate): that one finds groups by word overlap, this one says whether a contradiction is behind it or just a newer state of affairs. All pairs from the named ids are judged.
Does NOT judge authoritatively. Measured against 70 pairs: 67 % correct, 9 % false contradiction alarms, but only 2 of 6 real ones caught - and the model says FORTSCHRITT (progress) in 50 of 70 cases. The result says where to look closer, not what the actual case is.
Each pair is asked in BOTH directions, and only what comes back the same both times is reported; otherwise it says "uneinig" (disputed/unclear). Without this, the order of the supplied ids would influence the outcome (measured: 2 of 5 pairs were symmetric). This costs double, i.e. roughly 10 seconds per pair, which is why the cap is 5 pairs asked per call.
Opt-in: needs MEMORY_FC_URL and MEMORY_FC_MODELL pointing at any OpenAI-compatible endpoint (local model, LAN device, or cloud provider; MEMORY_FC_SCHLUESSEL for providers that want a key). Without both set, this tool does nothing and says so - there are no defaults, so nothing is contacted unless it was set up deliberately. Note that when it IS set up, up to 200 characters of each note are sent to that endpoint. If it is unreachable, the tool says so and returns nothing - all other tools are unaffected.
Args: ids: Two or more entry ids, e.g. "249,255".
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so richly: measured accuracy (67% correct, 9% false alarms), a stated bias toward FORTSCHRITT, bidirectional judging with 'uneinig' on disagreement, ~10s/pair cost, a 5-pair cap, and the privacy disclosure that up to 200 chars per note are sent to the endpoint. Failure behavior (unreachable endpoint returns nothing, other tools unaffected) is also disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose and sibling contrast, and every later paragraph carries load-bearing information (accuracy, cost, opt-in, privacy). It is long, but the length is justified by the tool's caveats rather than padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the description still clarifies result semantics ('where to look closer', 'uneinig'). Combined with the cost, cap, opt-in, and failure-mode coverage, an agent has everything needed to decide and call correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single 'ids' parameter, so the description must compensate and largely does: it gives the format ('249,255') and the minimum cardinality ('Two or more entry ids'). It could be more explicit that the value is a comma-separated string, so it is not quite perfect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it has a language model judge how named entries relate. It explicitly positions itself against the sibling verdichten ('that one finds groups by word overlap, this one says whether a contradiction is behind it'), so an agent can distinguish the two without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly differentiates from verdichten and states the opt-in precondition (needs MEMORY_FC_URL and MEMORY_FC_MODELL, otherwise does nothing). It implies the appropriate context but stops short of an explicit imperative 'use this when / not when' rule, so it lands just below the top.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches memory via full-text search, best matches first.
Also finds inflected forms ("Rangliste" -> "Ranglisten"/rankings) and word parts of compounds ("Katalysator" -> "Fusionskatalysator").
By default returns a PREVIEW per hit (id, kind, date, title line). Get the full text of the interesting ones afterwards with zeige("376,481") - or set voll=True right away if the question is narrow enough.
Args: query: Search term(s), FTS5 syntax allowed (e.g. "sqlite AND fts5", "proj*"). limit: Maximum number of hits (default 8). Measured: below this, exact matches drop out due to morphology blending them in; above it, mostly just the returned payload grows. art: Restrict to kinds of knowledge, e.g. "fallstrick,entscheidung". Possible values: schnittstelle (interface), fallstrick (pitfall), entscheidung (decision), messwert (measurement), arbeitsweise (way of working), verlauf (chronicle), gemischt (mixed/not yet classified), alle (all). Default: everything except verlauf - otherwise the chronicle drowns out every search for a specific detail. marke: Restrict to a project, e.g. "raumschiff-project". Multiple tags separated by comma or space are OR-combined. Sub-tags are included: "leuchtturm" also matches "leuchtturm-project", but conversely "mcp-memory-server" does not match "mcp-memory". themen() lists which tags exist. Nothing outside the tag can show up in the hits; if the best match lies outside, a last line names it. voll: Full text instead of preview (default: no). mit_veraltet: Also show superseded entries (default: no).
| Name | Required | Description | Default |
|---|---|---|---|
| art | No | ||
| voll | No | ||
| limit | No | ||
| marke | No | ||
| query | Yes | ||
| mit_veraltet | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so richly: morphology-aware matching (inflection, compound word parts), preview-by-default payload shape, superseded entries hidden unless mit_veraltet, and the notable edge case that hits outside the tag filter are excluded but the best out-of-scope match is named in a last line. These are non-obvious traits an agent could not infer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core behavior before the Args block, and every parameter note is substantive rather than filler. It is longer than typical, and a few rationales (e.g. the measured limit explanation) could be tightened, but nothing is redundant with structured fields given the 0% schema coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation, and the description still clarifies the preview vs. full-text distinction. Combined with filter semantics, defaults, morphology behavior, and the follow-up tool handoff, an agent has everything needed to call this correctly on the first attempt.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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, and it documents all six parameters: FTS5 syntax for query, the measured rationale behind the limit default of 8, enumerated art values with their exclusion of verlauf by default, OR-combining and sub-tag inclusion semantics for marke, and defaults for voll and mit_veraltet. This goes well beyond what the bare schema conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (full-text search over memory) with result ordering, and implicitly defines its niche against siblings by routing full-text retrieval to zeige() and tag discovery to themen(). An agent can distinguish 'find' from 'fetch', 'list tags', and 'store' without opening any schema, since comments and code snippets (>500 chars) are truncated regardless of position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit workflow guidance including the alternative path: use preview first, then zeige("376,481") for interesting hits, or set voll=True up front when the question is narrow. It also states when-not conditions through defaults (verlauf excluded so the chronicle doesn't drown out specific searches), which is genuine selection guidance rather than vague context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stores a text permanently in memory.
Reports back which existing entries resemble the new one - so contradictions get noticed instead of silently sitting side by side.
Args: text: The content to remember. tags: Optional keywords, separated by spaces or commas. Convention: the project, i.e. WHERE the knowledge belongs. art: WHICH KIND of knowledge - exactly one of: schnittstelle (interface: signature, file name, command, data format), fallstrick (pitfall: the obvious approach is wrong because ...), entscheidung (decision, made this way, with rationale), messwert (measurement: a number plus its measurement criterion), arbeitsweise (way of working), verlauf (chronicle - excluded from recall's default view). ersetzt: Ids of outdated entries that this one supersedes (e.g. "12,34"). They are not deleted, only removed from the default view.
| Name | Required | Description | Default |
|---|---|---|---|
| art | No | ||
| tags | No | ||
| text | Yes | ||
| ersetzt | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose meaningful behavior: storage is permanent, the call surfaces resembling existing entries so contradictions are noticed, and ersetzt entries are 'not deleted, only removed from the default view' (i.e., non-destructive). Auth requirements, concurrency, and write-vs-read safety profile are still unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in the first sentence, with the resemblance-reporting behavior immediately after and parameters grouped last. The Args block is necessarily long due to six art values, but every line carries information; only minor density cost from mixing German terms.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, yet the description usefully flags the resemblance report anyway. Parameter conventions are covered in depth. The main gap is the absence of explicit guidance on when to prefer this over sibling write/forget tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description compensates fully: it documents all four parameters, including the six allowed 'art' values with definitions (schnittstelle, fallstrick, entscheidung, messwert, arbeitsweise, verlauf), the tag separator format and convention, and the ersetzt id format ('12,34') plus its non-deleting effect. This goes well beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Stores a text permanently in memory') and adds a distinctive behavioral trait (reports back resembling entries). It indirectly contrasts with recall via the 'verlauf... excluded from recall's default view' note, but never explicitly frames itself against siblings like vergessen or verdichten.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the tag/art conventions (tags = WHERE, art = WHICH KIND), which tell the agent how to categorize knowledge. However, there is no explicit statement of when to use remember versus vergessen/verdichten/recall, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Shows which projects exist - or the title index of one project.
Counterpart to recall: that searches for words, this browses. Without an argument, the tag board (which project, how many entries, how they're distributed across kinds of knowledge); with an argument, that project's title lines, newest first, one page at a time - the last line says how many more there are and how to get them. Page 1 answers "what happened here lately"; for anything older use recall(query, marke="...").
What this is for: recall only finds what you already know to ask for.
Someone picking a project back up after months doesn't remember the
terms anymore - and needs a list first, from which to pull up the entry.
Follow up with recall(query, marke="...") or straight to zeige("...").
Outdated entries don't count, as everywhere in the default view. The chronicle does count here though: when browsing it's the scaffolding, not the filler that drowns out every search.
Args: marke: Project, e.g. "raumschiff-project". Empty = tag board. limit: Rows per page (default 40 for the board, 30 for the title index). seite: Page of the title index (default 1 = the newest). alle: Whole title index at once, grouped by kind. Large for a big project - prefer recall(query, marke=...) when you know a term.
| Name | Required | Description | Default |
|---|---|---|---|
| alle | No | ||
| limit | No | ||
| marke | No | ||
| seite | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, and it does disclose real behavior: title lines are newest-first, paginated one page at a time, the last line reports the remaining count and how to continue, outdated entries are excluded while the chronicle is counted. It does not mention permissions/auth or rate limits, but the operational mechanics an agent needs are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core purpose and the recall contrast, then mechanics, then args. A few sentences (the 'What this is for' motivation paragraph) restate the recall-vs-browse distinction already made and lean stylistic, but nearly everything carries usable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 detail is not required, and all four parameters plus the browsing semantics are documented. The one soft gap is that it never states permission/auth requirements or the shape of a project identifier beyond one example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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, and the Args section documents all four parameters with semantics and defaults: marke (empty = tag board), limit (40 board / 30 index), seite (1 = newest), and alle (whole index grouped by kind, with a size warning). This fully fills the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Shows which projects exist - or the title index of one project.' It also explicitly frames itself against the sibling recall ('that searches for words, this browses'), so an agent can distinguish the two without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit when-to-use branches (no argument = tag board; with argument = title index) and names the alternative with conditions ('for anything older use recall(query, marke=...)', 'prefer recall(query, marke=...) when you know a term'). Both routing conditions and the follow-up path (recall/zeige) are spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds groups of entries that say largely the same thing.
Does not summarize anything itself - that's a judgment call. The tool delivers the groups; the caller writes a new entry and supersedes the old ones via remember(..., ersetzt="...").
Args:
marke: Only consider entries from this project (empty = all). Same
reading as recall and themen: the tag is searched as a phrase in
the tag field, so multi-tagged entries and sub-tags are included
("spiel3d-test" also matches "spiel3d-test Nachtfrost"). Used to
be called tags and compared the whole tag column for equality -
that silently missed exactly the specifically tagged entries
where duplicates tend to sit (#1448).
art: Only consider entries of this kind/these kinds. Default "alle"
(all) - for consolidation the chronicle is the most worthwhile
case; art="verlauf" tackles it on its own.
schwelle: The similarity threshold above which two entries count as
the same.
gruppen: Maximum number of groups reported.
| Name | Required | Description | Default |
|---|---|---|---|
| art | No | alle | |
| marke | No | ||
| gruppen | No | ||
| schwelle | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and mostly meets it: it explicitly says the tool does not summarize and that the actual write/supersede step is the caller's responsibility via remember. This is exactly the kind of non-obvious behavioral contract an agent needs. It says nothing about cost, authentication, or whether the matching is case-sensitive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose before the Args block, and each arg entry is compact. The historical aside about #1448 explaining the old `tags` behavior is useful semantic context but is the one paragraph that a calling agent does not strictly need.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out, yet the description still clarifies that groups are delivered rather than rewritten entries. For a no-annotation tool with a 0%-covered schema, the remaining gap is the absence of any note on how many entries are examined or the cost of large thresholds, plus the unenumerated art values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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, and it largely does: marke is explained with matching semantics and examples ("spiel3d-test" also matches "spiel3d-test Nachtfrost"), art and gruppen are described, and schwelle is defined as the similarity threshold. However, schwelle gives no scale or range (0–1?) and art never enumerates the accepted kinds, so real ambiguity remains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence gives a concrete verb and result ("Finds groups of entries that say largely the same thing"), and the second immediately scopes it against the writing path by stating it does not summarize and that superseding happens via remember(..., ersetzt="..."). An agent can place this tool in a multi-step consolidation workflow without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It supplies real usage context: consolidation is the intended job, and art="verlauf" is called out as the most worthwhile case. It also names recall and themen as the reference for how marke is interpreted, giving the agent a comparison point. It stops short of explicit when-not-to-use exclusions against pruefe or zeige.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Marks entries as outdated, without a replacement.
They disappear from recall's default view but remain findable with mit_veraltet=True. Nothing is deleted.
Args: ids: One or more entry ids, e.g. "12,34". grund: Why - appears later in the display of outdated entries.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | ||
| grund | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden well: it states the soft-delete semantics (hidden from default recall view), the recovery path (mit_veraltet=True), that nothing is destroyed, and that grund surfaces in later displays. It omits permissions/auth requirements and behavior on invalid ids, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core effect, then the visibility/recovery consequence, then a tidy Args block. Every line does work; there is minor redundancy between "without a replacement" and "Nothing is deleted," though the latter usefully reinforces soft-delete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and the description covers the essential mutation semantics (non-destructive, recoverable, reason visibility). It stops short of mentioning idempotency, error behavior, or permission needs for a mutation tool that has no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 — and it does: ids is documented as one-or-more with the concrete format "12,34", and grund is explained as the reason string that appears in the outdated-entry display. Both parameters gain meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and effect — "Marks entries as outdated, without a replacement" — and immediately scopes it against the default recall view, so an agent can distinguish this soft-archive operation from sibling tools like recall or remember. The only gap is that it doesn't explicitly name which sibling to prefer when a replacement exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: marking as outdated is for entries with no replacement. There is no explicit when-to-use vs when-not-to-use guidance, and no routing to alternatives among pruefe, verdichten, or einordnen for cases where a replacement or merge is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the named entries in full text.
Counterpart to recall's preview: first see which entry is meant, then read only that one. Outdated entries are explicitly included here - whoever asks for the id means that one too, even if it's outdated.
One call returns about 6000 characters of full text, in the order asked. Whatever doesn't fit comes back as a title line plus the call that fetches it - nothing is dropped silently. The pieces of one cut-up memo are never separated.
Args: ids: One or more entry ids, e.g. "376,481". Most wanted first. voll: Everything asked for at once, without the cap (default: no).
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | ||
| voll | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and does so well: it discloses the ~6000-character per-call cap, that overflow returns a title line plus a follow-up fetch call rather than silent drops, that results preserve requested order, that cut-up memo pieces stay together, and that outdated entries are deliberately included. This is far more behavioral detail than the structured fields supply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core behavior and then the routing rule; the Args block is a clear, conventional structure. A few phrases are discursive ('whoever asks for the id means that one too'), but nothing is padding to the point of harm.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out, yet the description still covers the non-obvious return behavior (cap, overflow fetch hint, ordering) that a schema would not convey. Combined with full parameter coverage and sibling routing, nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 and does: 'ids' is documented as one or more comma-separated entry ids with a format example ('376,481') and ordering intent ('Most wanted first'), and 'voll' is explained as fetching everything without the cap, including its default of no. Both parameters gain meaning absent from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Returns the named entries in full text') and immediately distinguishes itself from the sibling recall by positioning itself as its 'counterpart'. An agent can tell this apart from recall/verdichten/pruefe without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear workflow context ('first see which entry is meant, then read only that one') and names the alternative tool (recall) explicitly. It stops short of stating when *not* to use it (e.g. free-text search) or any preconditions on the ids, so it is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0einordnenprueferecallrememberthemenverdichtenvergessenzeigeScored across 8 tools
Each tool has a distinct primary role: store (remember), search (recall), browse (themen), fetch (zeige), classify (einordnen), forget (vergessen), and two consolidation helpers (verdichten, pruefe). The closest pairs, verdichten/pruefe and vergessen/remember with ersetzt, are clearly delineated by the descriptions, but the fine distinction between finding duplicates versus judging contradictions could still cause occasional hesitation.
Tool names mix English ('remember', 'recall') with German ('verdichten', 'pruefe', 'vergessen', 'zeige', 'einordnen') and one noun ('themen') among otherwise imperative verbs. All names are single lowercase tokens, so they are readable, but the convention is not uniform enough for a high consistency score.
Eight tools are well-scoped for a personal memory server, covering create, read, search, browse, classify, forget, and two targeted consolidation helpers without obvious redundancy. Each tool earns its place and the set does not feel bloated or thin.
The core lifecycle is covered: create (remember), read (recall, zeige, themen), update knowledge kind (einordnen), soft delete (vergessen), and consolidation (verdichten, pruefe). Minor gaps exist—no way to edit tags of an existing entry and no hard delete—but these appear intentional and can be worked around by creating a new entry and superseding the old one.
Persistent memory for AI agents. Search and store durable facts, preferences and decisions.
Persistent memory for AI agents. Search, store, and recall across sessions.
Persistent memory for AI assistants: store, search, and connect knowledge across conversations.
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
