Skip to main content
Glama
ethos-zero

Mneme Memory MCP

by ethos-zero
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Mneme Memory MCP

The memory that grows with every agent.

Mneme Memory MCP

Mneme is a local-first shared memory and agent-mesh layer for Claude, Codex, Hermes, and any MCP-aware agent you trust.

It gives your agents one durable mind and one shared bridge: preferences, project state, tool setup, decisions, long-running context, and peer-agent delegation that survive new chats and new clients.

Claude Code  <---->  mneme-memory-mcp  <---->  Codex
       \                 |   |                  /
        \                |   |                 /
         \-------->  ~/.hermes memory  <------/
                         |
                    Hermes Agent

What It Does

  • Remembers across chats, agents, and clients

  • Installs always-on memory instructions for fresh Claude and Codex chats

  • Auto-injects Markdown memory into new Claude Code sessions

  • Archives local Claude and Codex conversation snippets as capped episodic memory, then distills compact searchable summaries

  • Shares one Hermes-compatible memory home

  • Stores human-readable memory in Markdown

  • Stores searchable facts in SQLite FTS

  • Exposes memory through MCP tools

  • Installs beside Hermes Agent, and can bootstrap Hermes when it is missing

  • Wires Claude and Codex together through MCP and the OpenAI Claude-to-Codex plugin

  • Installs Ponytail for smaller, safer code-generation behavior in both clients

Related MCP server: auxly-memory-cli

Why Mneme?

Mneme means memory. Hermes carries messages; Mneme keeps them from disappearing. This project is the bridge that lets every connected agent return to the same remembered context.

Platform support

The Mneme package (MCP server, memory tools, and CLIs) is pure Python and runs on macOS, Linux, and Windows.

  • macOS / Linux: use the one-command installer below (./scripts/install.sh is bash).

  • Windows: use the native PowerShell installer below (.\scripts\install.ps1).

Hermes auto-install uses the official bash installer on macOS/Linux. On Windows, Mneme looks for an existing Hermes Agent install and continues with Mneme MCP memory when Hermes is not present.

Quick Install

macOS / Linux:

git clone https://github.com/ethos-zero/mneme-memory-mcp.git
cd mneme-memory-mcp
./scripts/install.sh

Windows PowerShell:

git clone https://github.com/ethos-zero/mneme-memory-mcp.git
cd mneme-memory-mcp
powershell -ExecutionPolicy Bypass -File .\scripts\install.ps1

Both installers support these memory profiles:

Profile

Best For

Memory Home

Global Claude/Codex Instructions

global

A personal machine where every fresh Claude/Codex chat should share memory

~/.hermes by default

Yes

project

A cloned repo, shared setup, or isolated workspace

.env value, defaulting under the platform Mneme data directory

No

server

Manual wiring or cautious evaluation

Your existing env/defaults

No

Both installers ask which profile you want when run interactively. Non-interactive installs, including installs run by an AI agent or automation, stop until the user chooses global, project, or server. After the user answers, rerun with both --profile/-Profile and --profile-confirmed/-ProfileConfirmed, or set MNEME_SETUP_PROFILE plus MNEME_PROFILE_CONFIRMED=1.

The installer:

  • checks for hermes

  • installs Hermes Agent with the official Hermes installer if missing on macOS/Linux

  • creates a managed Python venv under the platform data directory

  • installs mneme-memory-mcp into that managed venv

  • creates the configured memory home and memories directory

  • for the global profile, installs always-on Mneme instructions into global Claude and Codex guidance files

  • for the global profile, configures a Claude Code SessionStart hook that injects the shared Markdown memory into fresh sessions

  • for the global profile, configures a Claude Code UserPromptSubmit hook that adds shared memory context before every future prompt

  • for the global profile, configures Claude and Codex capture hooks that archive recent local conversation snippets and distill compact searchable summaries

  • configures Mneme as an MCP server in Codex and Claude Code when those CLIs are present, and writes Claude user-scope MCP config directly when the Claude CLI is unavailable

  • installs openai/codex-plugin-cc into Claude Code for Claude -> Codex delegation

  • installs DietrichGebert/ponytail into Codex and Claude Code for minimal, safer implementation behavior

  • prints manual fallback config

