Skip to main content
Glama
yamantaka520

agent-memory-os

by yamantaka520
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

A local-first memory system for AI-agent teams — not just giving one agent a memory, but a shared memory fabric for a fleet of agents working together: private, team, and project-scoped memories behind a hard ACL, associative recall, and federated sync that keeps a mesh of nodes (and their org structure) in agreement. One SQLite file, zero required dependencies, Apache-2.0.

Why

Real work happens in teams of agents — a project might mix Claude Code, Codex, OpenClaw, and several Hermes profiles, across multiple teams and projects, on one machine or many. They need to share the right knowledge with the right teammates and keep private what should stay private:

  • Per-agent memory is the floor, not the ceiling: durable facts, preferences, procedures, and lessons that survive across sessions.

  • Team & project memory is the point: a team sees team:<id> memory; a project (a subset of the team) sees project:<id> memory; nothing leaks across the boundary. Membership is first-class and manageable, and drives the ACL.

  • Federation keeps a mesh honest: memories and the org structure (teams/projects/memberships) converge across nodes, so project:<id> means the same thing everywhere.

  • Local-first avoids the latency, cost, and privacy tradeoffs of cloud memory platforms — memories live in a local SQLite file, and each prompt receives only the relevant, budgeted slice.

Related MCP server: alaya

Features

  • Local-first, zero-dependency core — one SQLite file (FTS5), no server required. pip install and go.

  • Teams & projects, first-class — teams are sets of node members; a project's members are a subset of its team. team:<id> memory reaches the whole team, project:<id> memory only that project — a hard ACL, managed in the console/CLI/API. Removing a member re-scopes recall instantly; deleting a scope revokes its memory.

  • Federated across nodes, with a real trust model — portable bundles + peer sync converge memories, links, profiles, and the org structure (teams/projects/memberships) with last-writer-wins + tombstones. Per-peer policy (shared/full/team:/project:) is an enforced authorization scope: a peer can only assert membership within its own scope and can only shrink a memory's visibility, never widen it — no cross-scope escalation from a bundle.

  • Revocation that propagates — an independent ACL clock carries a post-hoc share/revoke across the mesh, so revoking access actually retracts it on peers that already synced the memory — without disturbing the decay clock.

  • Requester-aware ACL — every agent has private, agent, team, project, and global memories; visibility is a hard gate enforced before ranking, never a soft score. Candidate indexes return IDs only; content is re-read through the gate.

  • Dynamic context packs — token-budgeted, auditable memory selection per prompt (context_pack_report() explains every include/exclude decision).

  • Truth arbitration — duplicate suppression, contradiction detection (CONFLICT markers), and reserved budget for core memories.

  • Associative recall (resonance) — an authoritative memory_links graph lets related memories surface even when they share no query terms; traversal is ACL-safe (invisible nodes are untraversable).

  • Hebbian reinforcement — memories recalled together grow stronger links (record_recall, or auto_reinforce=True on context packs); unhelpful recalls weaken links and confidence (helpful=False).

  • Per-agent recall profiles — different agent personas weight memory types differently (an engineer leans on procedure, a companion on preference); profiles persist in the database and re-weight ranking only, never bypassing ACL.

  • Memory lifecycle — exponential/linear decay, pinning, hard expiry, and a write-side consolidate() pass that merges duplicates and synthesizes strongly co-recalled clusters into concept memories.

  • Optional sidecars — semantic vector candidates (turbovec), MCP server, and a FastAPI Web UI, all behind extras; every candidate rejoins SQLite and passes hard gates before use.

How it compares

Most agent-memory systems optimize for LLM-driven extraction at hosted scale. AgentMemoryOS optimizes for a different point: local-first, team-scoped, and federated — memory you run yourself, shared across a fleet under a hard ACL. This is a positioning comparison (architecture, not a benchmark); verify each row against the projects' current docs.

AgentMemoryOS

Mem0

Zep / Graphiti

Run it

One SQLite file, pip install

Self-host (configure LLM + vector DB) or hosted

Zep Cloud, or self-host Graphiti on Neo4j/FalkorDB

Core needs an LLM

No (FTS5 + optional local vectors)

Yes (LLM extraction, e.g. gpt-5-mini)

Yes (LLM builds the temporal graph)

External services

None required

LLM API + vector store

Graph DB + LLM + embeddings (3+ systems to self-host)

Scope / ACL model

Private / agent / team / project / global — hard gate before ranking

Per user / agent / session id

Per user / session graph

Cross-node federation

Yes — memories and org structure converge; revocation propagates

Centralized store

Centralized (Cloud or your graph DB)

Built-in MCP server

Yes

Via SDK

Via SDK

License / self-host

Apache-2.0, fully OSS

OSS core; graph & advanced tiers paid

Community Edition deprecated; self-host = raw Graphiti

Mem0 and Zep are strong at LLM-based extraction and managed-scale retrieval — things AgentMemoryOS deliberately doesn't do. Reach for AgentMemoryOS when you want a dependency-light memory you own, shared correctly across a team of agents, that keeps working offline and syncs on your terms.

Install

pip install 'agent-memory-os[full]'    # recommended: everything (Web UI, MCP, turbovec)

Or pick pieces: agent-memory-os (core, zero dependencies), [api] (Web UI), [mcp] (MCP server), [semantic] (turbovec vector recall).

Docker: the prebuilt multi-arch image is the complete AgentMemoryOS (web console + MCP server + CLI); the first argument picks the mode:

