Skip to main content
Glama
deenesjakoruzh
tverney

Agent Memory

by tverney
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

A Filesystem MCP for Agent Memory

mcp-agent-memory MCP server

MCP server that exposes agent-memory-daemon to any MCP-compatible client — Kiro (CLI & IDE), Claude Desktop, Cursor, and others.

The daemon does the thinking (consolidation + extraction); this server is a thin filesystem bridge so agents can read, append, and search memory through the Model Context Protocol.

How it fits together

 ┌──────────────┐     MCP/stdio     ┌────────────────────┐     filesystem      ┌────────────────────────┐
 │ Kiro / Claude│ ◄───────────────► │ mcp-server-memory  │ ◄─────────────────► │ agent-memory-daemon    │
 │   / Cursor   │                   │  (this package)    │   ~/.agent-memory/   │  (runs in background)  │
 └──────────────┘                   └────────────────────┘                     └────────────────────────┘

  • The MCP server reads/writes files under ~/.agent-memory/

  • The daemon watches the same directory and runs consolidation + extraction passes

  • They never talk to each other directly — the filesystem is the contract

Related MCP server: Recall

Tools exposed

memory_read

Read the agent memory index (MEMORY.md) and optionally specific topic files. Call with no arguments to load only the lightweight index (cheap). Pass topics only when you need the full content of a specific topic file.

Parameter

Type

Required

Description

topics

string[]

No

Topic file names to load in full (e.g., ["preferences", "projects"]). Omit to return the index only.

memory_append_session

Append a session summary to the sessions directory. The daemon will later extract durable memories from it. Call this at the end of meaningful exchanges. Keep summaries focused on durable findings and decisions (target 300–800 tokens), not play-by-play — longer summaries cost more during consolidation.

Parameter

Type

Required

Description

content

string

Yes

Markdown-formatted session summary. Use structured headers and bullets for better extraction; avoid verbose prose.

source

string

No

Origin tag, e.g., "kiro", "claude-desktop"

memory_search

Search memory files for a substring. Use this to recall specific facts without loading everything.

Parameter

Type

Required

Description

query

string

Yes

The substring to search for across all memory files.

Install

npm install -g mcp-agent-memory

Quick start (interactive wizard)

The fastest way to set everything up — memory directory, daemon, client configs, logs, and LaunchAgent — is the setup wizard:

mcp-agent-memory --setup

It asks six questions:

  1. Memory directory — where .agent-memory/ lives (default ~/.agent-memory)

  2. Install the consolidation daemon? — say "no" for MCP-only mode (agents can read/write/search memory, but no automatic consolidation)

  3. LLM backend — bedrock, openai, or kiro (skipped if you declined the daemon)

  4. Consolidation settings — min_hours, min_sessions, extraction interval, max chars

  5. Run mode — standalone (start manually) or launchagent (auto-start at login, macOS only)

  6. Logs directory + TTL — where to put logs, and how many days to keep them (0 = forever)

  7. Client registration — auto-register the MCP server in Kiro, Claude Desktop, and/or Cursor configs (existing MCP entries are preserved)

When you select the kiro backend, the wizard also copies a lean agent to ~/.kiro/agents/memconsolidate.json that cuts token usage by ~7× (see Kiro backend).

When you select launchagent, the wizard checks that agent-memory-daemon is installed (and offers to npm install -g it if not), then registers and starts the plist.

CLI reference

mcp-agent-memory                       # run as an MCP server (normal mode — clients spawn it)
mcp-agent-memory --setup               # first-time interactive setup
mcp-agent-memory --configure           # re-run most steps; can add/remove the daemon later
mcp-agent-memory --remove              # interactive uninstall (backup memory, clean configs)

# macOS LaunchAgent control:
mcp-agent-memory --daemon status       # is the daemon running?
mcp-agent-memory --daemon start        # load and start
mcp-agent-memory --daemon stop         # unload (keeps the plist)
mcp-agent-memory --daemon restart      # stop + start
mcp-agent-memory --daemon remove       # unload and delete the plist