Ponytail is part of the default client-wiring path for global and project profiles when the relevant CLIs are available and runnable. It is skipped only for server, --no-agent-plugins/-NoAgentPlugins, or --memory-only/-MemoryOnly.

Preselect a profile after the user has chosen it:

./scripts/install.sh --profile global --profile-confirmed
./scripts/install.sh --profile project --profile-confirmed
./scripts/install.sh --profile server --profile-confirmed

Windows:

powershell -ExecutionPolicy Bypass -File .\scripts\install.ps1 -Profile global -ProfileConfirmed
powershell -ExecutionPolicy Bypass -File .\scripts\install.ps1 -Profile project -ProfileConfirmed
powershell -ExecutionPolicy Bypass -File .\scripts\install.ps1 -Profile server -ProfileConfirmed

If a profile is supplied without the confirmation flag, an interactive shell asks you to type the profile name before it proceeds; a non-interactive shell exits so an agent can ask the user first.

To skip Hermes installation:

./scripts/install.sh --profile global --profile-confirmed --no-hermes-install
powershell -ExecutionPolicy Bypass -File .\scripts\install.ps1 -Profile global -ProfileConfirmed -NoHermesInstall

For memory-only setup without client/plugin changes:

./scripts/install.sh --profile global --profile-confirmed --memory-only
powershell -ExecutionPolicy Bypass -File .\scripts\install.ps1 -Profile global -ProfileConfirmed -MemoryOnly

To keep MCP/plugin setup but skip global memory instructions:

./scripts/install.sh --profile global --profile-confirmed --no-continuity
powershell -ExecutionPolicy Bypass -File .\scripts\install.ps1 -Profile global -ProfileConfirmed -NoContinuity

For a project/env-scoped setup using a specific env file:

./scripts/install.sh --profile project --profile-confirmed --env-file /path/to/.env
powershell -ExecutionPolicy Bypass -File .\scripts\install.ps1 -Profile project -ProfileConfirmed -EnvFile C:\path\to\.env

You can start from .env.example.

If that file has no MNEME_HOME or HERMES_HOME, Mneme adds:

MNEME_HOME=/Users/YOU/.local/share/mneme-memory-mcp/projects/mneme-memory-mcp

Check the setup:

~/.local/share/mneme-memory-mcp/venv/bin/mneme-memory-doctor

Windows:

& "$env:LOCALAPPDATA\mneme-memory-mcp\venv\Scripts\python.exe" -m mneme_memory_mcp.doctor

Install Paths

The installer does not create runtime folders on your Desktop. If you clone the repo on your Desktop, the visible Desktop item is just the cloned repo folder.

Default installer paths:

Item

macOS / Linux

Windows

Managed install directory

~/.local/share/mneme-memory-mcp

%LOCALAPPDATA%\mneme-memory-mcp

Python virtualenv

~/.local/share/mneme-memory-mcp/venv

%LOCALAPPDATA%\mneme-memory-mcp\venv

Global memory profile

~/.hermes

%USERPROFILE%\.hermes unless MNEME_HOME/HERMES_HOME is set

Project memory profile

~/.local/share/mneme-memory-mcp/projects/<repo-name>

%LOCALAPPDATA%\mneme-memory-mcp\projects\<repo-name>

Project env file

<repo>/.env unless --env-file is passed

<repo>\.env unless -EnvFile is passed

Codex global instructions

~/.codex/AGENTS.md

%USERPROFILE%\.codex\AGENTS.md

Codex capture notify wrapper

~/.codex/mneme-memory-notify.sh

%USERPROFILE%\.codex\mneme-memory-notify.cmd

Claude global instructions

~/.claude/CLAUDE.md

%USERPROFILE%\.claude\CLAUDE.md

Claude memory hook

~/.claude/hooks/mneme-memory-sessionstart.sh

%USERPROFILE%\.claude\hooks\mneme-memory-sessionstart.cmd

Claude capture hook

~/.claude/hooks/mneme-memory-capture.sh

%USERPROFILE%\.claude\hooks\mneme-memory-capture.cmd

The installer prints the exact install dir, venv dir, memory home, and env file paths it selected.

Override the managed install paths when needed:

