GENOME MCP Server
This server provides a fully local, persistent long-term memory for AI agents via four MCP tools.
remember – Store a fact, preference, or note; embeds locally with no LLM call or network.
recall – Semantic search over stored memories; supports limits and per-user namespaces.
forget – Delete the single memory most relevant to a query; destructive.
reset_memories – Clear all memories for a specific user namespace; irreversible.
All operations run offline against a local SQLite database (~/.genome/memories.db), with no API keys required.
Click on "Install 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., "@GENOME MCP ServerStore that my favorite color is blue"
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.
GENOME
Open memory for AI agents. Same answer accuracy as Mem0 - but ~1,000× cheaper to store, runs fully offline, and keeps an auditable record.
Papers: Do Agents Need an LLM to Remember? (the core evaluation, 2026) and What Does Each Memory Feature Buy? (a measured audit of all five optional features, wins and failures alike, 2026). PDFs in papers/; result tables in benchmarks/AUDIT-RESULTS.md.
Most agent-memory tools (like Mem0) call an LLM on every message to decide what to remember. That's the slow, expensive part - and GENOME's bet is that you don't need it. GENOME just embeds each message locally: no LLM, no API, no network in the write path.
Benchmarked honestly on public datasets (LoCoMo, LongMemEval), GENOME answers just as accurately as Mem0 - while storing memories for a tiny fraction of the cost and running completely offline.
Honest up front: on answer accuracy, GENOME ties Mem0 - we do not claim to beat it there (six independent benchmark configurations confirm parity, none significant in either direction). The advantage is cost, speed, offline operation, and a temporal/auditable record Mem0 can't produce.
See it work