docker run -p 8000:8000 -v amos-data:/data yamantaka520/agent-memory-os        # web console (default)
docker run -i --rm yamantaka520/agent-memory-os mcp                            # stdio MCP server
docker run --rm -v amos-data:/data yamantaka520/agent-memory-os check          # any CLI command

Or docker compose up -d. Console at http://localhost:8000, memories persist in a volume. See the Docker guide (Docker Hub image + a two-node sync mesh).

Requires Python 3.11+ with SQLite FTS5 (included in standard CPython builds).

After installing, run two commands:

agent-memory doctor          # verifies FTS5, turbovec, and the other extras
                             # (add --install to auto-install anything missing)
agent-memory token create    # protects the Web UI API with a bearer token

The token is stored at <home>/web_token (mode 600); agent-memory-web picks it up automatically and the console prompts for it on first use. Manage it later with agent-memory token show|rotate|disable. Two narrower tiers exist: --readonly (GET-only) and --sync (federation routes only — hand this to a peer instead of the admin token).

Quickstart

Prefer a runnable script? examples/team_memory.py shows three agents sharing one store under a hard ACL in ~40 lines — python examples/team_memory.py.

from agent_memory_os import MemoryClient, RecallProfile

client = MemoryClient(home="~/.agent-memory")

# Write memories with ownership and visibility
client.add("User prefers dark mode.", owner="mizuki", type="preference",
           visibility=[])                      # private to owner
client.add("Deploy target is port 8000.", owner="neo", type="environment",
           visibility=["global"])              # visible to every agent

# Requester-aware search: each agent sees only what it may see
hits = client.search("deploy port", requester_agent_id="neo")

# Token-budgeted context pack for the prompt, with reinforcement loop closed
pack = client.context_pack("deploy port", requester_agent_id="neo",
                           max_tokens=1200, auto_reinforce=True)

# Associate memories; linked memories resonate into future recalls
a = client.add("Staging deploy failed with database lock.", visibility=["global"])
b = client.add("Always snapshot before schema changes.", visibility=["global"])
client.link(a.id, b.id, relation="caused_by", weight=0.8)

# Persist an agent persona: soft ranking bias per memory type
client.save_profile(RecallProfile(agent_id="neo",
                                  type_weights={"procedure": 1.5, "note": 0.7}))

# Periodic hygiene: merge duplicates, synthesize concept memories
client.consolidate()

Architecture

query
  -> candidate providers (FTS5 | vector sidecar | resonance graph | fallback)
  -> merge/dedupe by stable memory_id
  -> rejoin authoritative rows from SQLite
  -> ACL hard gate -> expires_at hard gate
  -> scoring (relevance x importance x confidence x freshness x reinforcement)
  -> per-agent profile re-weighting (soft)
  -> truth arbitration + context budget allocation

Design invariants:

  • The SQLite memories table is the single source of truth; FTS/vector indexes are disposable and rebuildable (rebuild_indexes()).

  • Candidate providers return IDs and scores only — content is always re-read through SQLite behind the ACL and expiry hard gates.

  • Association edges (memory_links) are authoritative data, survive index rebuilds, decay when unused, and never let an invisible memory bridge two visible ones.

See SPEC.md for the full contract.

Storage engines: SQLite + turbovec

AgentMemoryOS uses two storage layers with strictly different authority:

  • SQLite (always on) is the single source of truth: memories, links, profiles, and the FTS5 lexical index all live in one memories.db file.

  • turbovec (installed with [full] / [semantic]) is the semantic vector engine: an in-memory quantized index that recalls memories by meaning rather than keywords. It is deliberately disposable — it returns candidate memory_ids and scores only; every candidate rejoins SQLite and passes the ACL/expiry hard gates before its content can be used, and the index can be dropped and rebuilt at any time without touching the truth store.

Semantic recall works out of the box:

client = MemoryClient(home="~/.agent-memory", semantic="auto")

semantic="auto" wires in a self-syncing turbovec index over a built-in deterministic hashing embedder (no model downloads; typo- and morphology-tolerant lexical vectors). The index rebuilds itself whenever the memories table changes and degrades silently to lexical + resonance recall when the backend isn't installed. For deeper semantics, plug any embedding model into TurbovecSemanticCandidateProvider.from_vectors(...) with your own embed_query. agent-memory doctor confirms the backend is importable.

Memory lifecycle & retention

agent-memory retention               # archive expired + memories idle 4+ half-lives
agent-memory retention --half-lives 0   # expired only
agent-memory check                   # SQLite + FTS + link-graph integrity

Archived memories leave recall entirely but stay restorable (Web UI → Tools → Retention & archive, or POST /api/archive/{id}/restore). Pinned and authority-track memories are never archived by decay. Databases self-migrate through a versioned, forward-only migration table (agent-memory check reports the schema version).

Backup & restore

agent-memory backup ~/backups/memories-$(date +%F).db --keep 14   # rotate, keep 14
agent-memory restore ~/backups/memories-2026-07-11.db --force

Backups use SQLite's online backup API, so they are consistent even while agents are writing. --keep N rotates out older backups in the same name series (and can never delete the live database). Disposable indexes rebuild automatically after a restore.

Upgrades & health. agent-memory update checks PyPI, upgrades, and restarts the running console; --check reports only. Point health checks at GET /healthz (200/503) and a Prometheus scraper at GET /metrics.

Multi-agent projects

One project can mix Claude Code, Codex, OpenClaw, and multiple Hermes profiles against a single store. Register each agent with its teams — in the console's Agents tab or via API — and team members automatically see team:<project> memories with no extra wiring:

