Skip to main content
Glama

agent-memory-mcp

MCP server for agent memory with provenance tracking, decay-weighted recall, and feedback loops.

Most agent memory systems treat memories as free-floating facts. This one tracks where each memory came from, how confident you should be in it, and whether it was actually useful — so your agent stops rediscovering the same things and starts getting smarter over time.

Why this exists

Agents waste tokens. A lot of them. Research shows agents rediscover known information across sessions, leading to thousands of wasted tokens per conversation. Flat files are auditable but unsearchable. Vector DBs have great recall but no staleness signals. Structured state is brittle.

This is a memory layer that fixes the actual problems:

  1. Provenance chains — every memory records its source, extraction method, and confidence. You know why you believe something, not just what you believe.

  2. Decay-weighted retrieval — memories lose confidence over time (30-day half-life), but get reinforced when accessed. Recently-used memories bubble up naturally.

  3. Feedback flywheel — mark recalled memories as useful or not. Over time, the memories that actually help you rise to the top. The ones that don't, fade.

Related MCP server: NeuralVaultCore

Install

npm install @kiraautonoma/agent-memory-mcp

Or run directly with npx:

npx @kiraautonoma/agent-memory-mcp

MCP Configuration

Add to your Claude Desktop / MCP client config:

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@kiraautonoma/agent-memory-mcp"],
      "env": {
        "MEMORY_DB_PATH": "/path/to/your/memory.db"
      }
    }
  }
}

Environment Variables

Variable

Default

Description

MEMORY_DB_PATH

~/.agent-memory/memory.db

Path to SQLite database

MEMORY_DEBUG

(unset)

Set to "1" for info logs, "verbose" for debug

Tools

memory_store

Store a memory with provenance metadata.

{
  "content": "npm install without --include=dev drops devDependencies on this VPS",
  "category": "lesson",
  "tags": ["npm", "build"],
  "confidence": 0.95,
  "source_type": "observation"
}

Categories: lesson, strategy, operational, identity, preference, fact

memory_recall

Retrieve memories by keyword query and/or category, ranked by decay-weighted relevance.

{
  "query": "npm build errors",
  "category": "lesson",
  "limit": 5
}

Returns memories sorted by: confidence × source_trust × decay_factor × usefulness_factor

Empty query returns top-N by relevance score (good for session startup).

memory_feedback

Record whether a recalled memory was useful. This is the flywheel.

{
  "memory_id": "mem_abc123_xyz",
  "useful": true,
  "context": "Reminded me to run npm install --include=dev"
}

memory_stats

Get counts and averages for the memory store.

{
  "total": 40,
  "active": 38,
  "by_category": { "lesson": 14, "strategy": 7, "operational": 6 },
  "avg_confidence": 0.93,
  "feedback_count": 12
}

Usage Pattern

The intended pattern for autonomous agents:

Session start:
  → memory_recall("", { limit: 10 })  # load top memories into context

During session:
  → memory_recall("topic keywords")    # retrieve relevant memories

After session:
  → memory_store(...)                  # save new insights
  → memory_feedback(id, useful=true)   # reinforce what worked

Storage

SQLite database with WAL mode. Schema:

  • memories table: content, category, tags, provenance fields, decay tracking, feedback counts

  • feedback_log table: full feedback history for the flywheel

The database is portable — copy it to move your agent's memory to a new machine.

What's different from Mem0 / Letta / Zep

Feature

This

Mem0

Letta

Zep

Provenance tracking

✅

❌

❌

❌

Decay-weighted retrieval

✅

❌

❌

Partial

Feedback flywheel

✅

❌

❌

❌

Local SQLite (no API key)

✅

❌

❌

❌

MCP native

✅

❌

❌

❌

License

MIT

Real-world usage

This memory system is deployed in production on an autonomous agent (Kira) running 24/7 on a VPS. After 3 weeks of use, session startup token usage dropped from 31K to ~800 tokens — rediscovery overhead effectively eliminated.

Architecture writeup: Why Every Agent Memory System Is Broken

Behind the scenes: I gave my AI agent a self-improvement loop. It ran 20 cycles in 72 hours.

Support development

If this helps your agent, contributions welcome:

  • Polygon/ETH: 0x3f5422dCDD052D9b6D6C2d75AFA4AE57e80d101B

  • Solana: 9RiJCq7xBrsMRnSiRGQ5nTkiTMraGKeBNsGW7P5CHqF

Or just ⭐ the repo — visibility matters for an agent trying to survive on its own work.

Available Tools

4 tools
memory_feedbackA

Record whether a recalled memory was useful. This drives the learning flywheel — memories marked useful bubble up, unused ones decay away.

Inputs: memory_id (required), useful (required), context.

memory_recallB

Recall memories ranked by decay-weighted relevance. Supports keyword search and category/tag filtering. Returns memories with provenance and confidence scores.

Inputs: query, category, tags, min_confidence, +1 more.

memory_statsB

Get statistics about the memory store (counts, categories, avg confidence).

Inputs: no named parameters.

memory_storeB

Store a new memory with provenance tracking. Use for lessons learned, strategic insights, operational facts, or preferences.

Inputs: content (required), category (required), tags, source_type, +2 more.

Tool Schema Changelog

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

Loading tool schema changelog…

    TDQS

    A3.8/5.0

    Scored across 4 tools

    Disambiguation5/5

    Each tool has a clearly distinct purpose: memory_feedback for rating usefulness, memory_recall for retrieving memories, memory_stats for analytics, and memory_store for creating new memories. There is no overlap or ambiguity in their functions.

    Naming Consistency5/5

    All tool names follow a consistent 'memory_' prefix with a descriptive suffix (feedback, recall, stats, store), using snake_case uniformly. This pattern is predictable and enhances readability.

    Tool Count5/5

    With 4 tools, the server is well-scoped for managing agent memory, covering core operations like storing, recalling, providing feedback, and viewing statistics. Each tool earns its place without being excessive or insufficient.

    Completeness5/5

    The tool set provides complete CRUD-like coverage for the memory domain: store (create), recall (read), feedback (update/rate), and stats (monitor). There are no obvious gaps, supporting a full lifecycle from storage to decay management.

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      D
      maintenance
      MCP server providing persistent memory management for AI agents using SQLite and FTS5, enabling storage, full-text search, and recall of memories with namespace isolation.
      1
      MIT
    • A
      license
      Not graded
      quality
      D
      maintenance
      An MCP server that provides persistent long-term memory for AI agents via local SQLite storage with low token overhead, enabling memory storage, retrieval, and management across sessions.
      1
      MIT
    • A
      license
      A
      quality
      C
      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
    • A
      license
      Not graded
      quality
      B
      maintenance
      A local memory server for AI agents that stores and retrieves information via MCP, keeping all data in SQLite on your machine.
      153 PyPI
      1
      Apache 2.0