Every frame is real output from examples/demo_timeline.py,
captured by tools/render_demo_gif.py. Run it yourself,
no API key required:
python examples/demo_timeline.pyThe interesting part is step 3. The same question gets three different correct answers depending on when you ask about, because the store keeps when each fact became true rather than overwriting it:
Question | Answer |
What was Priya's city in May 2023? | Boston [Mar 2023 - Jan 2024] |
What was Priya's city in March 2024? | Seattle [Jan 2024 - Feb 2025] |
What is Priya's city now? | Austin [Feb 2025 - present] |
The "thinking about maybe moving to Denver, nothing decided" turn is stored but never becomes an answer: it is a plan, not a durable fact.
Related MCP server: MCP Memento
How it works
The write path is deliberately dumb and cheap. All the intelligence happens at read time, when there is a query to focus it.
flowchart LR
M["incoming message"] --> E["local embedder<br/>all-MiniLM-L6-v2"]
E --> S[("local store<br/>SQLite or Postgres")]
M -. "optional, opt-in" .-> B["belief extraction<br/>(the only LLM call)"]
B --> K[("bi-temporal<br/>fact log")]
Q["query"] --> R["exact cosine search<br/>over this tenant's rows"]
S --> R
R --> RR["optional cross-encoder<br/>rerank"]
RR --> A["context for the agent"]
Q --> PIT["as-of resolution<br/>facts_valid_at(entity, T)"]
K --> PIT
PIT --> A
style E fill:#0A84FF,color:#fff
style S fill:#1c2530,color:#fff
style K fill:#1c2530,color:#fff
style B fill:#3a3a3a,color:#fffWrite: embed locally, store. About 10 ms, zero LLM calls, zero network calls. The embedding is deterministic -- the same text always yields the same vector, with no sampled extraction step deciding what matters -- so what gets stored is a function of the input, and replaying a journal reproduces that store exactly. (Ids and timestamps are stamped per write, so two independent ingests of the same conversation agree on content and vectors, not on record ids.)
Read: exact cosine search within the tenant's scope (no ANN index to build or update), with an optional local cross-encoder reranker.
Bi-temporal layer (opt-in): records each fact at its domain time, the moment it became true in the world, not the moment it was ingested. That is what makes point-in-time questions answerable even when facts arrive out of order.
Why the record can be re-derived
flowchart TB
subgraph LLM["LLM-extraction memory"]
A1["message"] --> A2["LLM decides what matters<br/>(sampled, non-deterministic)"]
A2 --> A3[("store")]
A3 --> A4["replaying the same input<br/>can produce a different store"]
end
subgraph GEN["GENOME"]
B1["message"] --> B2["local embedding<br/>(deterministic)"]
B2 --> B3[("store")]
B3 --> B4["replaying the same input<br/>reproduces the same store"]
end
style A4 fill:#5c1f1f,color:#fff
style B4 fill:#1f4d33,color:#fffA record that cannot be re-derived is difficult to audit. That property, not accuracy, is the actual argument for this design.
Don't believe it? Prove it yourself
The cost, speed, and offline claims need no API key - measure them on your machine in 60 seconds:
git clone https://github.com/NORTHTEKDevs/genome && cd genome
pip install -e . && python -m genome.verifyThe first run downloads the local embedding model (~90 MB, one time) before printing anything, so expect 30-120 seconds of apparent silence on a cold machine. Every run after that is instant.
It writes memories with your outbound network physically blocked and prints a live pass/fail receipt - 0 network calls, 0 LLM calls, single-digit-ms writes, retrieval that works:
[PASS] Air-gapped write path: wrote 200 memories with every outbound socket blocked -> 0 network attempts, 0 LLM calls
[PASS] Write latency: 7.1 ms/message (Mem0's measured write path: ~2,055 ms + 1 LLM call/message)
[PASS] Retrieval works: top hit score 0.598That receipt covers the cost/speed/offline story only. The accuracy-parity with Mem0 claim
is a separate, larger check that needs an LLM key - reproduce it head-to-head on the same
questions with your own key via python benchmarks/head_to_head.py (one OpenRouter key works;
see benchmarks/RESULTS.md for the n=90 / n=205 runs, the paired
significance tests, and the published nulls). The full test suite runs in public CI (badge
above). The pitch isn't "trust me" - it's "run it."
Add persistent memory to your agent in one line (MCP)
GENOME ships a fully-local MCP server - cross-session memory for Claude Desktop, Claude Code, or Cursor with no API key and no data leaving your machine:
pip install "genome-memory[mcp]"{ "mcpServers": { "genome": { "command": "genome-mcp" } } }Or zero-install via uv: { "command": "uvx", "args": ["--from", "genome-memory[mcp]", "genome-mcp"] }
Tools the agent gets: remember, recall, forget, reset_memories.
Memories persist locally in ~/.genome/memories.db. Full MCP details ↓
GENOME vs Mem0 at a glance
GENOME | Mem0 | |
Answer accuracy (LoCoMo, LongMemEval) | tied | tied |
LLM calls to store one message | 0 | 1+ |
Write speed | ~10 ms | ~2,000 ms |
Runs offline / air-gapped | yes | no (needs an LLM API) |
Ingest cost (10k-user deployment) | ~$190 / yr | $159k-$1.6M / yr |
"What was true in March?" (point-in-time) | yes | no |
Deterministic, auditable memory | yes | no |
Every number is measured within one harness - same responder, judge, embedder, and top-k;
only the memory layer changes - with paired significance tests. Full detail and per-number
provenance: benchmarks/RESULTS.md. Formatted report:
benchmarks/GENOME-LoCoMo-Report.pdf.
Why it's ~1,000× cheaper: it never calls an LLM to remember
Storing one message costs one LLM call in Mem0, zero in GENOME (just a local embedding). That's not a benchmark you can argue with - it's arithmetic, and it holds no matter which LLM you price it against. At 10,000 users × 50 messages/day (15M messages/month):
Model Mem0 uses to extract | Mem0's yearly ingest bill | GENOME |
Claude Haiku | $1,601,757 | $190 |
gpt-4o-mini | $238,596 | $190 |
cheapest hosted model | $159,064 | $190 |
The gap survives the cheapest model and grows in production (Mem0 re-sends stored memories
to the LLM as the store fills). Reproduce: python benchmarks/tco_project.py (no API key).
It runs air-gapped
GENOME's default embedder is local. We proved the write path is genuinely offline by blocking all network during writes - they still succeed:
~10 ms/message, 0 network calls, 0 LLM calls (
python benchmarks/local_writepath.py)Mem0 can't do this - it needs an LLM API call to ingest.
That makes GENOME usable on-prem, in regulated environments, or fully offline. It's a yes/no capability, not a price point.
How it works
Write: embed the message locally and store it. No LLM, no network. (~10 ms)
Read: vector search over your memories, with an optional local cross-encoder reranker for harder queries.
Optional bi-temporal layer: track how facts change over time and answer "what was true at time T" - see below.
What determinism buys you
Because nothing on the write path interprets your content, GENOME can do things an LLM-ingest memory system cannot do in principle:
Memory firewall (
genome.firewall): tag every write with where it came from (user,agent,tool,web), quarantine low-trust origins from recall, and enforce origin-bound authority - web content can never UPDATE or DELETE what your user said, even when a prompt-injected conflict resolver asks for it. There is also no extraction step for injected content to attack: the write path has no LLM.from genome import Memory from genome.firewall import TrustPolicy m = Memory(trust_policy=TrustPolicy(recall_min_trust=1)) m.add("I live in Anchorage", user_id="u1", provenance="user") m.add(scraped_page_text, user_id="u1", provenance="web") # quarantinedExplainable recall (
genome.explain):explain_search()reports every candidate's dense score, BM25 rank, fused score, and - when it was not returned - the exact reason (parent-filtered, quarantined, beyond the limit). Two runs agree, so a recall bug can be committed as a regression test instead of a shrug.Journal + replay (
genome.journal): record every mutation and provably reproduce the store -verify_journal()replays the history and compares canonical hashes. Replay a prefix to roll back; replay into different storage to branch a memory for a what-if run. The journal sits after extraction, so replay is deterministic even if you configured an LLM extractor. Each line chains to its predecessor, so a removed or edited line is detected even when the change cancels out in the final state.# Tamper-EVIDENT by default. Pass a key (kept outside the journal's directory) # to make it tamper-PROOF: an unkeyed chain can be recomputed by anyone with # write access, an HMAC chain cannot. m = Memory(journal="mem.journal", journal_key=os.environb[b"GENOME_JOURNAL_KEY"])Multi-agent belief attribution (
record_fact(..., believed_by="agent-a")): agents sharing a store keep their own belief timelines - agent B disagreeing does not clobber agent A's fact - andbelief_conflicts()surfaces disagreements for deliberate resolution instead of silently picking a winner.A neutral benchmark harness (
benchmarks/neutral/): run GENOME, Mem0, and a full-context baseline through the same responder, judge, and embedder, with a pairwise McNemar matrix and a full-disclosure block. GENOME is one row in the table, not the house.
Install
pip install genome-memoryThe default embedder is local (sentence-transformers/all-MiniLM-L6-v2) - no API key,
works offline; the first run downloads the ~90 MB model once. OpenAI embeddings are
optional for higher-dimensional retrieval.
Dependency footprint, honestly: the core install is numpy, sentence-transformers,
scikit-learn, and rank-bm25. Local embeddings run on PyTorch (pulled in by
sentence-transformers), so it isn't a tiny install - that's the deliberate tradeoff for
offline, zero-cost embedding. Plotting/benchmark-chart deps live in an optional [viz]
extra, not the core. Migrating from Mem0? See
docs/migrating_from_mem0.md.
Quickstart (fully local, no API key)
from genome import Memory
mem = Memory(storage="genome.db") # local embedder by default; ":memory:" for ephemeral
# Store a message -- embedded locally, no LLM call, no network
mem.add("Ada met Lin at the robotics summit in Berlin.", user_id="u1")
mem.add("They are collaborating on an open-source planning library.", user_id="u1")
# Retrieve the most relevant memories
for hit in mem.search("Where did Ada meet Lin?", user_id="u1", limit=5):
print(f"{hit.score:.3f} {hit.content}")Memory mirrors Mem0's API (add / search / get / delete / reset) - a near
drop-in swap. To use OpenAI embeddings instead (set OPENAI_API_KEY):
from genome import Memory, EmbeddingProvider
mem = Memory(storage="genome.db",
embedding_provider=EmbeddingProvider(model_name="openai:text-embedding-3-small"))Use it as an MCP server (fully-local memory for any agent)
GENOME ships an MCP server, so any MCP client (Claude Desktop, Claude Code, Cursor, ...) gets persistent cross-session memory that runs entirely on the local machine - no LLM calls, no API keys, no data leaves the box. Most memory MCPs can't say that.
Install with the mcp extra, then add it to your client's config:
pip install "genome-memory[mcp]"{
"mcpServers": {
"genome": { "command": "genome-mcp" }
}
}Tools the agent gets: remember (store a fact/preference, local + 0 LLM), recall
(semantic search), forget (delete the memory matching a query), reset_memories
(clear a user's memories). Memories persist in ~/.genome/memories.db (override with the
GENOME_MCP_DB env var). Run standalone with genome-mcp or python -m genome.mcp.server.
Run it as an HTTP API
Prefer HTTP? GENOME ships a FastAPI server that mirrors the library 1:1 (add / search /
get / update / delete / reset / synthesize), with an auto-generated OpenAPI spec at
/docs.
pip install "genome-memory[fastapi]"Try it locally (keyless, loopback only - one flag makes the "no auth" intent explicit):
GENOME_ALLOW_NO_AUTH=1 python -m genome.server # serves on 127.0.0.1:8080curl -X POST localhost:8080/v1/memories \
-H 'Content-Type: application/json' \
-d '{"text": "Ada met Lin at the robotics summit in Berlin.", "user_id": "u1"}'
curl -X POST localhost:8080/v1/search \
-H 'Content-Type: application/json' \
-d '{"query": "Where did Ada meet Lin?", "user_id": "u1", "limit": 5}'Safe by default. The server refuses to serve unauthenticated unless you opt in as
above, and it will not bind a non-loopback interface without a key. To expose it, set an
API key (sent as X-API-Key) - required to bind beyond localhost:
GENOME_API_KEY=$(openssl rand -hex 32) GENOME_HOST=0.0.0.0 python -m genome.server
# then add: -H "X-API-Key: $GENOME_API_KEY" to every requestFor multi-tenant deployments, set GENOME_REQUIRE_SCOPE=1 to require user_id/agent_id on
every call and disable the global reset. Docker: docker-compose up (needs GENOME_API_KEY
and POSTGRES_PASSWORD; Postgres is published on loopback only). Full guide, including the
Postgres backend and every env var: docs/tutorial_quickstart.md.
TypeScript / JavaScript client
@northtek/genome-memory mirrors the
Python Memory API shape against this server (ESM, Node 20+ or browser):
npm install @northtek/genome-memoryimport { Memory } from "@northtek/genome-memory";
const mem = new Memory({ baseUrl: "http://localhost:8080" });
await mem.add({ text: "Ada met Lin in Berlin.", userId: "u1" });
const hits = await mem.search({ query: "Where did Ada meet Lin?", userId: "u1" });Full client docs: sdks/typescript/README.md.
The honest results
Same responder + judge + embedder for every system; only the memory layer changes.
What we measured | Result | Verdict |
Answer accuracy, in-window (LoCoMo) | GENOME 0.851 vs Mem0 0.855 (p > 0.23) | Tied |
Answer accuracy, harder bench (LongMemEval, n=90 & n=205) | directionally ahead, not significant (p = 0.14-0.19) | Tied |
Accuracy when history overflows the context window | +0.409 at 80× less context (p = 8e-10) | Win |
Cost to store a message | 0 LLM calls vs 1+; 837-8,433× cheaper | Win |
Write path | ~10 ms, air-gapped, 0 network calls | Win |
Point-in-time ("what was true at T") | belief-state 0.870 vs Mem0 0.676 (synthetic data) | Win, with caveat |
Retrieval hit-rate with reranking | improves hit@10 (up to 0.943); local + free | Win |
What we tested that didn't help (so you don't have to)
We publish our nulls - it's how you know the wins are real:
Synthesis / consolidation: accuracy-neutral at equal token budget (p = 0.86).
Hybrid (BM25 + dense) and graph retrieval: hybrid underperformed plain dense on LoCoMo; graph was not validated here.
Reranking's accuracy gain is embedder-dependent: it reliably improves retrieval hit-rate, but its effect on final answer accuracy depends on the embedder - treat it as a retrieval-quality tool, not a guaranteed accuracy win.
Bi-temporal memory: "what was true at time T"
GENOME can track how facts change over time and answer point-in-time questions - something overwrite-based memory structurally can't do (it only keeps the latest value):
from genome.memory.belief import ingest_belief_turn, answer_belief_context
mem = Memory(storage="genome.db", llm_call=my_llm_fn)
# facts land at their DOMAIN time (parsed from the text), not wall-clock ingest time
ingest_belief_turn(mem, "In March 2024, Jordan moved to Seattle.", session_time=t0, user_id="u")
ingest_belief_turn(mem, "Jordan just moved to Austin.", session_time=t2, user_id="u")
answer_belief_context(mem, "Where does Jordan live now?", user_id="u") # -> Austin
answer_belief_context(mem, "Where did Jordan live in early 2024?", user_id="u") # -> Seattle
answer_belief_context(mem, "List every city Jordan has lived in.", user_id="u") # -> Seattle; AustinOn the TempBelief benchmark it answers as-of queries at 0.870 vs Mem0's 0.676, with the knowledge graph audited at 0.97 precision / 0.96 recall. Caveat: TempBelief is synthetic text with explicit dates; the edge shrinks on natural speech. Real capability, bounded proof.
Optional features
Opt-in; the default path stays LLM-free and local at ingest.
mem = Memory(
storage="genome.db",
llm_call=my_llm_fn, # LLM-based fact extraction on add()
resolve_conflicts=True, # ADD/UPDATE/DELETE vs existing memories
auto_extract_entities=True, # entity graph for graph retrieval
auto_consolidate_threshold=200, # summarize-or-prune when a scope grows past N
)
mem.search("...", user_id="u1", mode="hybrid") # modes: "dense" (default), "hybrid", "graph"Reranking (local, free, no API):
from genome.memory.rerank import CrossEncoderReranker
mem = Memory(storage="genome.db", reranker=CrossEncoderReranker()) # lazy-loaded
mem.search("Where did the user go on vacation?", user_id="u1", limit=5) # rerankedReproduce the benchmarks
The LoCoMo and LongMemEval datasets are not bundled (they carry their own licenses -
LoCoMo is CC BY-NC 4.0). See benchmarks/data/README.md to
download them. The first two lines need no dataset and no API keys:
python benchmarks/local_writepath.py # local write path: ~10ms/msg, 0 network
python benchmarks/tco_project.py # deployment cost projection
python benchmarks/verdict.py # in-window accuracy + McNemar
python benchmarks/haystack_report.py # overflow / context-window crossover
python benchmarks/ingest_cost.py --n 80 # measured ingestion cost vs Mem0
python benchmarks/lme_qa.py --n 90 # LongMemEval head-to-head vs Mem0
python benchmarks/tempbelief_run.py --convs 6 # bi-temporal point-in-time vs baselinesSupport and commercial tier
Bugs and questions: issues and discussions. Community support is best-effort - see SUPPORT.md.
GENOME Enterprise is a separate commercial product for regulated and on-premise buyers who have to answer to an auditor for what an AI system knew and when: a tamper-evident hash-chained audit record, point-in-time reconstruction, compliance reports, retention with erasure proofs, RBAC and SSO. Self-hosted and licensed per deployment - there is no hosted version, deliberately, because the value is that your data never leaves. That tier is what funds this one. Evaluating it, or want commercial support on the open core? info@northtek.io
License
Apache License 2.0 - see LICENSE and NOTICE.
GENOME is free and open source: read it, modify it, self-host it, and embed it in your own applications - commercial use included - under the terms of Apache 2.0. There is no "open core bait and switch" planned: the core stays Apache-2.0.
The Apache-2.0 grant covers the code, not the name - see TRADEMARKS.md, which leads with what you may do without asking. Questions: info@northtek.io.
Copyright 2026 Northtek (FrostByte Digital LLC). mcp-name: io.github.NORTHTEKDevs/genome
Available Tools
4 toolsforgetA
Delete the single memory most relevant to query, if it is relevant enough.
Destructive. Finds the best-matching memory and removes it only when its
relevance (cosine similarity, -1..1) reaches `min_score`. Below the floor
nothing is deleted and the best candidate is reported so the query can be
sharpened. Without the floor, any query against a non-empty memory deletes
its nearest neighbour, however unrelated.
Args:
query: Describes the memory to remove.
user_id: Namespace to delete from (default "default").
min_score: Relevance floor (default 0.5). Lower it only when the
reported candidate is confirmed to be the memory meant.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| user_id | No | default | |
| min_score | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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 and does so exceptionally well. It explicitly labels the operation 'Destructive', explains the relevance threshold in cosine similarity terms, describes the below-floor behavior, and warns that without a floor any query would delete the nearest neighbor however unrelated.
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 description is well-structured and front-loaded: a one-sentence summary, then a short behavioral/safety paragraph, then the Args block. Every sentence contributes either to the tool's purpose, its destructive edge cases, or parameter semantics. The slight redundancy between the first sentence and the second paragraph is acceptable because it reinforces the safety-critical threshold behavior.
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?
For a destructive tool with no annotations, the description is remarkably complete. It covers the operation, the deletion condition, the edge case below the floor, the consequence of omitting the floor, and all three parameters with defaults. Since an output schema exists, the absence of detailed return-value docs is not a gap.
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 fully does. Each parameter gets a meaningful explanation: query describes the memory to remove, user_id defines the namespace with a default, and min_score is explained as a relevance floor with explicit guidance to lower it only when the reported candidate is confirmed.
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 clearly states the verb and resource: 'Delete the single memory most relevant to `query`'. The qualifier 'if it is relevant enough' adds precision. However, it does not explicitly contrast this tool with recall, remember, or reset_memories, so sibling differentiation is implied by semantics rather than stated.
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 contextual guidance about when deletion happens and cautions against lowering min_score until the candidate is confirmed. It also suggests sharpening the query when the floor is not met. But it does not explicitly tell an agent when to choose forget over recall, remember, or reset_memories, so the when-to-use advice is only partial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recallA
Search long-term memory for information relevant to a query.
Read-only, fully local semantic search. Call this before answering when the
user refers to past context, preferences, or previously-shared facts.
Args:
query: What to look for (a question or topic).
limit: Max memories to return (1-50, default 5).
user_id: Namespace to search (default "default").
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| user_id | No | default |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses 'Read-only, fully local semantic search,' indicating no side effects and privacy (local). This is meaningful additional context beyond just 'search' though it could mention potential limitations like semantic match quality.
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 description is well-structured with a purpose line, usage guidance, and a clear Args list. It is front-loaded with the key function and every sentence earns its place.
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 description covers the tool's purpose, usage context, safety (read-only, local), and all parameter details. Since an output schema exists, return value details are not needed. It is complete for a simple retrieval tool.
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 coverage is 0%, so the description must compensate. It does so thoroughly: query is 'What to look for (a question or topic)', limit is 'Max memories to return (1-50, default 5)', and user_id is 'Namespace to search (default "default")'—adding semantics and defaults not present in 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?
The description clearly states the tool's function: 'Search long-term memory for information relevant to a query.' It uses a specific verb and resource, and the read-only nature distinguishes it from sibling tools (remember, forget, reset_memories) that modify memory.
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 provides explicit when-to-use guidance: 'Call this before answering when the user refers to past context, preferences, or previously-shared facts.' It lacks explicit when-not-to-use or named alternative tools, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rememberA
Store a fact or note in long-term memory.
Fully local -- embeds the text with a local model and writes it to a local
SQLite file. No LLM call, no network. Use this whenever the user tells you
something worth remembering across sessions (preferences, facts, decisions).
Args:
content: The text to remember (a fact, preference, or note).
user_id: Namespace to store under (default "default"). Use per-end-user.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | ||
| user_id | No | default |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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 'Fully local', 'embeds the text with a local model and writes it to a local SQLite file', and 'No LLM call, no network', providing transparency about side effects and operational behavior. It does not describe the return value, but an output schema exists.
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 description is well-structured: a one-sentence summary, a brief technical note, and an Args list. Every sentence is purposeful and there is no fluff.
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?
For a simple memory store, the description covers purpose, usage, behavior, and parameters. The sibling tools and the straightforward nature of the operation make it sufficiently complete.
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?
The schema provides only names and types with no descriptions, but the 'Args' section adds full meaning: 'content' as the text to remember, and 'user_id' as a namespace with default 'default' and guidance to use per end-user. This substantially enriches 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?
The description clearly states 'Store a fact or note in long-term memory' with a specific verb and resource. It distinguishes from sibling tools (recall, forget, reset_memories) by focusing on the write operation.
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?
Explicitly says 'Use this whenever the user tells you something worth remembering across sessions' with concrete examples. However, it does not explicitly name alternatives or state when not to use, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reset_memoriesA
Delete ALL memories for a user. Destructive and irreversible.
Args:
user_id: Namespace to clear (default "default"). This never clears other
users' namespaces.
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | No | default |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
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 explicitly states 'Destructive and irreversible,' which is the critical safety trait, and further clarifies namespace isolation with 'This never clears other users' namespaces.' This provides strong, directly relevant context beyond what the schema implies.
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 description is extremely concise: two sentences of behavioral context plus a brief parameter explanation. Every sentence earns its place, and the most important information ('Delete ALL', 'Destructive and irreversible') is front-loaded.
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?
Given the tool's simplicity (one optional parameter, no enums, no nested objects) and the presence of an output schema (which the description needn't explain), the description covers all essential aspects: purpose, destructive nature, parameter semantics, and scope isolation. No critical gaps remain.
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 for the single parameter. It does so by explaining user_id as a 'Namespace to clear' and adding the isolation guarantee. While it redundantly restates the default value already in the schema, it adds semantic meaning that the schema lacks.
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 starts with a specific verb and resource: 'Delete ALL memories for a user.' It clearly distinguishes itself from sibling tools like 'remember', 'recall', and 'forget' by emphasizing the bulk, all-encompassing scope ('ALL'). The purpose is unambiguous.
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 context: it is a destructive, bulk delete operation scoped to a user namespace, with a default namespace. However, it does not explicitly name alternatives or state when not to use it (e.g., 'use forget for individual memories'). The usage is clear but lacks explicit 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. Dates show when Glama detected each change.
1 tool update
v1.2.1- Changed
forget1 field changed- added
Input schema / properties / min_scoreAdded value: +{ + "default": 0.5, + "title": "Min Score", + "type": "number" +}
4 tool updates
v0.1.0- First observed
forget - First observed
recall - First observed
remember - First observed
reset_memories
TDQS
Each tool maps to a distinct memory operation: remember for storing, recall for searching, forget for deleting a single memory, and reset_memories for clearing an entire namespace. The overlap between forget and reset_memories is clearly scoped by singleness versus all-memories, so there is no real ambiguity.
Three tools use simple lowercase verb forms (remember, recall, forget) and one uses verb_noun snake_case (reset_memories). The pattern is mostly consistent and intuitive, with only reset_memories deviating by including an object.
Four tools is a well-scoped count for a memory server. Each tool covers a necessary operation without redundancy or bloat, making the set easy to navigate.
The core memory lifecycle is covered: store, read/search, delete one, and delete all. There is no explicit update operation, but for a semantic memory store treating memories as immutable facts this is not a meaningful gap.
Maintenance
Related MCP Connectors
Persistent memory for AI agents — verbatim conversations, searchable by meaning.
Persistent memory for AI agents. Search, store, and recall across sessions.
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
Persistent memory for AI agents. EU-hosted, privacy-first, hybrid recall, contradiction detection.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA local-first persistent memory server that provides AI agents with deterministic, multimodal information retrieval across different sessions and projects. It enables long-term memory continuity using a 5-signal hybrid search engine and cognitive reasoning loops designed for complex development workflows.1Apache 2.0
- AlicenseAqualityCmaintenanceA persistent long-term memory server for AI assistants that enables storing and recalling solutions, facts, and decisions with intelligent confidence tracking and relationship mapping. It allows developers to build a cross-platform knowledge base that integrates seamlessly with IDEs and CLI agents.172MIT
- AlicenseNot gradedqualityBmaintenanceA lightweight, powerful local memory server for AI agents supporting text, entities, and relations. Enables persistent codebase understanding and user preference management.4851MIT
- AlicenseNot gradedqualityDmaintenanceA local-first MCP memory server that gives AI coding agents persistent memory with hybrid semantic and keyword retrieval, working fully offline.20200MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/NORTHTEKDevs/genome'
If you have feedback or need assistance with the MCP directory API, please join our Discord server