./scripts/install.sh --profile global --profile-confirmed --install-dir /path/to/mneme-runtime
./scripts/install.sh --profile global --profile-confirmed --venv-dir /path/to/mneme-venv
powershell -ExecutionPolicy Bypass -File .\scripts\install.ps1 -Profile global -ProfileConfirmed -InstallDir C:\path\to\mneme-runtime
powershell -ExecutionPolicy Bypass -File .\scripts\install.ps1 -Profile global -ProfileConfirmed -VenvDir C:\path\to\mneme-venv

The default installer performs a normal package install, so the runtime does not depend on keeping the repo checkout on your Desktop. Contributors can use editable mode:

./scripts/install.sh --profile global --profile-confirmed --editable
powershell -ExecutionPolicy Bypass -File .\scripts\install.ps1 -Profile global -ProfileConfirmed -Editable

Agent Mesh

Mneme agent bridge

Mneme makes Claude and Codex meet in the same memory field.

  • Claude -> Codex: installed through OpenAI's codex-plugin-cc Claude Code plugin.

  • Codex -> Claude: exposed through Mneme's delegate_to_claude MCP tool.

  • Shared memory: both clients use the same Mneme MCP server pointed at the same Hermes-compatible memory home.

  • Always-on continuity: global Claude/Codex instructions, Claude startup and per-prompt memory injection, and local capture hooks make chats consult shared memory and keep adding searchable context as work happens.

  • Efficient implementation mode: Ponytail is installed for both clients when available.

More details live in docs/agent-mesh.md, docs/always-on-memory.md, and docs/ponytail.md.

Hermes Pairing

Mneme is designed to sit next to Hermes Agent, the agent that grows with you. Hermes provides the agent runtime and desktop experience; Mneme provides a small shared-memory MCP bridge that other agents can use directly.

For the full setup, install both:

  • Hermes Agent for the local agent environment

  • Mneme Memory MCP for shared memory across Codex, Claude Code, Hermes, and other MCP clients

More details live in docs/hermes.md.

Memory Store

Mneme stores memory in three local forms:

  • Generated Markdown views for always-on human-readable working context:

    • ~/.hermes/memories/USER.md

    • ~/.hermes/memories/MEMORY.md

  • SQLite typed fact/event store for searchable recall, supersession, handoffs, and episodic archives:

    • ~/.hermes/memory_store.db

USER.md and MEMORY.md are compact generated views. The database is the source of truth: semantic facts, project facts, procedural runbooks, resource pointers, structured handoffs, and a capped episodic archive live there. Automatic conversation captures write raw turns to episodic_entries, not the main fact table. Mneme then writes one session summary plus a few high-value distilled facts, so always-loaded context does not grow with every transcript turn.

Upgrading an older 0.6.x store quarantines legacy category='conversation' raw transcript rows into episodic_entries and removes them from searchable facts. The migration is idempotent and rebuilds FTS after quarantine so stale transcript text cannot remain searchable.

Facts can carry a stable key and optional version. Mneme parses numeric/date-like version strings, marks older facts superseded, and memory_current / mneme-memory current returns the deterministic current value.

Retrieval is scope-gated. Project reads see global + project; global, handoff, and agent-private scopes are isolated unless explicitly requested. Search uses the local FTS5 lexical path plus a LIKE fallback, merges/dedupes results, and ranks current in-scope facts by trust and freshness. Optional semantic/vector and graph indexes are intentionally deferred behind a future optional path, not required dependencies.

It is designed to sit next to Hermes, but the MCP memory server does not require Hermes Agent to be running.

Tools

The MCP server exposes:

  • memory_summary - read the current Markdown memory summary

  • memory_search - search the SQLite fact store with scope visibility

  • memory_list - list recent facts with scope visibility

  • memory_add - add a durable memory

  • memory_update - update a fact by id

  • memory_remove - remove a fact by id

  • memory_current - resolve the current fact for a supersession key

  • memory_consolidate - regenerate compact USER.md and MEMORY.md views

  • memory_handoff_write - write a structured handoff

  • memory_handoff_latest - fetch the latest handoff for a scope

  • agent_bridge_status - check local Claude, Codex, and Node readiness

  • delegate_to_claude - ask Claude Code to handle a one-shot task with Mneme memory injected

  • delegate_to_codex - ask Codex to handle a one-shot task with Mneme memory injected

