What can you do with this server?

memkeeper is a local-first, durable memory engine for AI agents that stores, ranks, and retrieves context on-device using SQLite (BM25/FTS) with optional semantic (ONNX) retrieval. Memory Lifecycle * remember — Write a single atomic memory (fact, decision, preference, lesson) with rich metadata: tags, confidence, validity windows, scope, supersession, and more. * forget — Soft-delete a memory by ID; use mode='correct' to record a factual correction signal. * verify — Re-confirm an existing memory is still accurate, updating its last-verified timestamp. * get — Fetch one memory by ID, optionally including version history and provenance. * memory_list — Browse recent memories in reverse-chronological order with optional filters. Retrieval & Context Assembly * search — Relevance-ranked retrieval using semantic (embedding) search with BM25/FTS fallback and optional cross-encoder reranking. * pack — Assemble a compact, prompt-ready context block from one or more queries, with character budgeting, graph expansion, and query expansion options. Entity Knowledge Graph * entity_upsert / entity_search — Create, update, or search entities (persons, projects, concepts) with canonical names, aliases, and metadata. * relationship_upsert — Create or update directed relationships between entities. * graph_neighbors — Traverse the graph outward from a starting entity to a bounded depth. * graph_context — Build a prompt-ready context block centered on one entity, including neighbors and linked memories. * dream_graph — Dry-run preview of entity/relationship extractions and merges without writing anything. Human-Review Queue * candidate_submit — Queue a proposed memory for human review instead of writing it directly to recall. * candidate_list — List pending, approved, or rejected review candidates. Store Inspection * stats — Report memory counts, breakdowns by space/silo/status/kind, schema version, DB size, and health rollups. All operations are local-first (embedded SQLite), require no network for lexical search, and optionally use on-device ONNX models or an OpenAI-compatible API for semantic embeddings.

Which integrations are available for this server?

Allows using OpenAI's embedding API for semantic memory retrieval, as an alternative to on-device models.

memkeeper

by teflon07

Overview Schema Related Servers Score Discussions

Rust

Local

memkeeper is a local-first, durable memory engine for AI agents that stores, ranks, and retrieves context on-device using SQLite (BM25/FTS) with optional semantic (ONNX) retrieval.

Memory Lifecycle

remember — Write a single atomic memory (fact, decision, preference, lesson) with rich metadata: tags, confidence, validity windows, scope, supersession, and more.
forget — Soft-delete a memory by ID; use mode='correct' to record a factual correction signal.
verify — Re-confirm an existing memory is still accurate, updating its last-verified timestamp.
get — Fetch one memory by ID, optionally including version history and provenance.
memory_list — Browse recent memories in reverse-chronological order with optional filters.

Retrieval & Context Assembly

search — Relevance-ranked retrieval using semantic (embedding) search with BM25/FTS fallback and optional cross-encoder reranking.
pack — Assemble a compact, prompt-ready context block from one or more queries, with character budgeting, graph expansion, and query expansion options.

Entity Knowledge Graph

entity_upsert / entity_search — Create, update, or search entities (persons, projects, concepts) with canonical names, aliases, and metadata.
relationship_upsert — Create or update directed relationships between entities.
graph_neighbors — Traverse the graph outward from a starting entity to a bounded depth.
graph_context — Build a prompt-ready context block centered on one entity, including neighbors and linked memories.
dream_graph — Dry-run preview of entity/relationship extractions and merges without writing anything.

Human-Review Queue

candidate_submit — Queue a proposed memory for human review instead of writing it directly to recall.
candidate_list — List pending, approved, or rejected review candidates.

Store Inspection

stats — Report memory counts, breakdowns by space/silo/status/kind, schema version, DB size, and health rollups.

All operations are local-first (embedded SQLite), require no network for lexical search, and optionally use on-device ONNX models or an OpenAI-compatible API for semantic embeddings.

memkeeper

Local-first memory for AI agents. A fast, embeddable memory engine that stores, ranks, and retrieves an agent's durable context, entirely on your machine, with no required network or LLM calls.

Memkeeper is the open-source, local-first control plane that AI agents run on: durable memory, project context, coordinated task handoffs, and deny-by-default permissions, all deterministic and on your own machine. This repo is the memory engine at its core.

ℹ️ Generated release mirror. This repo is generated from a private development repo and published as releases. The main branch may be regenerated, so pin to tagged releases (or the release artifacts) rather than to arbitrary main commits — tagged releases are stable. See CONTRIBUTING.md for how to contribute; issues, security reports, and design feedback are the best paths today.

Local-first. A single SQLite database. No server, no cloud, no telemetry.
Fast at prompt time. Deterministic BM25/FTS retrieval with optional ONNX semantic embeddings and a cross-encoder reranker.
Durable by design. Atomic writes, schema-versioned storage, and a retention model that promotes recurring, high-signal memories to a durable tier.

Status: pre-release (v0.5.3). APIs and the wire protocol may change before 1.0.

Quickstart

# Install the latest release binary (macOS arm64 / Linux x86_64) to ~/.local/bin.
# It's self-contained — nothing else to install.
curl -fsSL https://raw.githubusercontent.com/teflon07/memkeeper/main/install.sh | bash

# Optional, one-time: fetch on-device semantic models. Lexical search works without it.
memkeeper pull-models

# Create a store, remember something, search it back.
memkeeper init
memkeeper remember --json '{"content":"memkeeper stores memories in a local SQLite database"}'
memkeeper search   --json '{"query":"where are memories stored","limit":3}'

That's the whole install: a self-contained binary, no runtime network/LLM/API key. Prefer not to pipe a script to your shell? Grab a binary from the releases page and verify its .sha256, or build from source. The store defaults to ~/.memkeeper/store.sqlite when --store is omitted; a --json value can also be @<file> or - (stdin) instead of an inline string, which avoids shell-quoting pitfalls (handy in Windows PowerShell).

Related MCP server: SharedBrain

Upgrade from v0.2.x

v0.3.0 introduced the schema 5 to schema 6 upgrade; v0.4.0 through v0.5.3 keep schema 6 unchanged. The migration is transactional, but schema 6 stores cannot be opened by v0.2.x. Stop any long-running memkeeper process and keep a schema 5 backup until you verify the upgrade.

Back up the store with your v0.2.x binary before installing the current release:

STORE=~/.memkeeper/store.sqlite
memkeeper backup --store "$STORE" --output "$STORE.schema5.bak" --json

Install the current release, run the migration explicitly, and verify the result before restarting any long-running process:

curl -fsSL https://raw.githubusercontent.com/teflon07/memkeeper/main/install.sh | bash
memkeeper init --store "$STORE" --json
memkeeper doctor --store "$STORE" --json

init is safe to rerun. If you need to roll back, restore the schema 5 backup before starting the older binary.

Use it from your agent (MCP)

memkeeper speaks MCP (JSON-RPC 2.0 over stdio), so any MCP client — Claude Code, Cursor, and others — can read and write memory during a session. Point your client's MCP config at the native binary (no Python, no extra deps):

{ "mcpServers": { "memkeeper": { "command": "memkeeper", "args": ["mcp"] } } }

The agent calls remember to capture a durable fact and search to recall it later, across separate sessions, with the same retrieval as the CLI.