--remove preserves other entries in client MCP configs — only the memory key is deleted. By default it backs up ~/.agent-memory/ to a timestamped .bak-* directory so you can restore your consolidated memories.

Manual install

If you'd rather skip the wizard, here's how to do it by hand.

Install the daemon (optional)

The MCP server works standalone — it just reads and writes files under ~/.agent-memory/. Memories persist, but they won't be consolidated or extracted from sessions until you add the daemon.

npm install -g agent-memory-daemon

# copy the example config
mkdir -p ~/.agent-memory
cp examples/memconsolidate.toml ~/.agent-memory/memconsolidate.toml

# start the daemon
agent-memory-daemon start ~/.agent-memory/memconsolidate.toml

See examples/memconsolidate.toml for a ready-to-use config that matches the directory layout this MCP server expects.

Run the daemon at login (macOS)

Instead of starting the daemon manually, register it as a LaunchAgent:

./scripts/daemon.sh start          # install plist, load it, start at login
./scripts/daemon.sh status         # check if it's running
./scripts/daemon.sh stop           # unload (keeps the plist)
./scripts/daemon.sh remove         # unload and delete the plist

Pass a custom config path as a second arg: ./scripts/daemon.sh start /path/to/config.toml. Logs land in ~/.agent-memory/logs/daemon.{out,err}.log. remove leaves your config and memory files untouched.

Use Kiro as the LLM backend

If you have Kiro credits, you can run the daemon through kiro-cli instead of paying for Bedrock or OpenAI API calls. This requires agent-memory-daemon ≥ 2.7 (branch feat/kiro-backend) which adds a kiro backend.

[llm_backend]
name = "kiro"
# optional overrides:
# binary = "/custom/path/to/kiro-cli"
# agent = "memconsolidate"          # set to "" to use Kiro's default session context (not recommended)
# model = "claude-sonnet-4-20250514"
# timeoutMs = 300000

Use a lean agent to cut token usage by ~7×. By default, every kiro-cli chat call loads Kiro's full system prompt plus every MCP tool schema from your global config — roughly 12–18K extra input tokens per call. Create a minimal agent that skips all of that:

cp examples/kiro-agent-memconsolidate.json ~/.kiro/agents/memconsolidate.json

The Kiro backend passes --agent memconsolidate automatically, so no further config is needed. Measured on a trivial prompt: 0.01 credits with the lean agent vs. 0.07 credits with the default (same output quality).

See examples/kiro-agent-memconsolidate.json — the agent has mcpServers: {}, tools: [], and useLegacyMcpJson: false so it doesn't inherit anything from your global Kiro config.

Configure clients manually

The --setup and --configure wizards handle this for you. This section is for users who want to wire things up by hand.

Kiro (CLI and IDE)

Edit ~/.kiro/settings/mcp.json:

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "mcp-agent-memory"],
      "env": {
        "MEMORY_DIRECTORY": "~/.agent-memory/memory",
        "SESSION_DIRECTORY": "~/.agent-memory/sessions"
      },
      "disabled": false,
      "timeout": 30000,
      "autoApprove": ["memory_read", "memory_search", "memory_append_session", "memory_daemon_status"]
    }
  }
}

Why autoApprove? All memory tools are local-only filesystem operations — they read/write markdown files under ~/.agent-memory/ and never make network calls. Adding them to autoApprove lets Kiro call them without prompting you for confirmation each time, which is essential for the seamless "read memory at session start" experience.

Then ask Kiro: "Read my memory index." or "Remember this: I prefer pnpm over npm."

Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "mcp-agent-memory"],
      "env": {
        "MEMORY_DIRECTORY": "~/.agent-memory/memory",
        "SESSION_DIRECTORY": "~/.agent-memory/sessions"
      },
      "autoApprove": ["memory_read", "memory_search", "memory_append_session", "memory_daemon_status"]
    }
  }
}

