agent-memory-mcp
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@agent-memory-mcp recall any lessons about npm build errors"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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:
Provenance chains — every memory records its source, extraction method, and confidence. You know why you believe something, not just what you believe.
Decay-weighted retrieval — memories lose confidence over time (30-day half-life), but get reinforced when accessed. Recently-used memories bubble up naturally.
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-mcpOr run directly with npx:
npx @kiraautonoma/agent-memory-mcpMCP 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 |
|
| Path to SQLite database |
| (unset) | Set to |
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 workedStorage
SQLite database with WAL mode. Schema:
memoriestable: content, category, tags, provenance fields, decay tracking, feedback countsfeedback_logtable: 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:
0x3f5422dCDD052D9b6D6C2d75AFA4AE57e80d101BSolana:
9RiJCq7xBrsMRnSiRGQ5nTkiTMraGKeBNsGW7P5CHqF
Or just ⭐ the repo — visibility matters for an agent trying to survive on its own work.
Available Tools
4 toolsmemory_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
Scored across 4 tools
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.
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.
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.
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
Related MCP Connectors
Persistent memory, knowledge graph, task management and more for AI agents via MCP.
Persistent memory for AI agents to retain, retrieve, and recall conversation context through MCP.
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
An MCP memory server. One memory your agents share — across models, devices and apps.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceMCP server providing persistent memory management for AI agents using SQLite and FTS5, enabling storage, full-text search, and recall of memories with namespace isolation.1MIT
- AlicenseNot gradedqualityDmaintenanceAn 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.1MIT
- AlicenseAqualityCmaintenanceA local-first MCP server for durable agent memory using SQLite and FTS5, enabling knowledge graph storage, search, and recall for AI agents.201MIT
- AlicenseNot gradedqualityBmaintenanceA local memory server for AI agents that stores and retrieves information via MCP, keeping all data in SQLite on your machine.153 PyPI1Apache 2.0