What to store

memkeeper holds self-contained memories: facts, decisions, preferences, lessons. Each remember is one memory written to stand on its own, with its context and intent intact (store "the user likes pineapple on pizza," not just "pineapple"). Atomic means one idea per memory, not a stripped keyword. Retrieval, dedup, supersession, and the entity graph all work best at that grain.

Two ends to avoid:

Too small: a bare keyword or fragment that drops the point.
Too large: a whole document. The curated memory tier has no chunking, and the embedder sees only the first ~512 tokens of an entry, so loading long files (for example, an entire markdown library) gives weak semantic recall on those entries (lexical BM25 still indexes the full text). To bring whole documents in, don't store them as memories — use the document store, memkeeper's separate RAG tier that chunks and embeds files into an isolated space (the memkeeper-ingest add-on imports whole folders this way). Or distill the document down to its takeaways and store those as memories.

Capturing memories

memkeeper is curated memory you populate deliberately — not an automatic transcript logger. Memories get in two ways:

Directly — memkeeper remember --json '{"content":"…"}', from the CLI or a script.
From an agent — the native MCP server lets an MCP client (Claude and other agents) call remember during a session, so durable facts are captured as they come up. When a confirmed memory names entities or states a relationship, the MCP tool asks the agent to include a bounded graph projection in the same call. memkeeper validates and commits the memory, exact aliases, and typed relationships atomically. The one memory ID is the relationship evidence.

memkeeper does not run a second LLM or background extractor for this. The MCP host agent supplies the structured graph fields while making the normal remember call. Raw CLI callers can supply the same graph object explicitly.

On the retrieval side, memkeeper hook retrieve is a Claude Code UserPromptSubmit hook client that injects relevant memories into the prompt — so an agent recalls without an explicit search. It retrieves; capture stays a deliberate remember.

Semantic retrieval (default)

memkeeper has three retrieval modes. Local semantic is the default and the recommended, fully on-device mode. Pick one up front — the embedding backend is recorded in the store, so changing it means re-embedding (reindex --embed), not a flip.

Mode	Network	Setup
Local semantic (default)	none	install binary, then `pull-models`
Lexical only	none	works out of the box; just skip `pull-models`
Off-device semantic	embeds via an API	set `MEMKEEPER_EMBED_PROVIDER=openai` + base URL + key

Privacy: off-device semantic sends your memory text to the embeddings provider to be vectorized. Use it only where that is acceptable; the two on-device modes never send memory content anywhere.

Local semantic (default)

The release binary ships semantic-capable (the ONNX runtime is statically bundled), so there's no rebuild — it just needs the embed + rerank models, which aren't downloaded automatically. Fetch them once:

# Needs curl; ~2.1GB, or --quantized for ~0.6GB (slightly lower recall).
memkeeper pull-models

pull-models writes to ~/.memkeeper/models/ (override with MEMKEEPER_MODELS_DIR or --dir) — exactly where memkeeper looks by default. So semantic turns on with no env vars to set: run a search afterward and it's active.

If the models are missing, memkeeper does not degrade silently: it logs their absence and points you at pull-models, marks results semantic-unavailable (e.g. "semantic":{"attempted":false,"reason":"missing_embedding"}), and falls back to lexical (BM25/FTS) so search keeps working. Set MEMKEEPER_REQUIRE_SEMANTIC=1 to fail closed instead — refuse the request rather than serve degraded results — in any deployment that must never silently run lexical-only.

Embeddings are computed when a memory is written. Memories you stored before the models were present (for example, the one from the Quickstart above) are lexical-only until embedded. Backfill existing memories once with:

memkeeper reindex --embed

New memories written with the models in place are embedded automatically.

Lexical only

Skip pull-models and the release binary runs deterministic, model-free lexical-only (BM25/FTS) retrieval — zero network, zero models. Building from source with --no-default-features produces a leaner binary that omits the ONNX runtime entirely (see Build from source).

Off-device semantic (no model download)

Prefer not to download the ONNX models? Point memkeeper at an OpenAI-compatible embeddings API (OpenAI, OpenRouter, or any compatible proxy) instead. This mode embeds and reranks over the network rather than loading the local models, so it needs no pull-models:

# Embeddings (required for semantic): any OpenAI-compatible /embeddings endpoint.
export MEMKEEPER_EMBED_PROVIDER=openai     # "openai" = the OpenAI-compatible API dialect
export MEMKEEPER_EMBED_BASE_URL=https://api.openai.com/v1/embeddings   # or your provider, e.g. OpenRouter
export MEMKEEPER_EMBED_API_KEY=sk-...
export MEMKEEPER_EMBED_MODEL=text-embedding-3-small
export MEMKEEPER_EMBED_DIMS=1536

# Reranking (optional, recommended): Cohere /rerank dialect, which OpenRouter speaks.
export MEMKEEPER_RERANK_PROVIDER=openrouter
export MEMKEEPER_RERANK_API_KEY=sk-...
export MEMKEEPER_RERANK_MODEL=cohere/rerank-v3.5

The prebuilt release binaries support all three modes (--features semantic,api): run pull-models for fully on-device local semantic (the default and recommended mode), configure an API key for off-device semantic, or configure neither and they serve lexical (BM25/FTS). MEMKEEPER_REQUIRE_SEMANTIC=1 makes them refuse rather than serve degraded.

Prebuilt binaries are published for macOS (Apple Silicon) and Linux x86_64. Windows is experimental — there's no prebuilt binary, but it builds and runs from source; see docs/windows.md. (serve --socket is Unix-only there; the http dashboard and stdio serve are cross-platform.)

How `pack` combines semantic and graph retrieval

pack uses one retrieval path. Semantic and lexical matches supply memory seeds, exact entity and alias matches supply graph seeds, and bounded evidence-backed graph traversal joins both sets on canonical memory IDs. Every candidate then competes in the same cross-encoder rerank pool. Graph candidates receive no reserved slots or automatic demotion, and there is no production graph on/off mode. A store with no eligible graph route simply returns the semantic and lexical pool unchanged.

Switching the embedding model

The embedding backend is recorded per store, and memkeeper refuses to mix vectors from different models (they live in different vector spaces). To switch — local↔ off-device, or between models — change the embedding env vars, then re-embed every memory under the new model in one step:

./target/release/memkeeper reindex --embed --store ~/.memkeeper/store.sqlite

This wipes the old vectors, records the new active model, and re-embeds all active memories in one transaction. It is the supported way to change models; there is no partial mix.

Document store (RAG)

Alongside curated memories, memkeeper can hold a separate tier of ingested document chunks for retrieval-augmented use. Chunks live in their own space (default documents), isolated from the curated memory tier, so they never receive supersession, dedup, graph, or promotion treatment.

ingest — store a document source as embedded, isolated chunks. Re-ingesting the same source_path repairs that chunk's provenance in place; identical content under a different path is kept as an independent chunk.
document-search — hybrid (BM25 + vector) search over the chunks, with a citation back to source_path and chunk index.
document-get — fetch a document's chunks by path, or one chunk by id.
document-duplicates — surface exact-content duplicate chunks (the same content held under different sources) as clusters. stats also reports a document_duplicate_clusters count so you know when there are duplicates worth reviewing.
document-prune — delete the specific chunks you choose (supports dry_run). Deletion is always explicit: review duplicates, decide which copies to keep, then prune the rest.
promotion-candidates / mark-extracted — rank chunks that earned retrieval traffic, and mark a chunk extracted once it has been promoted into a memory.