Mneme also installs these local CLI commands:

  • mneme-memory - read, search, list, add, consolidate, resolve current facts, and manage handoffs without an MCP client

  • mneme-memory-capture - archive local Claude/Codex conversation transcripts and distill compact searchable summaries

  • mneme-memory-continuity - install or inspect always-on Claude/Codex memory continuity

  • mneme-memory-env-mcp - run the MCP server after loading memory settings from a .env file

Manual Install

macOS / Linux:

git clone https://github.com/ethos-zero/mneme-memory-mcp.git
cd mneme-memory-mcp
python3 -m venv .venv
.venv/bin/pip install -e .

Windows:

git clone https://github.com/ethos-zero/mneme-memory-mcp.git
cd mneme-memory-mcp
python -m venv .venv
.\.venv\Scripts\python.exe -m pip install -e .

Your server command will be:

/absolute/path/to/mneme-memory-mcp/.venv/bin/mneme-memory-mcp

On Windows:

C:\absolute\path\to\mneme-memory-mcp\.venv\Scripts\python.exe -m mneme_memory_mcp

Configure Codex

Add this to ~/.codex/config.toml:

[mcp_servers.mneme_memory]
command = "/absolute/path/to/mneme-memory-mcp/.venv/bin/mneme-memory-mcp"
args = []
startup_timeout_sec = 120

[mcp_servers.mneme_memory.env]
HERMES_HOME = "/Users/YOU/.hermes"

On Windows, use TOML literal strings so backslashes are not interpreted as escapes:

[mcp_servers.mneme_memory]
command = 'C:\absolute\path\to\mneme-memory-mcp\.venv\Scripts\python.exe'
args = ['-m', 'mneme_memory_mcp']
startup_timeout_sec = 120

[mcp_servers.mneme_memory.env]
HERMES_HOME = 'C:\Users\YOU\.hermes'

Restart Codex or open a fresh session so it reloads MCP servers.

Example config files live in examples/codex-config.toml and examples/codex-config-windows.toml.

To also expose Hermes Agent itself to Codex, add a Hermes MCP server using the hermes command installed by Hermes Agent:

[mcp_servers.hermes]
command = "hermes"
args = ["mcp", "serve", "--accept-hooks"]
startup_timeout_sec = 120

Configure Claude Code

Add this to ~/.claude.json:

{
  "mcpServers": {
    "mneme-memory": {
      "type": "stdio",
      "command": "/absolute/path/to/mneme-memory-mcp/.venv/bin/mneme-memory-mcp",
      "args": [],
      "env": {
        "HERMES_HOME": "/Users/YOU/.hermes"
      }
    }
  }
}

On Windows:

{
  "mcpServers": {
    "mneme-memory": {
      "type": "stdio",
      "command": "C:\\absolute\\path\\to\\mneme-memory-mcp\\.venv\\Scripts\\python.exe",
      "args": ["-m", "mneme_memory_mcp"],
      "env": {
        "HERMES_HOME": "C:\\Users\\YOU\\.hermes"
      }
    }
  }
}

If you already have other mcpServers, merge the mneme-memory entry into the existing object.

Example config files live in examples/claude.json and examples/claude-windows.json.

Always-On Client Memory

Always-on client memory is the global profile. It is ideal for one trusted personal machine, because every configured local Claude and Codex session is instructed to start from the same memory layer.

The installer writes managed instruction blocks to:

  • ~/.codex/AGENTS.md

  • ~/.claude/CLAUDE.md

It also installs this Claude Code hook:

~/.claude/hooks/mneme-memory-sessionstart.sh

On Windows this hook is:

%USERPROFILE%\.claude\hooks\mneme-memory-sessionstart.cmd

and merges it into ~/.claude/settings.json under SessionStart.

The MCP server is still the source of truth for search and writes; the global instructions plus Claude startup and per-prompt hooks make high-signal memory visible in fresh chats and before future prompts in active Claude Code sessions.

Read the full behavior in docs/always-on-memory.md.

For repo-scoped memory, choose the project profile when prompted, or use --profile project --profile-confirmed after the user has chosen it. That profile configures MCP clients through mneme-memory-env-mcp, which reads MNEME_HOME or HERMES_HOME from .env, and it does not install global Claude/Codex memory instructions.

