Skip to main content
Glama
deenesjakoruzh
tverney

Agent Memory

by tverney
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

에이전트 메모리를 위한 파일 시스템 MCP

mcp-agent-memory MCP server

Kiro(CLI 및 IDE), Claude Desktop, Cursor 등 모든 MCP 호환 클라이언트에 agent-memory-daemon을 노출하는 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/ 아래의 파일을 읽고 씁니다.

  • 데몬은 동일한 디렉토리를 감시하며 통합 및 추출 작업을 수행합니다.

  • 이 둘은 서로 직접 통신하지 않으며, 파일 시스템이 계약(contract) 역할을 합니다.

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가지 질문을 합니다:

  1. 메모리 디렉토리 — .agent-memory/가 위치할 곳 (기본값 ~/.agent-memory)

  2. 통합 데몬 설치 여부 — MCP 전용 모드라면 "no" 선택 (에이전트가 메모리를 읽기/쓰기/검색할 수는 있지만 자동 통합은 수행되지 않음)

  3. LLM 백엔드 — bedrock, openai, 또는 kiro (데몬 설치를 거부하면 건너뜀)

  4. 통합 설정 — min_hours, min_sessions, 추출 간격, 최대 문자 수

  5. 실행 모드 — standalone (수동 시작) 또는 launchagent (로그인 시 자동 시작, macOS 전용)

  6. 로그 디렉토리 + TTL — 로그 저장 위치 및 보관 일수 (0 = 영구 보관)

  7. 클라이언트 등록 — Kiro, Claude Desktop 및/또는 Cursor 설정에 MCP 서버 자동 등록 (기존 MCP 항목은 유지됨)

kiro 백엔드를 선택하면 마법사는 토큰 사용량을 약 7배 절감하는 간소화된 에이전트를 ~/.kiro/agents/memconsolidate.json에 복사합니다 (Kiro를 LLM 백엔드로 사용 참조).

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

두 번째 인수로 사용자 지정 설정 경로를 전달하세요: ./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배 절감하세요. 기본적으로 모든 kiro-cli chat 호출은 Kiro의 전체 시스템 프롬프트와 전역 설정의 모든 MCP 도구 스키마를 로드하므로 호출당 약 12~18K의 추가 입력 토큰이 발생합니다. 이를 모두 건너뛰는 최소한의 에이전트를 만드세요:

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

Kiro 백엔드는 --agent memconsolidate를 자동으로 전달하므로 추가 설정이 필요하지 않습니다. 간단한 프롬프트로 측정했을 때: 간소화된 에이전트 사용 시 0.01 크레딧 vs 기본값 사용 시 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.

토큰 사용 팁

세 가지 도구는 각각 다른 비용 프로필을 가집니다. 다음 관행을 통해 추론 및 통합 비용을 낮게 유지할 수 있습니다:

  • 인수 없이 memory_read 호출 시 MEMORY.md 인덱스(일반적으로 1KB 미만)만 반환합니다. 전체 내용이 필요한 경우가 아니라면 topics보다 이 방식을 선호하세요.

  • **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
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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.0.3
    • Addedmemory_daemon_status
    • Changedmemory_search1 field changed
      • addedInput schema / properties / query / description
        Added value: +"Substring to search for across all memory files (case-insensitive)"
  2. 3 tool updatesv1.0.0
    • 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 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

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