Restart Claude Desktop. The memory_* tools will appear.

Cursor

Add to ~/.cursor/mcp.json with the same server block (including autoApprove).

Environment variables

Variable

Default

Description

MEMORY_DIRECTORY

~/.agent-memory/memory

Where the daemon stores consolidated memory files

SESSION_DIRECTORY

~/.agent-memory/sessions

Where agent-written session summaries land

Both paths must match what your agent-memory-daemon config uses.

Recommended agent prompt

Tell your agent to call memory_read at the start of a conversation and memory_append_session at the end. Example steering rule for Kiro (~/.kiro/steering/memory.md):

At the start of every session, call memory_read (no arguments) to load my memory
index. Only pass `topics` when the task genuinely needs the full content of a
specific topic file.

When you learn something durable about me, my projects, or my preferences, call
memory_append_session with a concise markdown summary. Target 300-800 tokens,
use structured headers and bullets (not prose), and focus on durable findings
and decisions — not play-by-play. Verbose summaries cost more during the
daemon's consolidation pass.

Token usage tips

Each of the three tools has a different cost profile. A few practices keep inference + consolidation bills low:

  • memory_read with no arguments returns only the MEMORY.md index (typically <1 KB). Prefer this over topics unless you need full content.

  • memory_search is substring-based and returns ≤3 matching lines per file — cheaper than loading whole topic files.

  • memory_append_session costs nothing at call time, but every session gets processed by the daemon's LLM during consolidation. Keep summaries concise and structured.

  • Consolidate or prune old topic files occasionally. Run mcp-agent-memory --configure — it now warns if your memory directory exceeds 25 files or 200 KB.

  • Session pruning after extraction is handled by the daemon, not the MCP server. See agent-memory-daemon's config for options that archive or delete sessions after they're processed (prevents the daemon from re-scanning old sessions forever).

License

MIT

Available Tools

4 tools
memory_append_sessionA

Append a session summary to the sessions directory. The daemon will later extract durable memories from it. Call this at the end of meaningful exchanges. Keep summaries focused on durable findings and decisions (target 300-800 tokens), not play-by-play — longer summaries cost more during consolidation.

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYesMarkdown-formatted session summary. Use structured headers and bullets for better extraction; avoid verbose prose.
sourceNoOrigin tag, e.g., "kiro", "claude-desktop"

TDQS

A4.5/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. It discloses that the daemon will later extract memories and that longer summaries incur higher cost. This adds useful behavioral context beyond the simple append.

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

Conciseness5/5

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

Three compact sentences, each serves a purpose: action, timing, and content guidelines. No redundancy, front-loaded with core function.

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

Completeness5/5

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

For a simple tool with two parameters and no output schema, the description provides complete guidance: what, when, how, and cost implications. No gaps.

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% description coverage, but description adds significant value by advising on summary focus, token target (300-800), and avoiding verbose prose. This guides the agent beyond schema definitions.

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

Purpose5/5

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

Description clearly states 'Append a session summary to the sessions directory' with a specific verb and resource. It distinguishes from sibling read tools (memory_read, memory_search) by being a write operation.

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

Usage Guidelines4/5

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

Explicitly advises 'Call this at the end of meaningful exchanges' and provides guidelines on summary length and content. No exclusion criteria or alternatives mentioned, but context is clear.

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

memory_daemon_statusA

Check whether the memory consolidation daemon is running. Reports if the daemon is not installed or not available on this platform.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior4/5

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

Since no annotations are provided, the description carries the full burden. It discloses that the tool reports if the daemon is not installed or not available, indicating it can return multiple status outcomes. No contradictions with annotations (none provided).

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

Conciseness5/5

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

Two sentences, no wasted words. The core purpose is front-loaded in the first sentence, and the second adds extra detail concisely.

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 parameters and no output schema, the description covers the tool's purpose effectively. It explains what the tool does and the possible outcomes (daemon running, not installed, not available). No obvious gaps.

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 zero parameters and schema description coverage is 100% (trivially). The description does not need to add parameter information. Baseline for 0 params is 4.

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