curl -X POST localhost:8000/api/agents -H 'content-type: application/json' \
  -d '{"id": "cc-main", "kind": "claude-code", "teams": ["apollo"]}'

Or declare the whole fleet as code — <home>/agents.toml is re-applied every time the store opens (file-listed agents are file-authoritative; manually registered agents are untouched):

[agents.cc-main]
kind = "claude-code"
teams = ["apollo", "shared-infra"]   # multiple teams = multiple projects

[agents.hermes-neo]
kind = "hermes"
teams = ["apollo", "ops"]

Each MCP server declares its identity with AGENT_MEMORY_AGENT_ID, so memories default to that agent as owner and every recall carries its team ACL. Ship one project's shared memory to another host with agent-memory sync export apollo.jsonl --team apollo.

Federation (multi-host sync)

# on the host being joined: mint a sync-scoped token for the peer
agent-memory token create --sync           # prints amos_sync_… (federation routes only)

# one-time, on the joining host
# easiest: pairing (one command on each side — tokens/mesh key exchanged for you)
#   on the existing node:  agent-memory team invite apollo
#   on the joining node:   agent-memory join <code> --url http://that-node:8000
# or wire a peer by hand:
agent-memory peers add https://other-host:8000 --peer-token <their sync token>

# converge with every registered peer (pull + push, deterministic merges)
agent-memory sync auto

