state-memory-mcp
Related Servers
Alternatives to state-memory-mcp
No user-submitted related servers found.
Related Servers
- FlicenseNot gradedqualityDmaintenanceA persistent, conflict-aware memory MCP server for AI coding assistants (Cursor, Claude Code).-
- AlicenseNot gradedqualityDmaintenanceA self-hosted MCP server that provides AI assistants with a shared, persistent SQLite-backed memory for storing and retrieving project context, decisions, and discoveries. It enables cross-session continuity and team-wide knowledge sharing to keep AI coding tools aligned and informed.3MIT
- AlicenseNot gradedqualityDmaintenanceA local MCP memory server that gives AI assistants durable project memory across coding sessions, storing context, changes, and decisions.2 npm1MIT
- AlicenseBqualityDmaintenanceMCP server that provides cross-session persistent memory for AI coding assistants using local vector database and semantic search, enabling automatic recall of project context, issues, and tasks.9127 PyPI91Apache 2.0
- AlicenseNot gradedqualityBmaintenancePersistent project memory and task management for AI coding agents through MCP. Lets Claude Code, Cursor, Codex and other MCP clients save decisions and bug fixes, search relevant context, and reuse it across sessions.1MIT
- FlicenseNot gradedqualityAmaintenanceA local-first MCP memory server that lets AI coding agents store, search, and recall project-specific and cross-project knowledge, so architecture decisions, preferences, error patterns, and coding guidelines persist across sessions. It also exposes optional task-queue tools for handing off autonomous work that draws on the same stored context.-
TDQS
Scored across 13 tools
The descriptions are unusually thorough with explicit 'use X instead of Y' guidance, which genuinely helps separate tools like manage_nodes vs manage_edges vs use_blackboard and manage_snapshots vs manage_database vs get_events. However, the underlying domain heavily overlaps: nodes/edges/specs/blackboard all manipulate graph-like entities, and query_graph/get_analytics/run_diagnostics all operate on the same graph for read, aggregate, and maintenance purposes. Boundaries are clarified by prose rather than being intrinsically clean.
Most tools use a manage_* pattern (manage_data, manage_nodes, manage_edges, manage_sessions, manage_tasks, manage_snapshots, manage_specs, manage_database), which is consistent. But the remaining tools break the pattern with distinct verbs (query_graph, get_analytics, get_events, run_diagnostics, use_blackboard), producing mixed conventions. It remains readable, but there is no single predictable verb_noun scheme.
13 tools is within the well-scoped range and appropriate for a state/memory graph server covering graph, tasks, sessions, specs, analytics, events, and diagnostics. The design consolidates many operations as actions within each tool rather than exploding the tool count, keeping the surface manageable. Slightly heavy given the breadth, but reasonable.
Coverage is broad: node/edge CRUD, task workflow, sessions, snapshots/time-travel, specs, database maintenance, graph queries, analytics, event ledger, diagnostics, and multi-agent blackboard. Most lifecycle operations (create, update, get, list, remove, batch) appear across the mutation tools. Minor gaps exist, such as bulk-delete actions being less explicit than bulk-create.