Environment Variables

Defaults are chosen for Hermes compatibility:

Variable

Default

Purpose

MNEME_HOME

unset

Primary Mneme home override

HERMES_HOME

~/.hermes

Hermes-compatible memory home

MNEME_MEMORY_DIR

$HOME/memories under resolved home

Markdown memory directory

MNEME_DB_PATH

$HOME/memory_store.db under resolved home

SQLite fact store path

Priority for home is:

  1. MNEME_HOME

  2. HERMES_HOME

  3. ~/.hermes

Local Smoke Test

python -m unittest discover -s tests -v

To test through an MCP client, use any MCP-compatible inspector/client and run:

mneme-memory-mcp

Privacy

This server is local-first. It does not send memory anywhere by itself. Any agent you connect to it can read or write the configured local memory, so only connect agents you trust.

The delegate_to_claude and delegate_to_codex tools run the other CLI on your machine non-interactively. delegate_to_codex uses Codex's workspace-write sandbox with approvals disabled (and can be set to danger-full-access), so it can change files in the working directory on its own. Treat them like any autonomous agent and enable them only for directories and tasks you trust.

Available Tools

6 tools
memory_addA

Add a durable fact to shared memory.

Use target='user' for identity, preferences, and working style. Use target='memory' for projects, tools, paths, decisions, and setup notes.

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYes
targetNomemory
categoryNogeneral
tagsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior3/5

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

No annotations are provided, so the description must convey behavioral traits. It indicates the operation creates a durable fact (persistent storage) and gives context for targets, but lacks details on potential side effects, authorization needs, or limitations.

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: the first states the tool's purpose, the second provides clear usage guidance for the key parameter. No wasted words.

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

Completeness2/5

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

While the output schema (unseen) may define return values, the description fails to explain three of four parameters. Given the tool's 4 parameters and no schema descriptions, the description is incomplete for agent understanding.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. Only the 'target' parameter receives explanation; 'content', 'category', and 'tags' are not described. This leaves the agent uncertain about the use of the other three 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 'Add a durable fact to shared memory,' providing a specific verb and resource. It implicitly distinguishes from sibling tools (list, remove, search, summary, update) which involve 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?

The description provides explicit guidance for the 'target' parameter: use 'user' for personal data and 'memory' for other facts. However, it does not explicitly state when to use this tool instead of alternatives like memory_update.

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

memory_listB

List recent facts from the shared memory fact store.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description must disclose behavior. It mentions 'recent' but does not define recency, ordering, or whether all facts are returned. The output schema exists but is not referenced.

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 sentence with no extraneous words. It is highly concise and 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 simple tool (1 optional param, output schema present), the description adequately states purpose but lacks details like what 'recent' means, default behavior, or how results are ordered. It is minimally complete.

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

Parameters2/5

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

Schema description coverage is 0% and the description adds no meaning to the 'limit' parameter beyond its name. For a tool with one parameter, the description should at least clarify its effect, which it does not.

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 lists recent facts from the shared memory fact store, which is a specific verb+resource combination. It is distinct from siblings like memory_add, memory_remove, memory_search, etc.

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

Usage Guidelines3/5

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

The description implies this tool is for viewing recent facts, but it offers no explicit guidance on when to use it vs. memory_search or memory_summary, nor any exclusion criteria.

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

memory_removeA

Remove a fact by id and remove the matching Markdown bullet if present.

ParametersJSON Schema
NameRequiredDescriptionDefault
fact_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior2/5

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

Discloses that the matching Markdown bullet is removed if present, but with no annotations, it omits side effects, authorization, and idempotency details.

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?

Single sentence, front-loaded with the action, and 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?

Adequate for a simple tool with one parameter and output schema, but lacks details on error handling and preconditions.

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?

With one required parameter (fact_id) and 0% schema coverage, the description 'Remove a fact by id' effectively explains the parameter's purpose beyond the schema.

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

Purpose5/5

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

Clearly states it removes a fact by id and removes the matching Markdown bullet, distinguishing it from sibling tools that add, list, search, summarize, or update.

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

Usage Guidelines3/5

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

Implies use when you have a fact_id and want to delete, but provides no explicit guidance on when not to use or alternatives.

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

memory_summaryA

