ellmos-homebase-mcp
OfficialRelated Servers
Alternatives to ellmos-homebase-mcp
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
- AlicenseBqualityBmaintenanceEnables multiple AI agents and harnesses to share one local SQLite-backed memory store over standard MCP, so decisions, preferences, and past pitfalls carry across sessions instead of being re-explained. Runs fully offline with local Chinese-capable search, zero dependencies, and no accounts, API keys, or telemetry.11MIT
- AlicenseAqualityFmaintenanceLocal-first MCP memory server that gives AI coding agents long-term memory via SQLite and sqlite-vec, with optional LLM-powered layering. No gateway or API key required.7127 npm4MIT
- AlicenseAqualityAmaintenanceProvides AI coding tools with one local SQLite memory and rules store they can read over MCP, REST or the CLI, so facts, sessions and goals persist across sessions and shared rules are written into each tool's own instruction file. Runs entirely on your machine with no account, telemetry or network calls by default.4132,159 npm9Apache 2.0
- AlicenseCqualityAmaintenanceLocal-first, governable long-term memory for AI agents. Provides SQLite-backed storage, cross-session recall, and traceable memory corrections through a standard MCP interface.4019 PyPI1MIT
- AlicenseBqualityAmaintenanceSovereign, deterministic, local-first context and DAG lifecycle engine with native stdio MCP server for autonomous AI coding agents.23MIT
TDQS
Scored across 51 tools
Most tools are cleanly separated by domain prefix and verb. Minor overlaps exist: hb_api_probe vs hb_api_discover (probe-all-strategies vs schema auto-detect), and hb_mem_* vs hb_state_mem_* memory families could be confused by an agent. The many *_run/*_list/*_get tools are differentiated by their domain prefix, so ambiguity is limited.
Strong, predictable hb_<domain>_<verb> pattern across nearly all tools (hb_kb_search, hb_mem_store, hb_lock_check). A few deviations: hb_auto_list_chains inverts the order used by hb_auto_run/status/result, and accessors are inconsistently named hb_garden_get / hb_kb_get vs hb_ticket_show.
51 tools is well above the heavy threshold and far beyond what an agent can reliably select from in one session. The surface bundles at least a dozen separate domains (plugins, memory, routing, KB, swarm, state, garden, API, tests, connectors, automation, policy, tickets, locks), which should be split into focused servers.
Coverage is broad per domain but shallow: plugins have no install/enable, KB and garden lack update/delete, tasks have create/update but no delete, and policy/ticket tools are read-only by design. Read-only design is defensible, but the missing mutating operations leave lifecycle dead ends in several domains.