Skip to main content
Glama
NORTHTEKDevs

GENOME MCP Server

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.

tests install canary PyPI License: Apache 2.0 Python 3.11-3.14 DOI

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

GENOME storing a two-year timeline and answering point-in-time questions

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.py

The 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:#fff

Write: 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:#fff

A 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.verify

The 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.598

That 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")   # quarantined
  • Explainable 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 - and belief_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-memory

The 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:8080
curl -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 request

For 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-memory
import { 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; Austin

On 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)  # reranked

Reproduce 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 baselines

Support 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 tools
forgetA

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.
ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
user_idNodefault
min_scoreNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior5/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 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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/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, 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.

Purpose4/5

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.

Usage Guidelines3/5

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").
ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes
user_idNodefault

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations, the description 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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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

The description clearly states the tool's 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.

Usage Guidelines4/5

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.
ParametersJSON Schema
NameRequiredDescriptionDefault
contentYes
user_idNodefault

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.6/5.0
Behavior4/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 '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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters5/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.
ParametersJSON Schema
NameRequiredDescriptionDefault
user_idNodefault

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/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 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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/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 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.

Purpose5/5

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.

Usage Guidelines4/5

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. 1 tool updatev1.2.1
    • Changedforget1 field changed
      • addedInput schema / properties / min_score
        Added value: +{
        +  "default": 0.5,
        +  "title": "Min Score",
        +  "type": "number"
        +}
  2. 4 tool updatesv0.1.0
    • First observedforget
    • First observedrecall
    • First observedremember
    • First observedreset_memories

TDQS

A4.6/5.0
Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness5/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    A 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.
    1
    Apache 2.0
  • A
    license
    A
    quality
    C
    maintenance
    A 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.
    17
    2
    MIT

Latest Blog Posts

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/NORTHTEKDevs/genome'

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