Return the always-on shared memory summary.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/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 identifies the tool as a read operation returning a summary, but does not elaborate on what the summary contains, whether it is a snapshot, or any other behavioral details. The description is minimally adequate.

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 sentence that exactly conveys the tool's purpose with no unnecessary words. It is front-loaded and 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 that the tool has no parameters and an output schema exists (though not shown), the description is largely complete. It could benefit from a brief indication of what the summary includes (e.g., 'total memory count, last updated timestamp'), but the current wording is sufficient for a simple retrieval tool.

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?

The tool has no parameters, and the input schema is already fully documented with 100% coverage. The description does not add parameter semantics because none exist. Baseline of 4 is appropriate given the absence 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 the tool returns a summary of shared memory, distinguishing it from sibling tools like memory_list (which likely lists individual entries) and memory_search (which queries specific items). The verb 'Return' and noun 'summary' are specific and unambiguous.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as memory_list or memory_search. An agent must infer the purpose, but there are no explicit when-to-use or when-not-to-use instructions.

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

memory_updateC

Update a fact by id.

ParametersJSON Schema
NameRequiredDescriptionDefault
fact_idYes
contentNo
categoryNo
tagsNo
trust_scoreNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.4/5.0
Behavior2/5

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

No annotations exist, and the description only states 'Update a fact by id' without disclosing whether the update is partial or full, what happens if the id doesn't exist, or any side effects. The description carries the full burden but provides minimal behavior info.

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

Conciseness3/5

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

The description is very concise, but it sacrifices necessary detail. It is front-loaded but too brief to be helpful on its own.

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

Completeness2/5

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

Given 5 parameters, no schema descriptions, and no annotations, the description is insufficient. It does not explain the output schema or the behavior of partial updates, leaving significant gaps for an AI agent.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not explain any of the 5 parameters (fact_id, content, category, tags, trust_score). The tool name implies update, but no parameter semantics are added.

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

Purpose4/5

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

The description clearly states the verb and resource ('Update a fact by id'), distinguishing it from sibling tools like memory_add (create) and memory_remove (delete). However, it does not specify which fields can be updated, relying on the schema.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., when to update vs. add or remove), no prerequisites or context provided.

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. 6 tool updatesv0.1.0
    • First observedmemory_add
    • First observedmemory_list
    • First observedmemory_remove
    • First observedmemory_search
    • First observedmemory_summary
    • First observedmemory_update
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: add, list, remove, search, summary, update. There is no conceptual overlap; an agent can easily select the correct tool.

Naming Consistency5/5

All tools follow a consistent 'memory_verb' pattern using snake_case. The naming is predictable and aids discoverability.

Tool Count5/5

Six tools is an ideal count for a focused memory server. Each tool addresses a specific need without bloat, covering core CRUD and search operations.

Completeness4/5

The tool surface covers add, read (list, search, summary), update, and delete. Missing a bulk operation (e.g., clear memory) is a minor gap but not critical for typical usage.

Maintenance

ActivitySlowing
ResponsivenessSyncing

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

  • memmd-mcp

    matamong
    A
    license
    B
    quality
    D
    maintenance
    A shared memory layer for AI agents — one memory.md synced across Claude Desktop, Cursor, Claude Code, OpenAI Codex, and any MCP client.
    4
    2
    MIT

  • auxly-memory-cli

    Tzamun-Arabia-IT-Co
    A
    license
    Not graded
    quality
    A
    maintenance
    Local-first, file-based memory layer for AI agents — one shared Markdown vault across Claude, Codex, Gemini, Cursor and any MCP client. Provides read/write memory tools with an audit trail, per-agent trust levels, and Git sync; no cloud and no lock-in.
    2
    MIT

  • server-memory

    MK-986123
    A
    license
    A
    quality
    B
    maintenance
    A local-first MCP server for durable agent memory using SQLite and FTS5, enabling knowledge graph storage, search, and recall for AI agents.
    20
    1
    MIT

  • Caduceus Memory MCP

    ethos-zero
    A
    license
    A
    quality
    C
    maintenance
    A local shared-memory MCP server for Claude, Codex, Hermes, and other MCP-aware agents, providing a durable memory layer with Markdown files and SQLite fact store.
    6
    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/ethos-zero/mneme-memory-mcp'

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