de en es ja ko ru zh

Agent Memory

Name: Agent Memory
Author: tverney

by tverney

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

エージェントメモリ用ファイルシステムMCP

mcp-agent-memory MCP server

agent-memory-daemonを、Kiro (CLI & IDE)、Claude Desktop、CursorなどのMCP対応クライアントに公開するためのMCPサーバーです。

デーモンが思考（統合と抽出）を行い、このサーバーは軽量なファイルシステムブリッジとして機能するため、エージェントはModel Context Protocolを通じてメモリの読み取り、追記、検索を行うことができます。

仕組み

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

MCPサーバーは~/.agent-memory/配下のファイルを読み書きします
デーモンは同じディレクトリを監視し、統合と抽出の処理を実行します
両者が直接通信することはありません。ファイルシステムが契約（インターフェース）となります

Related MCP server: Recall

公開されるツール

ツール	目的
`memory_read`	`MEMORY.md`インデックス（およびオプションのトピックファイル）をエージェントのコンテキストに読み込む
`memory_append_session`	デーモンが後でメモリを抽出するためのセッション要約を書き込む
`memory_search`	メモリファイル全体に対する部分文字列検索
`memory_daemon_status`	統合デーモンが実行中かどうかを確認する（macOS LaunchAgentのみ）

インストール

npm install -g mcp-agent-memory

クイックスタート（対話型ウィザード）

メモリディレクトリ、デーモン、クライアント設定、ログ、LaunchAgentなど、すべてをセットアップする最も速い方法はセットアップウィザードを使用することです：

mcp-agent-memory --setup

6つの質問に答えます：

メモリディレクトリ — .agent-memory/の場所（デフォルトは~/.agent-memory）
統合デーモンをインストールしますか？ — MCPのみのモードにする場合は「no」と答えてください（エージェントはメモリの読み取り/書き込み/検索は可能ですが、自動統合は行われません）
LLMバックエンド — bedrock、openai、またはkiro（デーモンを拒否した場合はスキップされます）
統合設定 — min_hours、min_sessions、抽出間隔、最大文字数
実行モード — standalone（手動起動）またはlaunchagent（ログイン時に自動起動、macOSのみ）
ログディレクトリ + TTL — ログの保存場所と保持日数（0は無期限）
クライアント登録 — Kiro、Claude Desktop、Cursorの設定にMCPサーバーを自動登録する（既存のMCPエントリは保持されます）

kiroバックエンドを選択すると、ウィザードはトークン使用量を約7分の1に削減する軽量エージェントを~/.kiro/agents/memconsolidate.jsonにコピーします（Kiroバックエンドを参照）。

launchagentを選択すると、ウィザードはagent-memory-daemonがインストールされているか確認し（インストールされていない場合はnpm install -gを提案）、plistを登録して起動します。

CLIリファレンス

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はクライアントMCP設定内の他のエントリを保持し、memoryキーのみを削除します。デフォルトでは、統合されたメモリを復元できるように、~/.agent-memory/をタイムスタンプ付きの.bak-*ディレクトリにバックアップします。

手動インストール

ウィザードを使わずに手動で行う方法は以下の通りです。

デーモンのインストール（オプション）

MCPサーバーは単体でも動作します。単に~/.agent-memory/配下のファイルを読み書きするだけです。メモリは永続化されますが、デーモンを追加するまでは統合やセッションからの抽出は行われません。

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

このMCPサーバーが期待するディレクトリレイアウトに適合した設定については、examples/memconsolidate.tomlを参照してください。

ログイン時にデーモンを実行する（macOS）

デーモンを手動で起動する代わりに、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

2番目の引数としてカスタム設定パスを渡します：./scripts/daemon.sh start /path/to/config.toml。ログは~/.agent-memory/logs/daemon.{out,err}.logに出力されます。removeを実行しても、設定ファイルやメモリファイルはそのまま残ります。

KiroをLLMバックエンドとして使用する

Kiroクレジットをお持ちの場合は、BedrockやOpenAIのAPI料金を支払う代わりに、kiro-cliを通じてデーモンを実行できます。これにはkiroバックエンドを追加したagent-memory-daemon 2.7以上（feat/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

軽量エージェントを使用してトークン使用量を約7分の1に削減します。 デフォルトでは、kiro-cli chatを呼び出すたびに、Kiroの完全なシステムプロンプトとグローバル設定からのすべてのMCPツールスキーマが読み込まれ、呼び出しごとに約12〜18Kの追加入力トークンが消費されます。これらをすべてスキップする最小限のエージェントを作成します：

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

Kiroバックエンドは自動的に--agent memconsolidateを渡すため、追加の設定は不要です。単純なプロンプトで測定した結果：軽量エージェントで0.01クレジット、デフォルトで0.07クレジット（出力品質は同じ）。

examples/kiro-agent-memconsolidate.jsonを参照してください。このエージェントはmcpServers: {}、tools: []、useLegacyMcpJson: falseを設定しているため、グローバルなKiro設定から何も継承しません。

クライアントの手動設定

--setupおよび--configureウィザードがこれらを処理します。このセクションは手動で設定したいユーザー向けです。

Kiro (CLIおよびIDE)

~/.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
    }
  }
}

その後、Kiroに「メモリインデックスを読んで」や「これを覚えておいて：私はnpmよりpnpmを好む」と伝えてください。

Claude Desktop