Peers are stored per-home; sync auto (or the console's "Sync mesh now") converges bidirectionally with each peer — last-writer-wins on memories and profiles, strongest-wins on links — and unreachable peers fail individually, never fatally. File bundles (sync export/import) cover air-gapped moves. Pair with agent-memory service install and a cron/timer entry for continuous mesh sync.

Encrypt the wire. Give every node the same mesh key and sync bundles are encrypted app-layer (Fernet), so memory content stays confidential even over plain HTTP or through a proxy — the key is a separate secret that never travels on the wire:

agent-memory sync genkey                   # prints amos_sk_… ; needs the [secure-sync] extra
export AGENT_MEMORY_SYNC_KEY=amos_sk_…      # set the SAME value on every node

The sync-scoped token still rides in the Authorization header, so prefer https:// peer URLs (certificate-verified) for non-localhost peers to protect the token too. See SECURITY.md for the exact guarantees.

Agent integrations

Step-by-step guides for wiring AgentMemoryOS into common agents — click a tile:

Hermes Agent gets a native memory-provider plugin (not just MCP): pip install agent-memory-os && agent-memory hermes install, then pick agent-memory-os in hermes memory setup — recall is injected every turn and amos_* tools carry the team/project ACL. No API key, no LLM. See the Hermes guide.

Any MCP-capable agent can use the same pattern: run python -m agent_memory_os.mcp_server as a stdio MCP server pointing at a shared AGENT_MEMORY_HOME.

MCP server

pip install 'agent-memory-os[mcp]'
python -m agent_memory_os.mcp_server

Wire it into Claude Code in one line (set the agent identity so memories are owned correctly):

claude mcp add agent-memory --env AGENT_MEMORY_AGENT_ID=cc-main -- python -m agent_memory_os.mcp_server

Tools (12): memory_add (with a share arg for team/project/global), memory_search, memory_context_pack, memory_orchestrate_context, memory_link, memory_update, memory_share, memory_recall_feedback, memory_consolidate, memory_offload_context, memory_reload_context, memory_snapshot_diff. Set AGENT_MEMORY_AGENT_ID so each agent acts under its own identity — and two agents pointed at the same home instantly share team:/project: memories.

Web UI

pip install 'agent-memory-os[api]'
agent-memory-web --host 127.0.0.1 --port 8000 --home ~/.agent-memory-web

The console speaks English, 繁體中文, 简体中文, 日本語, and 한국어 — auto-detected from the browser, switchable in the header. It ships with a stats dashboard (scope/type/relation breakdowns, 14-day activity, most-recalled memories), search and recency browsing (memory cards with in-place editing, feedback, links, and delete actions), an interactive association-graph view, a context-pack preview with per-memory decisions, and add/link/consolidate tools — all driven by a global "acting as" identity.

Endpoints: health/stats/dashboard/integrity · memories CRUD + browse · search / context-pack / orchestrate · links + graph · recall feedback · share / revoke / audit · consolidate / retention / archive+restore · agents registry · peers + mesh sync · bundle export/import · owner list / reassign / purge · fleet status/trigger (Ed25519-signed cross-node ops). Full table in the User Guide.

Search, browse, graph, recall feedback, and context-pack accept requester_agent_id and enforce the same ACL hard gates as the SDK. Requests without a requester run in unrestricted admin view — bind to localhost only, or require a bearer token on every API route with --token <secret> (or AGENT_MEMORY_WEB_TOKEN).

Note: keep the --home database on a local disk. Network filesystems (NFS/SMB) can fail SQLite FTS5 schema creation with database is locked.

Run as a login service (macOS / Linux / Windows)

agent-memory service install [--host 127.0.0.1] [--port 8000]
agent-memory service status | start | stop | restart | uninstall

install registers the console with the native service manager so it starts automatically at login and restarts on failure — launchd LaunchAgent on macOS, a systemd user unit on Linux, a Task Scheduler logon task on Windows. No admin rights required; the service runs the exact Python environment it was installed from, and logs to <home>/logs/web.log. On Linux, run loginctl enable-linger $USER if it must start at boot without a login. Add --dry-run to preview the actions. CI runs the full test suite on Ubuntu, macOS, and Windows across Python 3.11–3.13.

Development

pip install -e '.[dev]'
pytest

Status

Stable — 1.x. The contracts above are implemented, covered by the test suite (300+ tests across a 3-OS CI matrix, plus a migration upgrade-path job), and audited by repeated fan-out code + security reviews (reports under docs/reviews/). Performance is verified at 10k memories (add 0.17 ms, search <1 ms, context-pack 7.8 ms). The database self-migrates forward; see the CHANGELOG for what each release added.

Documentation

  • User Guide — concepts, full CLI / HTTP API / MCP references, multi-agent and federation walkthroughs, ops checklist

  • Docker guide — docker/docker compose startup, config via env, two-node sync mesh

  • SPEC — contracts and invariants, by milestone

  • Security & Threat model — disclosure policy, trust boundaries, and honest known limitations

  • Embeddings & scale — plug in a real embedding model; behaviour from 10k to 1M memories

  • Importers — migrate from Mem0 / Zep / ChatGPT · Compatibility — the 1.x semver promise

  • Reviews & reports — fan-out code + security reviews (through the 1.x line), the performance/security report, and the validation harness (scripts/validation_run.py)

  • CHANGELOG · Roadmap · Integration guides

License

Apache License 2.0

Available Tools

12 tools
memory_addA

Store a durable memory that will survive across sessions.

    Use this to remember a user preference, project fact, decision, procedure,
    or lesson worth recalling later — not transient chat. Set `share` to make it
    visible to teammates ('team'/'project') instead of just yourself; the default
    is private. Content is de-duplicated softly and becomes searchable immediately.
    Returns the new memory's `id`, `content`, and resolved `visibility`, or an
    `{"error": ...}` object if `share` names a team/project you can't resolve.
ParametersJSON Schema
NameRequiredDescriptionDefault
typeNoKind of memory: 'preference', 'fact', 'procedure', 'environment', 'decision', 'warning', or 'note'.note
ownerNoOwner id the memory belongs to. Defaults to this server's AGENT_MEMORY_AGENT_ID, else 'default'.
scopeNoLifecycle label used for graph coloring and filtering: 'user', 'agent', 'project', 'team', or 'global'. Does NOT set access control (use `share` for that).user
shareNoWho may read this memory (the ACL). 'private' (default, owner only), 'global' (all agents), 'team' or 'team:<id>' (your team — teammates on the same node share it), 'project' or 'project:<id>', or 'agent:<id>'. Use 'team'/'project' to share with collaborators; leave 'private' for personal notes.private
contentYesThe fact to remember, as a self-contained sentence (e.g. 'The user prefers dark mode.'). Write it so it makes sense on its own in a future session.

TDQS

A4.3/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. Discloses soft de-duplication, immediate searchability, and return values (id, content, visibility, or error). Provides behavioral traits beyond basic CRUD.

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?

Well-structured paragraph with front-loaded purpose. Every sentence adds value. Slightly verbose in the share explanation, but overall 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?

Given 5 parameters (1 required), no output schema, the description covers purpose, parameter semantics, and return behavior. Could elaborate on error conditions beyond share resolution, but still complete enough for correct invocation.

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%, so baseline is 3. Description adds meaning to 'content' (self-contained sentence), 'share' (ACL details), and 'type' (kinds of memory). These go beyond schema descriptions, earning an extra point.

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 starts with a clear verb+resource ('Store a durable memory') and enumerates specific use cases (preferences, facts, decisions) that distinguish it from transient chat. Siblings like memory_search or memory_update are clearly different operations.

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?

Describes when to use (durable, persistent info) and contrasts with transient chat. Implicitly excludes use for temporary data. Does not explicitly say when to use alternatives like memory_update, but provides enough context for an agent to decide.

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

memory_consolidateA

Merge duplicate memories and synthesize concept memories (housekeeping).

    A periodic hygiene pass: it collapses exact/near duplicates and combines
    strongly co-recalled clusters into higher-level concept memories, keeping the
    store compact and recall sharp. Safe to run occasionally rather than per-write.
    Returns counts of what was merged and created.
ParametersJSON Schema
NameRequiredDescriptionDefault
ownerNoRestrict consolidation to one owner id. Omit to consolidate across all owners this agent may modify.
scopeNoRestrict consolidation to one scope (e.g. 'project'). Omit for all scopes.

TDQS

A4.2/5.0
Behavior4/5

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

No annotations provided, so description bears full burden. Clearly describes effects: merging duplicates, synthesizing concept memories, returning counts. Indicates non-destructive but modifying. No hidden behaviors mentioned.

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?

Description is concise and front-loaded: the main purpose is in the first line. Each sentence adds value without redundancy.

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 simplicity, the description is fairly complete. It explains the consolidation process, safety, and return values. Could mention that it's safe and returns counts, which it does.

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

Parameters3/5

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

Input schema has 100% coverage with descriptions for both parameters (owner, scope). The tool description does not add extra parameter meaning beyond the schema, so baseline score of 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 the tool's purpose: 'Merge duplicate memories and synthesize concept memories (housekeeping).' It includes a specific verb ('merge', 'synthesize') and resource ('memories'), distinguishing it from sibling tools like memory_add or memory_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?

Provides explicit guidance on when to use: 'Safe to run occasionally rather than per-write.' Explains it is for housekeeping, collapsing duplicates and combining clusters. Does not explicitly state when not to use, but context implies it is for periodic maintenance.

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

memory_context_packA

Build a prompt-ready, token-budgeted block of the most relevant memories.

    Prefer this over `memory_search` when you want text to paste straight into a
    prompt: it selects and formats the highest-value memories within `max_tokens`,
    de-duplicates, and flags contradictions. Access-controlled to this agent's
    identity. Returns a formatted string (empty if nothing relevant is visible).
ParametersJSON Schema
NameRequiredDescriptionDefault
ownerNoOptional filter to a single owner id. Leave unset to include everything this agent may see.
queryYesThe task or question to gather relevant memories for.
max_tokensNoApproximate token budget for the returned block; the most relevant memories are selected to fit.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.9/5.0
Behavior5/5

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

Fully describes behavior without annotations: selects highest-value memories, fits within max_tokens, de-duplicates, flags contradictions, access-controlled, returns formatted string or empty.

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?

Four sentences, front-loaded with purpose, no fluff. Every sentence contributes meaningful information.

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 moderate complexity, output schema presence, and full annotation burden, the description is complete: covers purpose, usage, behavior, and parameter semantics adequately.

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 has 100% coverage, so baseline is 3. Description adds value by explaining that max_tokens is a budget and that selection is based on relevance, but this is mostly repetition of schema descriptions.

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 verb 'Build' and resource 'prompt-ready, token-budgeted block of memories'. Explicitly differentiates from sibling memory_search with a usage preference.

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 when-to-use guidance: 'Prefer this over memory_search when you want text to paste straight into a prompt'. Implicitly indicates when to use alternative.

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

memory_offload_contextA

Park the agent's working context as a restorable snapshot (offload).

    Use before context runs out or when switching tasks, so the work can be reloaded
    later with `memory_reload_context` instead of being lost. Snapshots are rotated
    per session. Returns the new `snapshot_id` and `session_id`.
ParametersJSON Schema
NameRequiredDescriptionDefault
triggerNoWhy the snapshot was taken, e.g. 'manual', 'pre-compaction', 'checkpoint'.manual
session_idYesStable id for the working session this snapshot belongs to (used to reload later).
snapshot_dataYesArbitrary JSON object capturing the working context to park (open files, plan, decisions, TODOs, etc.).

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses that snapshots are rotated per session and that the tool returns snapshot_id and session_id. This adequately describes the behavioral traits without contradictions.

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 four sentences, front-loaded with the main action, and each sentence adds value. No irrelevant information.

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 simple tool with 3 parameters and no output schema, the description covers purpose, usage, rotation, and return. It is complete enough for an AI agent, though it could mention potential failure modes or size limits.

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 baseline is 3. The description does not add additional meaning beyond the schema; it only mentions the return values but not parameter details or constraints.

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 purpose: 'Park the agent's working context as a restorable snapshot (offload).' It uses a specific verb and resource, and distinguishes itself from the sibling tool memory_reload_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?

The description provides explicit guidance on when to use this tool: 'Use before context runs out or when switching tasks.' It also mentions how to reload later with memory_reload_context, offering clear alternatives.

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

memory_orchestrate_contextA

Assemble a rich, budget-aware context block for a task.

    A higher-level alternative to `memory_context_pack`: it splits the budget into
    sections — bedrock constants, proactive warnings and procedures, and relevance
    recall — in one prompt-ready block. With a `session_id`, repeated calls omit
    memories already delivered (bedrock constants always repeat). Access-controlled
    to this agent. Returns `text`, `sections`, `used_tokens`, `max_tokens`, `emphasis`.
ParametersJSON Schema
NameRequiredDescriptionDefault
taskYesThe task you are about to work on; drives which memories are gathered.
max_tokensNoApproximate token budget for the whole assembled block.
session_idNoOptional session id. Pass the same id across calls to skip memories already delivered this session (iterative deepening).

TDQS

A4.4/5.0
Behavior4/5

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

While no annotations are present, the description details key behaviors: it splits budget into sections (bedrock constants, proactive warnings, relevance recall), repeats bedrock constants, supports session-based deduplication, and returns specific fields. It does not mention destructive actions or authentication needs, but these are not critical for a read-like context assembly 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?

The description is concise and well-structured. It starts with a one-sentence summary of the tool's purpose, then provides key details in a bullet-like flow. Every sentence adds meaningful information without redundancy.

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 three parameters and no output schema, the description is complete: it lists the returned fields (text, sections, used_tokens, max_tokens, emphasis) and explains the budget-aware behavior. It could explicitly confirm the tool is non-destructive, but the context-packing nature implies it is read-only. The description compensates well for the lack of an output schema.

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?

All three parameters have descriptions in the schema (100% coverage). The description adds value by explaining the role of 'task' (drives which memories are gathered), the approximate nature of 'max_tokens' budget, and how 'session_id' enables iterative deepening. This goes beyond the schema's basic descriptions.

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 purpose: 'Assemble a rich, budget-aware context block for a task.' It uses specific verbs and identifies the resource. It also distinguishes itself from the sibling 'memory_context_pack' by explaining it is a higher-level alternative that splits the budget into sections.

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 clear context for usage: it compares to 'memory_context_pack' and explains that passing a 'session_id' skips already delivered memories for iterative deepening. However, it does not explicitly state when not to use this tool or specify alternatives among the other siblings.

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

memory_recall_feedbackA

Report whether recalled memories were helpful, to tune future ranking.

    This closes the learning loop: `helpful=True` strengthens the memories and the
    links between them (they will resurface more readily); `helpful=False` weakens
    them and lowers their confidence. Only memories visible to this agent are
    affected — you cannot influence another identity's memories. Returns a summary
    of what was reinforced or weakened.
ParametersJSON Schema
NameRequiredDescriptionDefault
helpfulNoTrue if the recalled memories helped (reinforce them); False if they misled you (weaken them and lower confidence).
memory_idsYesIds of memories that were just recalled together, whose usefulness you are reporting.
create_colinksNoIf true, create weak 'co_recalled' links between the given memories that weren't already linked.

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 full burden. It transparently explains the behavioral effects: strengthening/weakening memories and links, and lowering confidence for negative feedback. It also mentions that a summary is returned, providing insight into the tool's output.

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 and well-structured, with no wasted words. It front-loads the core purpose and follows with necessary behavioral details and limitations in a clear, organized manner.

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 3 parameters and no output schema, the description provides sufficient context: purpose, effects, scope, and return value. It could optionally include an example, but the current level is adequate for correct tool selection and use.

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 of 3. The description adds value by explaining the semantic meaning of each parameter: 'helpful' controls reinforcement vs. weakening, 'memory_ids' specifies which memories are being evaluated, and 'create_colinks' adds co-recalled links. This goes beyond the schema descriptions.

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 purpose: to report whether recalled memories were helpful. It uses a specific verb ('Report') and resource ('recalled memories'), and distinguishes this tool from sibling tools like memory_search or memory_add by explaining its role in the learning loop.

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 clear context on when to use the tool (after recalling memories) and explains the consequences of 'helpful=True/False'. It also notes the limitation that only the agent's own memories are affected, offering guidance on proper usage.

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

memory_reload_contextA

Restore a previously offloaded working-context snapshot (reload).

    The counterpart to `memory_offload_context`: rehydrates the parked context so
    the agent can resume where it left off. Returns the snapshot's stored data, or
    an `{"error": ...}` object if the session/snapshot is not found.
ParametersJSON Schema
NameRequiredDescriptionDefault
session_idYesSession id to restore working context for.
snapshot_idNoSpecific snapshot to reload. Omit to reload the most recent snapshot for the session.

TDQS

A4.1/5.0
Behavior3/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 that the tool returns stored data or an error object if not found, but does not mention any side effects such as whether the snapshot is deleted or modified after reload.

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 with no redundant information. It front-loads the core purpose and follows with relevant details, making it highly efficient.

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 no output schema, the description adequately explains return values (stored data or error). It covers the error case and relates to a sibling, making it complete for a tool with two parameters.

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. The description adds no new semantics beyond what the input schema already provides for 'session_id' and 'snapshot_id'.

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 verb 'restore' and resource 'previously offloaded working-context snapshot'. It distinguishes itself by explicitly naming its counterpart 'memory_offload_context', avoiding confusion among siblings.

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 that it is the counterpart to 'memory_offload_context' and is used to resume where the agent left off. This gives clear context, though it lacks explicit when-not-to-use guidance.

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

memory_shareA

Change who can read an existing memory (share it, or make it private again).

    Use this to promote a note you already stored to your team/project so
    collaborators can recall it, or to lock it back down. Only the memory's OWNER
    may change its visibility. The change propagates over sync — sharing reaches
    teammates, and making it private retracts it. Returns the memory's `id` and new
    `visibility`, or an `{"error": ...}` object if it doesn't exist, isn't yours, or
    `share` is invalid.
ParametersJSON Schema
NameRequiredDescriptionDefault
shareNoNew audience: 'private' (owner only), 'global' (all agents), 'team' or 'team:<id>', 'project' or 'project:<id>', or 'agent:<id>'.private
memory_idYesId of the memory whose visibility you want to change.

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, description fully discloses ownership requirement, propagation over sync, effects of sharing/retracting, and error conditions (not found, not owner, invalid share). This is thorough for a mutation tool.

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

Conciseness4/5

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

Description is front-loaded with purpose, then details. A few extra words could be trimmed, but overall efficient and well-structured for its length.

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 2 parameters, no output schema, and no annotations, the description covers purpose, usage, parameters, behavioral nuances, and error responses. Nothing essential is missing.

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% and description adds value by explaining the 'share' parameter audience options with examples and clarifying the memory_id parameter's purpose. Slight redundancy with schema but beneficial context.

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 clear verb 'Change who can read' and resource 'existing memory', distinguishing it from siblings like memory_add or memory_update. It also gives synonyms 'share it, or make it private again' for added clarity.

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 states when to use: 'promote a note ... to your team/project' or 'lock it back down'. Also covers ownership prerequisite. Lacks explicit when-not-to-use or alternatives, but context is sufficiently clear.

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

memory_snapshot_diffA

Show what changed between a session's two most recent context snapshots.

    Answers "what did I change since I last parked this work?" — returns the
    top-level keys added, removed, and changed between the previous and latest
    snapshot, or an `{"error": ...}` object if the session has fewer than two.
ParametersJSON Schema
NameRequiredDescriptionDefault
session_idYesSession id whose two most recent snapshots should be compared.

TDQS

A4.2/5.0
Behavior4/5

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

No annotations provided, so description bears full burden. It clearly states the tool returns a diff or an error object, implying read-only behavior. It does not mention authentication or side effects, but for a read-only tool the description 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?

Description is concise: one-line summary followed by a short paragraph with additional context. Every sentence adds value. Front-loaded with the primary purpose.

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 no output schema, the description adequately explains return value (top-level keys added/removed/changed). It covers purpose, usage scenario, and error condition. Could mention that snapshots are per session, but is inferred.

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 description. The tool description adds contextual usage (the 'parked work' question) but no additional semantic detail beyond the schema. Baseline score of 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?

Description uses specific verb 'Show' and specifies resource 'what changed between a session's two most recent context snapshots'. It clearly distinguishes from sibling tools (e.g., memory_search, memory_update) by focusing on introspection of snapshot diffs. Return structure (added/removed/changed keys) is explicitly stated.

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?

Description provides a user-facing question ('What did I change since I last parked this work?') indicating when to use. It also mentions error condition (fewer than two snapshots). However, it does not explicitly list alternatives or cases where this tool should not be used.

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

memory_updateA

Update fields of an existing memory in place (keeps the same id).

    Use it to correct content, re-weight importance/confidence, or pin a memory so
    it is never forgotten. Only the fields you pass are changed. Returns the updated
    `id`, `content`, and `updated_at`, or an `{"error": ...}` object if the id does
    not exist.
ParametersJSON Schema
NameRequiredDescriptionDefault
pinnedNoPin (true) to exempt the memory from decay/forgetting, or unpin (false). Omit to leave unchanged.
contentNoNew content text. Omit to leave unchanged.
memory_idYesId of the memory to modify.
confidenceNoNew confidence 0.0-1.0 (how sure the fact is true). Omit to leave unchanged.
importanceNoNew importance 0.0-1.0 (boosts ranking). Omit to leave unchanged.

TDQS

A4.5/5.0
Behavior5/5

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

No annotations provided, so the description bears full burden. It discloses that only passed fields are changed, the return value includes id/content/updated_at or error for missing id, and pinning exempts from decay. This is 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?

The description is concise with three well-structured sentences, front-loading the main purpose. No unnecessary text.

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?

Despite no output schema, the description explains return value and error case. It covers pinning behavior. Combined with full schema, the information is complete for an update 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% with each parameter well-described. The description adds minimal extra meaning beyond listing use cases, so 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 it updates an existing memory in place, with specific use cases (correct content, re-weight importance/confidence, pin). It distinguishes from siblings like memory_add by noting 'keeps the same id'.

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 implies usage scenarios (correction, re-weighting, pinning) but does not explicitly compare to siblings or state when not to use. However, the context is sufficient for an agent to decide.

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. 2 tool updatesv1.0.6
    • Changedmemory_add2 fields changed
      • changedInput schema / properties / scope / description
        Previous value: -"Lifecycle label used for graph coloring and filtering: 'user', 'agent', 'project', 'team', or 'global'. Does NOT set access control (use visibility for that)."New value: +"Lifecycle label used for graph coloring and filtering: 'user', 'agent', 'project', 'team', or 'global'. Does NOT set access control (use `share` for that)."
      • addedInput schema / properties / share
        Added value: +{
+  "default": "private",
+  "description": "Who may read this memory (the ACL). 'private' (default, owner only), 'global' (all agents), 'team' or 'team:<id>' (your team — teammates on the same node share it), 'project' or 'project:<id>', or 'agent:<id>'. Use 'team'/'project' to share with collaborators; leave 'private' for personal notes.",
+  "title": "Share",
+  "type": "string"
+}
    • Addedmemory_share
  2. 11 tool updatesv0.1.1
    • Changedmemory_add4 fields changed
      • addedInput schema / properties / content / description
        Added value: +"The fact to remember, as a self-contained sentence (e.g. 'The user prefers dark mode.'). Write it so it makes sense on its own in a future session."
      • addedInput schema / properties / owner / description
        Added value: +"Owner id the memory belongs to. Defaults to this server's AGENT_MEMORY_AGENT_ID, else 'default'."
      • addedInput schema / properties / scope / description
        Added value: +"Lifecycle label used for graph coloring and filtering: 'user', 'agent', 'project', 'team', or 'global'. Does NOT set access control (use visibility for that)."
      • addedInput schema / properties / type / description
        Added value: +"Kind of memory: 'preference', 'fact', 'procedure', 'environment', 'decision', 'warning', or 'note'."
    • Changedmemory_consolidate2 fields changed
      • addedInput schema / properties / owner / description
        Added value: +"Restrict consolidation to one owner id. Omit to consolidate across all owners this agent may modify."
      • addedInput schema / properties / scope / description
        Added value: +"Restrict consolidation to one scope (e.g. 'project'). Omit for all scopes."
    • Changedmemory_context_pack5 fields changed
      • addedInput schema / properties / max_tokens / description
        Added value: +"Approximate token budget for the returned block; the most relevant memories are selected to fit."
      • addedInput schema / properties / max_tokens / maximum
        Added value: +32000
      • addedInput schema / properties / max_tokens / minimum
        Added value: +128
      • addedInput schema / properties / owner / description
        Added value: +"Optional filter to a single owner id. Leave unset to include everything this agent may see."
      • addedInput schema / properties / query / description
        Added value: +"The task or question to gather relevant memories for."
    • Changedmemory_link6 fields changed
      • addedInput schema / properties / dst_id / description
        Added value: +"Id of the destination memory to associate with the source."
      • addedInput schema / properties / relation / description
        Added value: +"Relationship type: 'related_to', 'supersedes', 'caused_by', 'derived_from', or 'co_recalled'."
      • addedInput schema / properties / src_id / description
        Added value: +"Id of the source memory (from memory_add/memory_search)."
      • addedInput schema / properties / weight / description
        Added value: +"Association strength from 0.0 to 1.0; higher means the memories surface together more strongly."
      • addedInput schema / properties / weight / maximum
        Added value: +1
      • addedInput schema / properties / weight / minimum
        Added value: +0
    • Changedmemory_offload_context3 fields changed
      • addedInput schema / properties / session_id / description
        Added value: +"Stable id for the working session this snapshot belongs to (used to reload later)."
      • addedInput schema / properties / snapshot_data / description
        Added value: +"Arbitrary JSON object capturing the working context to park (open files, plan, decisions, TODOs, etc.)."
      • addedInput schema / properties / trigger / description
        Added value: +"Why the snapshot was taken, e.g. 'manual', 'pre-compaction', 'checkpoint'."
    • Changedmemory_orchestrate_context5 fields changed
      • addedInput schema / properties / max_tokens / description
        Added value: +"Approximate token budget for the whole assembled block."
      • addedInput schema / properties / max_tokens / maximum
        Added value: +32000
      • addedInput schema / properties / max_tokens / minimum
        Added value: +128
      • addedInput schema / properties / session_id / description
        Added value: +"Optional session id. Pass the same id across calls to skip memories already delivered this session (iterative deepening)."
      • addedInput schema / properties / task / description
        Added value: +"The task you are about to work on; drives which memories are gathered."
    • Changedmemory_recall_feedback3 fields changed
      • addedInput schema / properties / create_colinks / description
        Added value: +"If true, create weak 'co_recalled' links between the given memories that weren't already linked."
      • addedInput schema / properties / helpful / description
        Added value: +"True if the recalled memories helped (reinforce them); False if they misled you (weaken them and lower confidence)."
      • addedInput schema / properties / memory_ids / description
        Added value: +"Ids of memories that were just recalled together, whose usefulness you are reporting."
    • Changedmemory_reload_context2 fields changed
      • addedInput schema / properties / session_id / description
        Added value: +"Session id to restore working context for."
      • addedInput schema / properties / snapshot_id / description
        Added value: +"Specific snapshot to reload. Omit to reload the most recent snapshot for the session."
    • Changedmemory_search5 fields changed
      • addedInput schema / properties / limit / description
        Added value: +"Maximum number of results to return, best-first."
      • addedInput schema / properties / limit / maximum
        Added value: +100
      • addedInput schema / properties / limit / minimum
        Added value: +1
      • addedInput schema / properties / owner / description
        Added value: +"Optional filter to a single owner id. Leave unset to search everything this agent may see."
      • addedInput schema / properties / query / description
        Added value: +"Natural-language search query. Matches by keyword AND by association (linked memories surface even without shared words)."
    • Changedmemory_snapshot_diff1 field changed
      • addedInput schema / properties / session_id / description
        Added value: +"Session id whose two most recent snapshots should be compared."
    • Changedmemory_update7 fields changed
      • changedInput schema / properties / confidence / anyOf
        Previous value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maximum": 1,
+    "minimum": 0,
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedInput schema / properties / confidence / description
        Added value: +"New confidence 0.0-1.0 (how sure the fact is true). Omit to leave unchanged."
      • addedInput schema / properties / content / description
        Added value: +"New content text. Omit to leave unchanged."
      • changedInput schema / properties / importance / anyOf
        Previous value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "maximum": 1,
+    "minimum": 0,
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]
      • addedInput schema / properties / importance / description
        Added value: +"New importance 0.0-1.0 (boosts ranking). Omit to leave unchanged."
      • addedInput schema / properties / memory_id / description
        Added value: +"Id of the memory to modify."
      • addedInput schema / properties / pinned / description
        Added value: +"Pin (true) to exempt the memory from decay/forgetting, or unpin (false). Omit to leave unchanged."
  3. 11 tool updates
    • First observedmemory_add
    • First observedmemory_consolidate
    • First observedmemory_context_pack
    • First observedmemory_link
    • First observedmemory_offload_context
    • First observedmemory_orchestrate_context
    • First observedmemory_recall_feedback
    • First observedmemory_reload_context
    • First observedmemory_search
    • First observedmemory_snapshot_diff
    • First observedmemory_update
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0
Disambiguation5/5

Each tool serves a distinct memory operation: adding, updating, searching, linking, consolidating, context packing, orchestration, feedback, offloading/reloading, and diffing. There is no functional overlap.

Naming Consistency5/5

All tool names follow a consistent `memory_<verb>_<optional_noun>` pattern in snake_case, making them predictable and easy to understand.

Tool Count5/5

With 11 tools, the set is well-scoped for a memory management server, covering creation, retrieval, update, linking, consolidation, context assembly, and snapshot management without being bloated.

Completeness4/5

The tool surface is comprehensive for agent memory operations, but lacks an explicit delete or clear expiration mechanism, which may be a minor gap depending on requirements.

Maintenance

ActivityActive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • alaya

    SecurityRonin
    A
    license
    Not graded
    quality
    C
    maintenance
    A local memory engine for AI agents. Stores conversation episodes, consolidates knowledge through a neuroscience-inspired lifecycle, and builds a personal knowledge graph — all in a local SQLite database.
    14
    MIT
  • mem0-mcp by tensakulabs

    mem0-mcpofficial

    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.
    6
    4
    MIT

  • SharedBrain

    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.
    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/yamantaka520/Agent-Memory-OS'

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