Skip to main content
Glama
ellmos-ai

ellmos-homebase-mcp

Official
by ellmos-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Related Servers

Alternatives to ellmos-homebase-mcp

No user-submitted related servers found.

    Related Servers

    • nuzo-memory

      fabionfsc
      A
      license
      Not graded
      quality
      F
      maintenance
      Local-first, auditable memory for AI agents. Provides durable context for MCP hosts with SQLite storage, CLI, and MCP tools for memory management.
      2
      Apache 2.0

    • tdai-memory-mcp

      tinhien11
      A
      license
      A
      quality
      F
      maintenance
      Local-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.
      7
      131 npm
      4
      MIT

    • CP Memory

      CJhuochai
      A
      license
      C
      quality
      A
      maintenance
      Local-first, governable long-term memory for AI agents. Provides SQLite-backed storage, cross-session recall, and traceable memory corrections through a standard MCP interface.
      40
      25 PyPI
      1
      MIT

    • MEMGRAPH-MCP

      MikeB317
      F
      license
      A
      quality
      D
      maintenance
      A durable multi-agent orchestrator for software development with explicit run graphs, checkpoint/resume capabilities, and project memory exposed through MCP resources and tools. It enables coordinated agent workflows for coding, review, repair, CI, and approval with SQLite-backed memory retrieval and pluggable research backends.
      10
      -
    Deploy Server
    One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

    TDQS

    C2.7/5.0

    Scored across 51 tools

    Disambiguation4/5

    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.

    Naming Consistency4/5

    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.

    Tool Count2/5

    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.

    Completeness3/5

    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.

    Maintenance

    ActivityActive
    ResponsivenessNo issues

    Resources