~/Library/Application Support/Claude/claude_desktop_config.json（macOS）または%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"
      }
    }
  }
}

Claude Desktopを再起動すると、memory_*ツールが表示されます。

Cursor

同じサーバーブロックを使用して~/.cursor/mcp.jsonに追加します。

環境変数

変数	デフォルト	説明
`MEMORY_DIRECTORY`	`~/.agent-memory/memory`	デーモンが統合されたメモリファイルを保存する場所
`SESSION_DIRECTORY`	`~/.agent-memory/sessions`	エージェントが書き込んだセッション要約が保存される場所

両方のパスは、agent-memory-daemonの設定で使用しているものと一致させる必要があります。

推奨されるエージェントプロンプト

会話の開始時にmemory_readを、終了時にmemory_append_sessionを呼び出すようエージェントに指示してください。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.

トークン使用量のヒント

3つのツールにはそれぞれ異なるコストプロファイルがあります。以下の習慣により、推論と統合のコストを低く抑えることができます：

**引数なしのmemory_read**はMEMORY.mdインデックスのみを返します（通常1KB未満）。コンテンツ全体が必要な場合を除き、トピックファイルよりもこちらを優先してください。
**memory_search**は部分文字列ベースで、ファイルごとに最大3行の一致行を返します。トピックファイル全体を読み込むよりも安価です。
**memory_append_session**は呼び出し時のコストはかかりませんが、統合時にデーモンのLLMによって処理されます。要約は簡潔かつ構造化してください。
古いトピックファイルは時々統合または削除してください。mcp-agent-memory --configureを実行すると、メモリディレクトリが25ファイルまたは200KBを超えた場合に警告が表示されるようになりました。
抽出後のセッション削除はMCPサーバーではなくデーモンによって処理されます。処理後にセッションをアーカイブまたは削除するオプションについては、agent-memory-daemonの設定を参照してください（デーモンが古いセッションを永遠に再スキャンするのを防ぎます）。

ライセンス

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

Name	Required	Description	Default
`content`	Yes	Markdown-formatted session summary. Use structured headers and bullets for better extraction; avoid verbose prose.
`source`	No	Origin 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

Name	Required	Description	Default
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

Name	Required	Description	Default
`topics`	No	Optional 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.

memory_searchA

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

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Substring to search for across all memory files (case-insensitive)

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior. It specifies case-insensitive substring search but omits what the response contains (e.g., matching lines, file paths) and any performance implications.

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 purpose, no redundant information.

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?

Despite low complexity, the lack of output schema and omission of response format leaves the agent guessing about what will be returned, reducing completeness.

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

Parameters3/5

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

Schema coverage is 100% with full parameter description; the tool description adds no extra semantics beyond restating the schema's content.

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

Purpose5/5

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

The description clearly states the tool searches memory files for a substring, distinguishing it from sibling 'memory_read' which presumably loads entire files.

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 use for 'recall specific facts without loading everything,' providing clear context for when to use, though it could name the alternative sibling directly.

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.

2 tool updatesv1.0.3Jun 17, 2026
- Addedmemory_daemon_status
- Changedmemory_search1 field changed
  - addedInput schema / properties / query / description
```
Added value: +"Substring to search for across all memory files (case-insensitive)"
```
3 tool updatesv1.0.0Apr 27, 2026
- First observedmemory_append_session
- First observedmemory_read
- First observedmemory_search

Deploy Server

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

TDQS

A4.2/5.0

Scored 2026-06-17 19:01 across 4 tools

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

ActivityNo data

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Great ArrowOAuth
ai.greatarrow
Shared memory and actions for Claude, Kiro, OpenAI, Cursor, and other MCP-compatible AI clients.
Knowledge & Memory
1
saagarpatel.dev Portfolio A
io.github.saagpatel
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Search Documentation Access
82
Agentage MemoryOAuth
io.agentage
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
Knowledge & Memory File Systems
2
mifactory-agent-memory C
io.github.mifactory-bot
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
Knowledge & Memory Autonomous Agents Agent Orchestration
22

Related MCP Servers

MCP-Mem0
Knowledge & Memory Vector Databases Autonomous Agents
coleam00
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that provides AI agents with persistent memory capabilities through Mem0, allowing them to store, retrieve, and semantically search memories.
Updated 2 years ago (2025-04-13 01:17 UTC)
684
MIT
Recallofficial
Knowledge & Memory RAG Systems
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.
Updated 4 months ago (2026-06-16 08:03 UTC)
8
MIT
Amberofficial
Knowledge & Memory RAG Systems
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.
Updated 3 days ago (2026-10-11 03:51 UTC)
18
1
MIT
@memofs/mcp-serverofficial
Knowledge & Memory RAG Systems
memo-fs
A
license
Not graded
quality
A
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.
Updated 18 days ago (2026-09-26 13:31 UTC)
6
MIT

エージェントメモリ用ファイルシステムMCP

仕組み

公開されるツール

インストール

クイックスタート（対話型ウィザード）

CLIリファレンス

手動インストール

デーモンのインストール（オプション）

ログイン時にデーモンを実行する（macOS）

KiroをLLMバックエンドとして使用する

クライアントの手動設定

Kiro (CLIおよびIDE)

Claude Desktop

Cursor

環境変数

推奨されるエージェントプロンプト

トークン使用量のヒント

ライセンス

Available Tools

TDQS

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

MCP-Mem0

Recallofficial

Amberofficial

@memofs/mcp-serverofficial