light-agent-memory-mcp-server
Related Servers
Alternatives to light-agent-memory-mcp-server
No user-submitted related servers found.
Related Servers
- AlicenseAqualityCmaintenanceProvides persistent local memory for any MCP-compatible AI agent, enabling agents to store, search, recall, forget, export, and manage preferences, rules, and facts with zero dependencies, no cloud, and no API keys.8MIT
- AlicenseNot gradedqualityCmaintenancePersistent memory for AI coding agents. Enables agents to save and recall decisions, patterns, bugs, and context across sessions via an MCP server with local SQLite storage.4 npm2MIT
- AlicenseNot gradedqualityDmaintenanceProvides persistent, local-first AI memory across sessions via MCP tools for storing, searching, and retrieving context from past interactions.1MIT
- AlicenseNot gradedqualityBmaintenanceA local-first MCP memory server providing persistent, searchable memory for AI agents, powered by SQLite.1 npm1Apache 2.0
- AlicenseNot gradedqualityFmaintenanceLocal-first, auditable memory for AI agents. Provides durable context for MCP hosts with SQLite storage, CLI, and MCP tools for memory management.2Apache 2.0
- AlicenseNot gradedqualityAmaintenanceProvides persistent memory for AI coding agents via MCP, enabling agents to store and semantically recall facts, events, and lessons across sessions, all running locally without cloud dependencies.Apache 2.0
TDQS
Scored across 12 tools
The type-specific tools (project/pref/learning) are fairly distinct, but the generic memory_save, memory_search, and memory_list overlap with specialized equivalents like memory_project_save, memory_learning_search, and memory_project_list. The descriptions clarify the generic vs. specific distinction, but an agent still faces multiple paths to accomplish the same operation.
Tool names consistently use a memory_ prefix and mostly follow a memory_<type>_<action> pattern. Minor inconsistencies exist: 'search' is used for learning where 'list' or 'get' might be expected, and the top-level memory_save/memory_search/memory_delete/memory_list deviate from the type-specific naming pattern.
Twelve tools is reasonable for a memory system covering projects, preferences, and learnings. The count is slightly inflated by the generic memory_* tools that duplicate type-specific functionality, but overall the server remains well-scoped and navigable.
The server covers create, read, list, search, and delete across all memory types, either through type-specific or generic tools. Minor gaps exist—learning has no direct get-by-ID function, and deletion is only exposed through the generic memory_delete—but common workflows can be completed with existing tools.