EGC
Related Servers
Alternatives to EGC
No user-submitted related servers found.
Related Servers
- 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
- AlicenseAqualityAmaintenancePersistent memory for AI coding agents, storing decisions, bug fixes, conventions, and discoveries in a local SQLite database and automatically recalling them when relevant. Works with Claude Code, Codex, Cursor, Gemini CLI, and other MCP-compatible agents.222MIT
- FlicenseNot gradedqualityBmaintenanceLocal-first memory for AI coding agents. Indexes your Claude Code, Codex, Cursor, Cline and Gemini CLI history by repo/branch/worktree and hands a context capsule (decisions, touched files, next steps) to the next agent over MCP.-
- FlicenseNot gradedqualityAmaintenanceLocal MCP server that lets your AI coding agent query its own cross-tool project history - file/command freshness, past test failures, cost & token spend, cache status, and session handoff - over stdio, 100% local, no telemetry.46-
- FlicenseNot gradedqualityCmaintenanceLocal-first cross-agent memory for AI coding agents. Persistent, shared memory over MCP — what you tell one agent can be recalled by another — with all data stored in a single local SQLite file, no cloud and no API keys.-
- AlicenseNot gradedqualityBmaintenanceLocal, cross-agent memory for AI coding agents using a single SQLite file, enabling persistent sessions and durable facts shared across multiple MCP-compatible tools.10 npmMIT
TDQS
Scored across 24 tools
Most tools are grouped by clear prefixes (session_, team_, lesson_, working_memory_), but there are several confusable pairs: get_project_state vs get_state, query_history vs search_history, and store_decision vs update_state. The descriptions help disambiguate, but the name similarity and overlapping memory-related purposes create real misselection risk.
The server mixes two naming conventions: object-first names like working_memory_set, session_send, and lesson_save, and action-first names like get_state, store_decision, and claim_path. Within each cluster the pattern is fairly consistent, but across the full surface the conventions are mixed and team_status/session_peers/session_events use noun forms alongside verb forms.
At 24 tools, the server is at the heavy end of reasonable and spans seven distinct subsystems (state, decisions, working memory, lessons, team sync, session bus, hook analysis). Each tool has a distinct job, but the overall surface is large and would benefit from consolidation in areas like session_wait/session_events.
The core workflows are well covered: state read/update, working memory set/get/list, lesson save/recall/reinforce, team init/sync/status, and session coordination. However, there are notable lifecycle gaps: no explicit delete for decisions or working memory keys, no way to remove/archive a decision, and no direct session end tool, relying instead on TTL expiry and heartbeats.