Run memkeeper schema <command> for each command's accepted JSON fields. Over serve --http, reads (search/get/duplicates) are available on the read-only dashboard. Writes (ingest, document-prune) are disabled unless you set a write token: start the server with MEMKEEPER_HTTP_WRITE_TOKEN=<secret> in the environment, then send it on write requests as Authorization: Bearer <secret>. With no token set, the HTTP server is read-only.

The dashboard

memkeeper serve --http starts a read-only local dashboard (default http://127.0.0.1:7777) for browsing memories and the entity graph. Point it at a store with --store <path> (or MEMKEEPER_STORE); it uses the default store otherwise.

A fresh store starts empty — that's expected. Two views, populated differently:

The memory list fills as you remember.
The graph visualizes entities and relationships, which are a separate layer from raw memories. Native MCP remember captures bounded entities, aliases, and typed relationships with a confirmed memory when the host agent supplies them. Raw CLI callers can pass the same graph structure, or curate it with entity-upsert / relationship-upsert. The dream graph task may add generic related_to links for visualization, but those links are not retrieval evidence. Plain memories without graph fields still fill the list without adding graph edges.

Benchmarks

On LoCoMo (10 multi-session dialogues, 1,982 evidence-bearing questions), memkeeper's default semantic retrieval scores:

Metric	Score
recall@20	0.768
hit@20	0.880
MRR	0.668

Prompt-time search on a warm serve daemon (ONNX models loaded once) runs in ~25 ms p50/p95, about 32× faster than a cold per-call binary that reloads the models on every query.

Full methodology, per-config results (including the late-interaction upgrade), and a reproduction script are in docs/benchmarks.md.

Build from source

Building is optional — the Quickstart binary is self-contained. Build from source to track the latest main, produce a leaner lexical-only binary, or develop.

Prerequisites: a Rust toolchain (stable, via rustup; edition 2021, Rust 1.56+) and a C toolchain for the native deps (bundled SQLite plus the ONNX runtime for semantic search). macOS: Xcode Command Line Tools (xcode-select --install); Debian/Ubuntu: build-essential. Building fetches crates from crates.io the first time; after that a clean build is offline.

# Semantic build (default): local embeddings + cross-encoder rerank.
cargo build --release
# ...or lexical-only — omits the ONNX runtime and models entirely:
cargo build --release --no-default-features

# The binary lands at ./target/release/memkeeper (not on PATH). To install it:
cargo install --path crates/memkeeper-cli   # then a bare `memkeeper` works

Then memkeeper pull-models to enable semantic, exactly as in the Quickstart.

Workspace layout

Crate	Role
`memkeeper-core`	Core types and retrieval policy
`memkeeper-store`	SQLite storage, schema, indexing, promotion
`memkeeper-embed`	ONNX embeddings + cross-encoder reranker
`memkeeper-protocol`	Wire protocol (`memkeeper.v0.1`)
`memkeeper-cli`	The `memkeeper` binary (CLI + daemon)

Editor/agent integrations live under adapters/ (an MCP bridge and a thin extension client).

Memkeeper family

Warden is a companion capability broker and execution gate: it decides whether an agent's requested action (a shell command, a file read/write) is allowed by a declared, auditable policy, and logs every decision. memkeeper remembers; Warden guards.

License

Dual-licensed under either of MIT or Apache-2.0 at your option.

Contributing

See CONTRIBUTING.md. Contributions require signing the project Contributor License Agreement — the CLA bot prompts you on your first pull request. You keep the copyright to your contributions.

Available Tools

16 tools

candidate_listA

List memories in the human-review queue, filtered by review status. Read-only. Use to see what has been proposed via candidate_submit and its disposition; approving or rejecting candidates is a human action in the CLI/dashboard.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum candidates to return. Default 50.
`space`	No	Restrict to a single memory space (namespace).
`status`	No	Which queue to list. Default pending.

TDQS

A4/5.0

Behavior3/5

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

The description declares the tool as 'Read-only', which indicates no side effects, but with no annotations provided, it could add more details like auth requirements or rate limits. The disclosure is minimal but sufficient for a simple list operation.

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

Conciseness5/5

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

Two sentences with no wasted words. The first sentence states the core purpose, the second provides usage context and boundaries. Highly efficient.

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

Completeness4/5

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

The description is complete for a listing tool: it explains the purpose, read-only nature, and relationship to sibling tools. With no output schema, it could mention pagination or default behavior, but the schema already covers limit. Overall adequate.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already describes all three parameters (limit, space, status). The description adds context by mentioning 'filtered by review status' and linking to candidate_submit, but does not provide additional semantic detail beyond the schema.

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

Purpose4/5

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

The description clearly states the tool lists memories in the human-review queue filtered by review status. It differentiates from siblings by specifically mentioning the review queue and referencing candidate_submit, though it doesn't explicitly contrast with other listing tools like memory_list.

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

Usage Guidelines5/5

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

The description explicitly states when to use (to see proposed candidates via candidate_submit) and what not to do (approving/rejecting is a human action in CLI/dashboard), providing clear guidance and context for the agent.

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

candidate_submitA

Queue a proposed memory for human review instead of writing it to recall directly. Mutating: adds an item to the review queue (it does not enter recall until a human approves it via CLI/dashboard). Use this for plausible-but-unverified inferences; use remember when the fact is confirmed and should be recallable immediately.

ParametersJSON Schema

Name	Required	Description
`kind`	No	Memory kind (fact, decision, preference, lesson, ...).
`silo`	No	Retention tier the candidate targets (e.g. short-term, durable).
`tags`	No	Free-form tags.
`scope`	No	Visibility scope: global, workspace, project, session, or custom.
`space`	No	Memory space (namespace) the candidate targets.
`content`	Yes	The proposed memory text: one atomic, self-contained claim. Required.
`dry_run`	No	If true, validate without enqueuing. Default false.
`project`	No	Free-form project key.
`summary`	No	Optional shorter summary of the content.
`claim_key`	No	Stable key identifying the claim.
`rationale`	No	Why you are proposing this (evidence/reasoning) to help the human reviewer decide.
`confidence`	No	Confidence in the proposed memory, 0.0–1.0.
`entity_key`	No	Stable key of the entity this memory is about.
`supersedes`	No	Memory ids this candidate would replace if approved.
`sensitivity`	No	normal (default) or sensitive.
`source_type`	No	Provenance: assistant-inference (default) or explicit-user.

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, so the description carries full burden. It discloses that the tool is mutating ('adds an item to the review queue') and explains the review process. However, it does not mention potential side effects like queue limits or validation behavior beyond the dry_run parameter.

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

Conciseness5/5

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

Two sentences: first explains the action and its mutational nature, second provides usage guidance and alternative tool. Front-loaded, no wasted words.

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

Completeness3/5

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

Given the complexity of 16 parameters and no output schema, the description adequately explains the core function but does not specify return values or behavior when optional parameters are omitted. The 100% schema coverage partially compensates, but the missing output schema leaves some ambiguity.

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

Parameters3/5

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

Schema coverage is 100% with descriptions for all 16 parameters, so baseline is 3. The description does not add additional meaning to individual parameters beyond what the schema already provides.

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 queues a proposed memory for human review, using specific verbs like 'Queue' and 'adds an item to the review queue'. It directly contrasts with the sibling `remember` tool, which writes directly to recall.

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

Usage Guidelines5/5

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

Explicit guidance: use for 'plausible-but-unverified inferences' versus `remember` for 'confirmed facts'. Also notes that memories enter recall only after human approval via CLI/dashboard, providing clear when-to-use and when-not-to-use context.

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

dream_graphA

Preview the graph-maintenance pass in dry-run (proposal-only) mode: surfaces the entity and relationship extractions and merges the nightly dream job would make, without writing anything. Read-only; no side effects. Use to inspect what graph changes are pending before they are applied.

ParametersJSON Schema

Name	Required	Description	Default
`space`	No	Restrict the analysis to a single memory space (namespace).
`max_memories`	No	How many recent memories to analyze for proposals. Default 1000.

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 takes full responsibility for behavioral transparency. It clearly states the tool is 'Read-only; no side effects' and 'without writing anything,' fully disclosing its non-destructive nature.

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 a single, well-structured sentence that front-loads the core purpose (dry-run preview) and includes no extraneous words. Every clause adds value.

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

Completeness4/5

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

For a tool with no output schema, the description sufficiently explains what the tool does, its behavior, and use case. It could optionally mention the output format, but this does not detract from completeness.

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

Parameters3/5

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

Schema description coverage is 100% as both parameters have descriptions. The tool description provides high-level context for the parameters but does not add significant meaning beyond the schema. Baseline 3 is appropriate.

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 that the tool previews graph maintenance changes in dry-run mode, specifying it surfaces entity and relationship extractions and merges without writing anything. This distinguishes it from siblings like 'candidate_submit' which likely applies changes.

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

Usage Guidelines4/5

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

The description explicitly says 'Use to inspect what graph changes are pending before they are applied,' providing clear usage context. It implies it is a safe read-only alternative, though it does not explicitly name alternatives like 'candidate_submit'.

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

entity_searchA

Search the entity graph by key, canonical name, alias, or type (substring match). Read-only. Returns entity records, not memories — use it to resolve an entity_key or canonical name from a partial term. For memory content use search; to traverse outward from a known entity use graph_neighbors or graph_context.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of entities to return. Default 10.
`query`	No	Substring matched against entity key, canonical name, and aliases.
`entity_key`	No	Filter to an exact entity key.
`entity_type`	No	Filter by entity type (e.g. person, project, concept).
`include_source`	No	If true, reveal provenance/source metadata. Default false.

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so description carries burden. It declares read-only and returns entity records, but lacks details on ordering, pagination, or exact structure of returned records. Adequate but not rich.

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

Conciseness5/5

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

Two concise sentences. First sentence states purpose, second gives usage guidelines and alternatives. No superfluous information. Front-loaded with key action.

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

Completeness4/5

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

With 5 parameters (all optional) and no output schema, description covers when to use and what it does. Lacks details on result ordering, pagination, or exact content of entity records, but sufficient for basic search tool.

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

Parameters3/5

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

Schema coverage is 100%, so baseline is 3. Description adds context that 'query' is substring matched against key, canonical name, aliases, but this is already implicit in schema. No significant added value beyond 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 searches the entity graph by key, canonical name, alias, or type with substring match. It explicitly distinguishes from sibling tools like 'search' (for memories), 'graph_neighbors', and 'graph_context'.

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

Usage Guidelines5/5

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

Provides explicit guidance on when to use this tool: to resolve an entity_key or canonical name from partial term. Also states when to use alternatives: 'search' for memory content, 'graph_neighbors' or 'graph_context' for graph traversal.

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

entity_upsertA

Create or update one entity in the graph projection (register it, rename it, or add aliases). Mutating. The graph is a rebuildable projection over memories, which remain the source of truth — use this to curate entity identity, not to store facts (use remember for facts).

ParametersJSON Schema

Name	Required	Description
`space`	No	Memory space (namespace) the entity belongs to.
`status`	No	Lifecycle status (e.g. active, tombstoned).
`aliases`	No	Alternate names/surface forms that should resolve to this entity.
`metadata`	No	Arbitrary key/value attributes to attach to the entity.
`confidence`	No	Confidence in the entity, 0.0–1.0.
`entity_key`	Yes	Stable, unique key identifying the entity. Required.
`entity_type`	No	Type of entity (e.g. person, project, concept, tool).
`canonical_name`	Yes	Primary display name for the entity. Required.
`include_source`	No	If true, reveal provenance/source metadata in the response. Default false.
`source_episode_id`	No	Id of the source episode this entity was derived from, if any.

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so the description must carry the burden. It states the tool is mutating and that the graph is rebuildable from memories, implying non-destructive changes. However, it omits details like idempotency or unique constraints on entity_key, leaving some behavioral gaps.

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

Conciseness5/5

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

Two sentences, front-loaded with the core action, followed by crucial context. Every word earns its place; no fluff.

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

Completeness4/5

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

Covers the primary functionality and differentiates from related tools. With 10 parameters and no output schema, some guidance on responses or effects of optional parameters would improve completeness, but the description is still adequate.

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

Parameters3/5

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

Schema coverage is 100% with clear parameter descriptions in JSON. The description adds no extra meaning beyond basic purpose and usage context, so it meets the baseline but does not elevate understanding of parameters.

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 it creates or updates entities in the graph projection, specifying actions like register, rename, or add aliases. It differentiates from siblings by noting that facts should be stored with `remember`, not here.

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

Usage Guidelines5/5

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

Explicitly advises using this tool for entity identity curation and not for facts, directing to `remember` for facts. It also explains the graph is a rebuildable projection, setting context for when modifications are appropriate.

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

forgetA

Retire one specific memory by id. Mutating: tombstones the memory (a soft delete that preserves audit history), so it stops surfacing in recall; it is not a hard delete. Set mode='correct' when retiring a memory because it is WRONG (e.g. a surfaced/recalled fact the user contradicted), as opposed to routine cleanup: this records a distinct correct event with the memory's provenance, and if you pass corrected_by (the id of the memory holding the right answer) it also records a contradicts link. Use mode='correct' for factual corrections so the signal is captured explicitly rather than inferred later.

ParametersJSON Schema

Name	Required	Description
`mode`	No	tombstone (default) for routine cleanup; correct when the memory was factually wrong (records a correction signal).
`reason`	No	Why the memory is being retired (recorded in the audit trail).
`dry_run`	No	If true, validate without retiring. Default false.
`memory_id`	Yes	Id of the memory to retire. Required.
`corrected_by`	No	With mode='correct', the id of the memory holding the right answer (records a contradicts link).

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description fully discloses that the operation is a soft delete (tombstone), preserves audit history, and that mode='correct' records additional events. It also explains the audit trail for reason and the contradicts link.

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

Conciseness4/5

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

The description is information-dense and front-loaded with the primary action. It could be slightly more concise but avoids unnecessary details.

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?

Without an output schema, the description thoroughly explains what happens (soft delete, audit trail, correction events). It covers all key behavioral aspects and use cases.

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 coverage is 100%, providing baseline. The description adds value beyond schema by explaining the purpose of mode and corrected_by in context, though the schema already describes them adequately.

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 retires one specific memory by ID, explains the soft-delete mechanism, and distinguishes between modes. It is specific, uses a clear verb (retire) and resource (memory), and differentiates from sibling tools like memory_list or search.

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

Usage Guidelines4/5

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

The description provides explicit guidance on when to use mode='correct' versus the default tombstone, and explains the corrected_by parameter. However, it does not explicitly state when not to use this tool or offer comparisons to alternatives.

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

getA

Fetch one memory by its exact id (for example, an id returned by search or memory_list). Read-only. Use when you already have the id and want the full record; use search to find a memory by its content.

ParametersJSON Schema

Name	Required	Description
`memory_id`	Yes	The memory's id. Required.
`include_source`	No	If true, reveal provenance/source metadata. Default false.
`include_history`	No	If true, include the memory's version/change history. Default false.

TDQS

A4.4/5.0

Behavior4/5

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

The description declares the tool as 'Read-only', which is a key behavioral trait, especially in the absence of annotations. However, it does not elaborate on other behavioral aspects like no side effects or return format, but for a simple fetch operation this is sufficient.

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 two sentences long, front-loads the core purpose, and provides essential usage guidance without any wasted words. Every sentence is meaningful.

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

Completeness4/5

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

For a simple read operation with three well-documented parameters and no output schema, the description adequately covers purpose, usage, and read-only nature. It could mention that the full record is returned, but the implied completeness is acceptable.

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

Parameters3/5

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

The input schema has 100% documentation coverage for its three parameters. The description adds minimal additional semantic value beyond the schema (e.g., 'exact id'), but the baseline of 3 is appropriate since the schema already describes the parameters well.

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

Purpose5/5

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

The description uses the specific verb 'Fetch' and clearly identifies the resource ('one memory by its exact id'), with an example. It distinguishes itself from the sibling tool 'search' by specifying different use cases.

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

Usage Guidelines5/5

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

The description explicitly states when to use this tool ('when you already have the id') and when not to ('use search to find a memory by its content'), providing clear guidance on alternatives.

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

graph_contextA

Build a compact, prompt-ready context pack centered on an entity: the entity, its graph neighbors, and the most relevant linked memories, budgeted to a character limit. Read-only. Use when an agent needs ready-to-inject context about one specific entity; use pack for query-driven context, or graph_neighbors for raw graph edges.

ParametersJSON Schema

Name	Required	Description
`depth`	No	Number of relationship hops to include. Default 1.
`max_chars`	No	Character budget for the assembled pack. Default 4000.
`max_edges`	No	Maximum relationships to include. Default 50.
`entity_key`	Yes	Entity key the context pack is centered on. Required.
`max_memories`	No	Maximum linked memories to include. Default 10.
`include_source`	No	If true, reveal provenance/source metadata. Default false.

TDQS

A4.3/5.0

Behavior4/5

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

The description declares the tool is 'Read-only' and explains it is budgeted to a character limit, which are important behavioral traits. No annotations are provided, so the description carries full burden. It could additionally mention error handling or behavior if limits are exceeded, but overall is clear.

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

Conciseness5/5

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

Two sentences: first states the core action and output; second provides usage guidance. No extraneous words, information is front-loaded.

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

Completeness3/5

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

Given no output schema, the description could have explained the return format or error behavior more explicitly. It mentions 'prompt-ready context pack' but is vague. Adequate but not comprehensive.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description does not add additional parameter meaning beyond the schema's own descriptions, which are sufficient.

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 builds a prompt-ready context pack centered on an entity, with specific components (entity, neighbors, memories) and a character limit. It distinguishes from sibling tools by contrasting with `pack` and `graph_neighbors`.

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

Usage Guidelines5/5

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

Explicitly states when to use this tool ('when an agent needs ready-to-inject context about one specific entity') and when to use alternatives (`pack` for query-driven, `graph_neighbors` for raw edges).

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

graph_neighborsA

Traverse the entity graph outward from a starting entity, returning connected entities and the relationships between them up to a bounded depth. Read-only. Use to explore how an entity connects to others (raw graph structure); use graph_context if you want a prose, prompt-ready context pack instead of edges.

ParametersJSON Schema

Name	Required	Description
`depth`	No	Number of relationship hops to follow. Default 1.
`max_edges`	No	Maximum relationships to return (bounds the traversal). Default 50.
`entity_key`	Yes	Entity key to start the traversal from. Required.
`include_source`	No	If true, reveal provenance/source metadata. Default false.
`include_tombstoned`	No	If true, include tombstoned (soft-deleted) entities/edges. Default false.

TDQS

A4.4/5.0

Behavior4/5

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

No annotations exist, so description carries full burden. It clearly states 'Read-only' and describes the traversal behavior. However, it does not disclose potential side effects, auth requirements, or rate limits, though these are less critical for a read-only tool.

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

Conciseness5/5

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

Two sentences with no filler. First sentence states core purpose, second provides usage comparison. Every word earns its place.

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

Completeness4/5

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

Given 5 parameters and no output schema, the description covers core behavior and provides usage context. It does not specify the exact output format (e.g., list of nodes and edges), but the high-level description is sufficient for an agent to understand what it returns.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description adds minimal parameter semantics beyond what schema already provides, aside from the 'bounded depth' and 'bounds the traversal' context for depth and max_edges.

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?

Description clearly states the action (traverse), resource (entity graph), and output (connected entities and relationships). It distinguishes from the sibling tool graph_context by specifying raw graph structure vs. prose.

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

Usage Guidelines5/5

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

Explicitly tells when to use this tool ('explore how an entity connects to others') and when to use the alternative graph_context ('if you want a prose, prompt-ready context pack'). This provides clear decision guidance.

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

memory_listA

List recent memories in reverse-chronological order for review or cleanup, optionally filtered. Read-only. Use to browse or audit what is stored (including stale or superseded entries); use search or pack for relevance-ranked retrieval against a query.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of memories to return. Default 20.
`space`	No	Restrict to a single memory space (namespace), or "*" for all spaces. Omit for the default space.
`status`	No	Filter by lifecycle status (e.g. active, superseded, tombstoned). Omit for active memories.
`entity_key`	No	Restrict to memories linked to this entity key.
`include_source`	No	If true, reveal provenance/source metadata. Default false.
`include_content`	No	If true, return each memory's full text instead of a snippet. Default false.

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the burden. It declares the tool is read-only and lists results in reverse-chronological order. While it doesn't detail return format or pagination, the core behavioral trait (read-only audit) is clearly communicated.

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

Conciseness5/5

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

Two sentences with no wasted words. Critical information (purpose, order, readonly, alternatives) is front-loaded. Every sentence earns its place.

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

Completeness4/5

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

For a 6-parameter list tool with no output schema, the description covers purpose, usage, and behavioral constraints. It lacks mention of return structure but is otherwise complete given the tool's simplicity.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description does not add parameter-specific details beyond the schema, but it frames the overall filtering capability ('optionally filtered'), which is acceptable.

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?

Clearly states the verb 'list', resource 'memories', and key behaviors: reverse-chronological order, optional filtering, read-only. Distinguishes from siblings like search and pack by mentioning relevance-ranked retrieval.

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

Usage Guidelines5/5

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

Explicitly states 'Read-only' and provides explicit usage context: 'Use to browse or audit what is stored (including stale or superseded entries)' and directs to alternatives: 'use search or pack for relevance-ranked retrieval against a query.'

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

packA

Assemble a compact, prompt-ready context block from one or more queries: retrieves, reranks, and budgets the top memories into injectable text. Read-only. This is the retrieval path for putting memory into an agent's prompt; use search instead when you want individual scored records rather than an assembled block.

ParametersJSON Schema

Name	Required	Description
`tags`	No	Restrict retrieval to memories carrying these tags.
`space`	No	Restrict retrieval to a single memory space (namespace), or "*" for all spaces. Omit for the default space.
`title`	No	Heading for the assembled pack. Default "context".
`queries`	Yes	One or more natural-language queries to retrieve and merge into the pack. Required.
`max_chars`	No	Character budget for the assembled pack. Default 6000.
`min_score`	No	Drop memories scoring below this threshold; the pack abstains (returns empty) when nothing clears it. Default 0 (no floor).
`graph_decay`	No	Default 0.5. Per-hop activation decay for graph expansion.
`max_memories`	No	Maximum memories to include in the pack. Default 10.
`graph_expansion`	No	Default false. Associative recall: graph-expand the rerank pool one hop from the top seeds so a relationship-reachable memory below the ANN/BM25 threshold can still be reranked (hybrid_assoc_v0).
`max_graph_seeds`	No	Default 3. Top-of-pool anchors used for graph expansion.
`query_expansion`	No	Default false. Deterministically add subqueries before retrieval.
`max_thread_seeds`	No	Default 3.
`thread_expansion`	No	Default false. Add same-entity/same-claim neighbors to the rerank pool.
`graph_rerank_slots`	No	Default 0. Reserve N pack slots for top-activation graph candidates so a hop-reached memory the reranker scored low can still land (0 = recall-widening only).
`max_query_variants`	No	Default engine maximum.
`max_graph_neighbors`	No	Default 5. Graph-reachable neighbors unioned into the pool (activation budget).
`max_thread_neighbors`	No	Default 3.
`graph_activation_floor`	No	Default 0.0. Minimum activation a graph candidate needs to claim a reserved rerank slot.
`graph_within_entity_maxsim`	No	Default false. Experimental: select one memory per graph entity by first-query MaxSim; requires late-interaction tokens.

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description alone must convey behavioral traits. It explicitly states 'Read-only' and mentions the retrieval, reranking, and budgeting process. It also hints at behavior with `min_score` ('abstains when nothing clears it'). While not exhaustive, it covers key behaviors.

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 two sentences, each earning its place. The first states the primary action, the second provides usage guidance and distinguishes from a sibling. No waste, perfectly concise.

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

Completeness4/5

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

Given the tool's complexity (19 parameters, no output schema, no annotations), the description provides a solid high-level overview and usage context. It lacks details on output format but compensates with clear purpose and sibling differentiation. The thorough schema fills many gaps, making the description fairly complete for effective selection.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description adds some context for parameters like `queries`, `max_chars`, and `min_score` but does not significantly enhance understanding beyond the schema. The description's added value is moderate.

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 identifies the tool's function: 'Assemble a compact, prompt-ready context block from one or more queries: retrieves, reranks, and budgets the top memories into injectable text.' It also distinguishes it from the sibling tool `search` by specifying when to use each, making the purpose very specific and clear.

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

Usage Guidelines5/5

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

The description explicitly states when to use this tool vs. `search`: 'use `search` instead when you want individual scored records rather than an assembled block.' It also notes that it is read-only, providing clear context for usage.

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

relationship_upsertA

Create or update one directed relationship in the graph: subject --relation_type--> object. Mutating. Identify each endpoint by entity_key (preferred) or internal entity_id. The graph is a rebuildable projection over memories — curate structure here, store facts with remember.

ParametersJSON Schema

Name	Required	Description
`space`	No	Memory space (namespace) the relationship belongs to.
`status`	No	Lifecycle status (e.g. active, tombstoned).
`metadata`	No	Arbitrary key/value attributes to attach to the relationship.
`valid_to`	No	RFC 3339 timestamp the relationship stops being valid.
`memory_id`	No	Id of the memory this relationship was derived from, if any.
`confidence`	No	Confidence in the relationship, 0.0–1.0.
`valid_from`	No	RFC 3339 timestamp the relationship starts being valid.
`observed_at`	No	RFC 3339 timestamp of when this was observed.
`relation_type`	Yes	The relationship type/predicate (e.g. depends_on, works_with, part_of). Required.
`include_source`	No	If true, reveal provenance/source metadata in the response. Default false.
`object_entity_id`	No	Internal id of the object endpoint (alternative to object_entity_key).
`object_entity_key`	No	Entity key of the object (target) endpoint. Preferred over object_entity_id.
`source_episode_id`	No	Id of the source episode this relationship was derived from, if any.
`subject_entity_id`	No	Internal id of the subject endpoint (alternative to subject_entity_key).
`subject_entity_key`	No	Entity key of the subject (source) endpoint. Preferred over subject_entity_id.

TDQS

A3.9/5.0

Behavior3/5

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

The description states 'Mutating' and describes the graph as a rebuildable projection, but does not detail conflict resolution on upsert (replace/merge), required permissions, or side effects on the projection. Without annotations, these omissions limit transparency.

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 two concise sentences: the first communicates the core action, the second adds context about the graph's relationship to memories. No fluff, front-loaded.

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

Completeness3/5

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

Given the complexity (15 params, no output schema), the description adequately covers purpose and endpoint identification but omits return value details, conflict resolution behavior, and impact on the graph projection. More completeness is needed for a complex mutation tool.

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

Parameters3/5

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

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds minimal value by noting endpoint identification preference, but does not elaborate on parameter semantics beyond what the schema provides.

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 it creates or updates a directed relationship in the graph, specifying the structure subject --relation_type--> object. It distinguishes itself from sibling tools like entity_upsert (entity focus) and remember (fact storage).

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

Usage Guidelines4/5

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

The description explains when to use this tool ('curate structure here') versus remember ('store facts'). It also instructs on endpoint identification (entity_key preferred over entity_id). However, it lacks explicit when-not-to-use scenarios or alternatives.

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

rememberA

Write one durable memory the agent should be able to recall later. Mutating: persists a memory (set dry_run to validate without writing). Store exactly one atomic, self-contained fact, decision, preference, or lesson per call — include enough context that it stands alone ("the user deploys from the release branch, never main", not just "release branch"). Do not store secrets or raw transcripts. For a plausible-but-unverified inference, use candidate_submit instead so a human approves it first.

ParametersJSON Schema

Name	Required	Description
`kind`	No	Memory kind (fact, decision, preference, lesson, action, ...). Inferred from the content prefix when omitted.
`mode`	No	How to resolve against existing memories sharing the same entity/claim key. Default auto.
`silo`	No	Retention tier (e.g. short-term, durable). Omit to use the space default.
`tags`	No	Free-form tags for filtering and retrieval boosts.
`scope`	No	Visibility scope: global, workspace, project, session, or custom.
`space`	No	Memory space (namespace) to write into. Omit for the default space.
`pinned`	No	If true, exempt from automatic eviction. Default false.
`content`	Yes	The memory text: one atomic, self-contained claim with enough context to stand on its own. Required.
`dry_run`	No	If true, validate and return what would be written without persisting. Default false.
`project`	No	Free-form project key this memory belongs to.
`summary`	No	Optional shorter summary of the content.
`valid_to`	No	RFC 3339 timestamp the fact stops being true (past values are excluded from recall).
`claim_key`	No	Stable key identifying the claim, used to group versions for supersession.
`confidence`	No	Confidence in the memory, 0.0–1.0. Default 1.0.
`entity_key`	No	Stable key of the entity this memory is about (groups related memories in the graph).
`expires_at`	No	RFC 3339 timestamp after which the memory is dropped from recall.
`supersedes`	No	Memory ids this memory replaces (they become superseded).
`valid_from`	No	RFC 3339 timestamp the fact starts being true.
`contradicts`	No	Memory ids this memory conflicts with.
`derive_keys`	No	Auto-derive entity_key/claim_key from the content when not provided. Default true.
`observed_at`	No	RFC 3339 timestamp of when this was observed. Defaults to now.
`sensitivity`	No	Mark sensitive to flag the memory for stricter handling. Default normal.
`source_type`	No	Provenance: assistant-inference (default) when the agent inferred it, or explicit-user when the user stated it directly.
`verified_against`	No	What this memory was checked against, if any.

TDQS

A4.3/5.0

Behavior4/5

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

No annotations exist, so the description carries full burden. It states persistence, dry_run behavior, and atomicity requirements. However, it does not mention error conditions, success/failure responses, or side effects like eviction.

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

Conciseness4/5

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

The description is a single paragraph, front-loaded with the core purpose and behavioral instructions. Compact but clear, with no unnecessary words.

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

Completeness4/5

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

For a tool with 24 parameters and no output schema, the description covers the primary use case and provides enough context for the agent to use it correctly. Lacks detailed return value information but that is mitigated by the schema and dry_run mention.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description elaborates on the content parameter's format and the dry_run parameter's purpose, but does not detail other parameters beyond what the schema provides.

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 verb ('Write'), resource ('durable memory'), and the single action per call. It also distinguishes from the sibling tool 'candidate_submit' by noting when to use that instead.

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

Usage Guidelines5/5

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

Explicitly provides when to use (atomic facts), what not to store (secrets, raw transcripts), and an alternative tool for unverified inferences. Also mentions dry_run for validation without persisting.

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

searchA

Find individual memories ranked by relevance to a query. Semantic-primary when embedding models are loaded, falling back to deterministic BM25/FTS keyword search otherwise; cross-encoder reranked by default. Read-only. Returns scored, individual memory records (with ids) — use this to locate or inspect specific memories. To assemble a prompt-ready context block, use pack instead; to browse recent memories without a query, use memory_list.

ParametersJSON Schema

Name	Required	Description
`tags`	No	Restrict to memories carrying these tags.
`limit`	No	Maximum number of memories to return. Default 10.
`query`	Yes	Natural-language search query. Required.
`space`	No	Restrict to a single memory space (namespace), or "*" for all spaces. Omit to search the default space.
`rerank`	No	Apply the cross-encoder reranker to the candidate pool. Default true.
`entity_key`	No	Restrict to memories linked to this entity key.
`include_source`	No	If true, reveal provenance/source metadata. Default false.
`include_content`	No	If true, return each memory's full text instead of a snippet. Default false.
`semantic_enabled`	No	Force semantic retrieval on or off. Default: on when embedding models are available, else lexical.

TDQS

A4.4/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 full burden. It discloses read-only nature, the dual search algorithm (semantic with fallback), cross-encoder reranking, and output format (scored records with ids). It does not mention potential side effects or rate limits, but for a search tool it is adequately transparent.

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

Conciseness5/5

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

Three sentences front-loaded with core purpose, followed by algorithmic nuance and sibling contrasts. Every sentence earns its place; no waste.

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

Completeness4/5

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

Given 9 parameters and no output schema or annotations, the description covers key behavioral aspects (fallback, reranking, read-only) and contrasts with two siblings. It mentions output includes scored records with ids, which is helpful, but missing details about pagination or return format.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description does not add new meaning beyond the schema; it only restates that output includes ids. The schema already documents all parameters.

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 specifies the verb 'Find', the resource 'individual memories', and the ranking method. It clearly distinguishes itself from siblings by stating when to use 'pack' for context assembly and 'memory_list' for browsing without a query.

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

Usage Guidelines5/5

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

The description explicitly provides when-to-use guidance ('locate or inspect specific memories') and contrasting alternatives ('use `pack` instead' for context blocks, 'use `memory_list`' for recent memories without a query).

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

statsA

Report store statistics: total/active memory counts, breakdowns by space, silo, status, and kind, schema version, and database size. Read-only; no side effects. Use to inspect the store's overall state and health, not to retrieve memories (use search or pack for that).

ParametersJSON Schema

Name	Required	Description	Default
`include_health`	No	If true, add the governance/health rollup (counts of stale, expiring, and low-confidence memories). Default false.
`include_indexes`	No	If true, add per-index row counts. Default false.

TDQS

A4.4/5.0

Behavior4/5

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

Explicitly declares 'Read-only; no side effects,' which is the key behavioral trait. Lacks details on auth or rate limits but sufficient for a simple stats tool.

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

Conciseness5/5

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

Two concise sentences, front-loaded with purpose, no fluff.

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

Completeness4/5

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

Covers purpose, side effects, and usage; could detail output format more but acceptable given no output schema and low complexity.

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

Parameters3/5

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

Schema coverage is 100% with descriptions for both parameters. The description adds overall context but does not significantly enhance parameter meaning beyond 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?

Description explicitly states it reports store statistics, listing specific metrics (memory counts, breakdowns, etc.). It also distinguishes from siblings by stating not to use for memory retrieval, referencing 'search' and 'pack'.

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

Usage Guidelines5/5

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

Clearly states when to use (inspect store state/health) and when not to use (retrieve memories), with explicit alternative tools named.

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

verifyA

Re-confirm that an existing memory is still accurate as of now, stamping its last-verified time. Mutating: updates verification metadata only — it does NOT change the memory's content or promote it to a durable tier. If the value has CHANGED, do not verify; write a new memory with remember and supersede the old one instead.

ParametersJSON Schema

Name	Required	Description	Default
`memory_id`	Yes	Id of the memory being re-confirmed. Required.
`verified_against`	No	The source or ground truth the memory was checked against.

TDQS

A4.4/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses that the tool is mutating but only affects verification metadata. However, it does not mention error handling (e.g., if memory_id is invalid) or return value, which could be important.

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

Conciseness5/5

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

The description is concise with three sentences, each serving a clear purpose: stating the action, clarifying the mutation scope, and providing usage guidelines. It is front-loaded and contains no filler.

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

Completeness4/5

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

For a simple tool with two parameters and no output schema, the description covers purpose, usage, and behavioral constraints well. It lacks information on error cases or what happens if memory_id is missing, but overall is sufficiently complete.

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

Parameters3/5

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

Both parameters are fully described in the input schema (100% coverage). The main description adds no additional meaning beyond what the schema already provides for the parameters, meeting the baseline of 3.

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

Purpose5/5

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

The description clearly states the tool re-confirms an existing memory's accuracy and stamps its last-verified time. It explicitly contrasts with the sibling tool 'remember' for when content changes, making the purpose specific and distinct.

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

Usage Guidelines5/5

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

Provides explicit guidance on when to use (memory still accurate) and when not to (if value changed, use 'remember' instead). Also clarifies that it only updates verification metadata, not content or durability tier.

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 updatev0.3.1Jul 15, 2026

Changedpack1 field changed

addedInput schema / properties / graph_within_entity_maxsim

Added value: +{
+  "description": "Default false. Experimental: select one memory per graph entity by first-query MaxSim; requires late-interaction tokens.",
+  "type": "boolean"
+}

3 tool updatesv0.2.14Jul 10, 2026

Changedmemory_list1 field changed

changedInput schema / properties / space / description

Previous value: -"Restrict to a single memory space (namespace)."New value: +"Restrict to a single memory space (namespace), or \"*\" for all spaces. Omit for the default space."

Changedpack7 fields changed

addedInput schema / properties / graph_activation_floor

Added value: +{
+  "description": "Default 0.0. Minimum activation a graph candidate needs to claim a reserved rerank slot.",
+  "type": "number"
+}

addedInput schema / properties / graph_decay

Added value: +{
+  "description": "Default 0.5. Per-hop activation decay for graph expansion.",
+  "type": "number"
+}

addedInput schema / properties / graph_expansion

Added value: +{
+  "description": "Default false. Associative recall: graph-expand the rerank pool one hop from the top seeds so a relationship-reachable memory below the ANN/BM25 threshold can still be reranked (hybrid_assoc_v0).",
+  "type": "boolean"
+}

addedInput schema / properties / graph_rerank_slots

Added value: +{
+  "description": "Default 0. Reserve N pack slots for top-activation graph candidates so a hop-reached memory the reranker scored low can still land (0 = recall-widening only).",
+  "type": "integer"
+}

addedInput schema / properties / max_graph_neighbors

Added value: +{
+  "description": "Default 5. Graph-reachable neighbors unioned into the pool (activation budget).",
+  "type": "integer"
+}

addedInput schema / properties / max_graph_seeds

Added value: +{
+  "description": "Default 3. Top-of-pool anchors used for graph expansion.",
+  "type": "integer"
+}

changedInput schema / properties / space / description

Previous value: -"Restrict retrieval to a single memory space (namespace)."New value: +"Restrict retrieval to a single memory space (namespace), or \"*\" for all spaces. Omit for the default space."

Changedsearch1 field changed

changedInput schema / properties / space / description

Previous value: -"Restrict to a single memory space (namespace). Omit to search the default space."New value: +"Restrict to a single memory space (namespace), or \"*\" for all spaces. Omit to search the default space."

16 tool updatesv0.1.0Jun 28, 2026
- First observedcandidate_list
- First observedcandidate_submit
- First observeddream_graph
- First observedentity_search
- First observedentity_upsert
- First observedforget
- First observedget
- First observedgraph_context
- First observedgraph_neighbors
- First observedmemory_list
- First observedpack
- First observedrelationship_upsert
- First observedremember
- First observedsearch
- First observedstats
- First observedverify

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: remember vs candidate_submit for confirmed vs unverified facts; search vs pack for records vs assembled context; get vs memory_list for single vs list retrieval; entity tools are well-separated from memory tools. No overlapping responsibilities.

Naming Consistency4/5

Most tools follow a verb_noun pattern in snake_case (entity_search, candidate_submit, memory_list). A few are single verbs (remember, forget, search, get, verify, stats) which are intuitive but deviate slightly. Overall pattern is coherent and predictable.

Tool Count5/5

16 tools cover memory storage, retrieval, curation, entity graph management, and statistics without being overwhelming. Each tool serves a specific need and the count is well-scoped for the domain.

Completeness4/5

Core memory CRUD is present: create (remember, candidate_submit), read (search, get, memory_list, stats), soft delete (forget). Entity and relationship upsert covers create/update. Missing an explicit memory update tool and a tool to trigger graph rebuild (dream applies nightly). Minor gaps but overall functional.

Maintenance

ActivityMaintained

ResponsivenessUnresponsive

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

MemorySyncOAuth
io.memorysync
Persistent memory for AI agents. Search and store durable facts, preferences and decisions.
Knowledge & Memory Autonomous Agents
1
Ace Memory BOAuth
io.github.rudedoggg
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
Knowledge & Memory RAG Systems Autonomous Agents
4
AI Context FlowOAuth
network.plurality
Universal memory for AI agents and tools. Save, organize and search context anywhere.
Knowledge & Memory Search
22
goldhold
io.github.jerrysrodz
Persistent memory for AI agents. Search, store, and recall across sessions.
Knowledge & Memory Autonomous Agents RAG Systems
2

Related MCP Servers

mem0-mcpofficial
Knowledge & Memory Vector Databases Search
tensakulabs
A
license
A
quality
C
maintenance
Self-hosted Mem0 MCP server integrating Qdrant, Neo4j, and Ollama for semantic memory search, graph entity relationships, and memory management via OpenMemory API.
Updated 7 months ago (2026-02-14 09:29 UTC)
6
4
MIT
SharedBrain
Knowledge & Memory Search
awictor
A
license
Not graded
quality
B
maintenance
Local-first, multi-user shared memory for AI agents with semantic search, offline support, and team synchronization.
Updated 2 months ago (2026-06-25 23:52 UTC)
MIT
Geniro Graphiti MCPofficial
Knowledge & Memory AI & Machine Learning
geniro-io
A
license
Not graded
quality
B
maintenance
A Model Context Protocol server that provides Claude CLI with a Graphiti knowledge-graph memory backed by Neo4j, featuring synchronous writes and no silent ingestion failures.
Updated 2 months ago (2026-06-28 19:30 UTC)
Apache 2.0
io.github.oxgeneral/agentmem
oxgeneral
A
license
Not graded
quality
C
maintenance
Lightweight persistent memory for AI agents using a single SQLite file with hybrid search (keywords + semantics). Zero to 12MB install, no cloud or server required.
Updated 6 months ago (2026-02-28 12:34 UTC)
4
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/teflon07/memkeeper'

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

memkeeper

Quickstart

Upgrade from v0.2.x

Use it from your agent (MCP)

What to store

Capturing memories

Semantic retrieval (default)

Local semantic (default)

Lexical only

Off-device semantic (no model download)

How pack combines semantic and graph retrieval

Switching the embedding model

Document store (RAG)

The dashboard

Benchmarks

Build from source

Workspace layout

Further reading

Memkeeper family

License

Contributing

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

mem0-mcpofficial

Geniro Graphiti MCPofficial

Latest Blog Posts

MCP directory API

How `pack` combines semantic and graph retrieval