Purpose5/5

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

Description clearly states the tool checks the running status of the memory consolidation daemon, and also reports if the daemon is not installed or not available on the platform. This distinguishes it from sibling tools (memory_append_session, memory_read, memory_search) which perform different memory operations.

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 usage context (checking daemon status) but does not explicitly state when to use this tool versus alternatives. No exclusions or alternatives are mentioned, though sibling tools have different purposes.

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

memory_readA

Read the agent memory index (MEMORY.md) and optionally specific topic files. Call with no arguments to load only the lightweight index (cheap). Pass topics only when you need the full content of a specific topic file.

ParametersJSON Schema
NameRequiredDescriptionDefault
topicsNoOptional topic file names to load in full (e.g., ["preferences", "projects"]). Omit to return the index only.

TDQS

A4.6/5.0
Behavior4/5

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

No annotations are provided, so the description must disclose behavior. It reveals that calling without arguments is 'cheap' (lightweight), implying topic file retrieval is more expensive. This adds useful context beyond the schema, though it could further clarify error handling or return format.

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

Conciseness5/5

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

Two sentences, front-loaded with the core purpose, then a follow-up sentence with usage details. No filler or 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?

For a simple read tool with one optional parameter, the description covers the main usage. However, without an output schema, it lacks details on the return format (e.g., structure of the index or topic file content). This is a minor gap.

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%, but the description adds meaning: it explains that the topics parameter triggers full content retrieval, while omitting it returns the index. This informs the agent of the parameter's purpose beyond data typing.

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 'Read the agent memory index (MEMORY.md) and optionally specific topic files.' It identifies the action (read) and resource (memory index/topic files), and distinguishes from siblings by specifying the no-arguments vs. topics usage.

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

Usage Guidelines5/5

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

Explicit guidance: 'Call with no arguments to load only the lightweight index (cheap). Pass topics only when you need the full content of a specific topic file.' This tells the agent when to use each mode, effectively differentiating between lightweight and full retrieval.

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

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

TDQS

A4.2/5.0
Disambiguation5/5

Each tool serves a distinct purpose: appending sessions, checking daemon status, reading memory index, and searching. No overlaps or ambiguities.

Naming Consistency5/5

All tools follow a consistent pattern: 'memory_' prefix followed by a descriptive verb or verb_noun (append_session, daemon_status, read, search). Naming is predictable and clear.

Tool Count5/5

With 4 tools, the surface is concise and well-scoped for a memory management server. Each tool addresses a core operation without redundancy.

Completeness4/5

The tools cover essential operations (append, read, search, status). Missing update/delete might be a minor gap, but the memory consolidation daemon likely handles lifecycle, making this acceptable.

Maintenance

ActivityMaintained
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

  • Recall by RecallWorks

    Recallofficial

    RecallWorks
    A
    license
    Not graded
    quality
    C
    maintenance
    Open-source MCP memory server for AI agents — persistent, searchable, tiered memory across sessions. Works over stdio (Cursor, Claude Desktop) or HTTP+SSE. MIT licensed.
    7
    MIT
  • Amber by ambermem

    Amberofficial

    ambermem
    A
    license
    A
    quality
    B
    maintenance
    Gives your AI persistent memory across conversations. Stores facts automatically, finds them by meaning using hybrid search with query expansion, and organizes everything into topics without manual tagging.
    18
    1
    MIT
  • @memofs/mcp-server by memo-fs

    @memofs/mcp-serverofficial

    memo-fs
    A
    license
    Not graded
    quality
    B
    maintenance
    @memofs/mcp-server lets AI coding agents (Claude Code, Claude Desktop, Codex, Cursor, opencode, Gemini CLI, GitHub Copilot, Zed, and any other MCP client) securely read and write MemoFS memory through standard Model Context Protocol tools.
    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/tverney/mcp-agent-memory'

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