ellmos-homebase-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AGENT_ID | No | Fallback agent ID if HOMEBASE_AGENT_ID not set. | |
| PYTHONPATH | No | Path to the source directory when running from source. | |
| HOMEBASE_LANG | No | Language for the server (en, de, es, zh, ja, ru). | |
| HOMEBASE_CONFIG | No | Override the configuration file path. | |
| HOMEBASE_LOCALE | No | Alternative language setting (locale). | |
| HOMEBASE_AGENT_ID | No | Default agent ID used by modules. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| hb_mem_storeC | Store a fact, lesson, or working memory entry |
| hb_mem_queryC | Search memory by keyword |
| hb_mem_contextC | Generate compact context string for prompt injection |
| hb_mem_mergeB | Confidence-based merge of duplicate memories (dry_run previews; dry_run=false applies the merge) |
| hb_mem_consolidateA | Decay memory confidence and prune low-confidence entries (dry_run previews; dry_run=false applies) |
| hb_route_selectC | Analyze a prompt and recommend the best model/provider |
| hb_route_evaluateC | Rate a response for routing feedback loop (epsilon-greedy learning) |
| hb_route_statsC | Get routing statistics and learning progress |
| hb_kb_searchB | Full-text search in knowledge database |
| hb_kb_ingestC | Add new knowledge (text, URL, or file content) |
| hb_kb_getB | Get a single knowledge entry with metadata |
| hb_kb_listC | List tags in the knowledge base |
| hb_swarm_parallelC | Split task into chunks and process in parallel |
| hb_swarm_consensusC | Get majority vote from multiple independent agents |
| hb_swarm_hierarchyD | Boss-worker delegation pattern |
| hb_swarm_stigmergyC | Indirect coordination via shared state (blackboard pattern) |
| hb_state_mem_getC | Get state memory entries |
| hb_state_mem_setC | Store a state memory entry |
| hb_state_task_listC | List tasks with optional status filter |
| hb_state_task_createC | Create a new task |
| hb_state_task_updateC | Update a task (status, description, priority) |
| hb_state_dispatchC | Return connector-dispatch status |
| hb_garden_findC | Search the garden |
| hb_garden_getC | Get a specific entry by key |
| hb_garden_putC | Store or update an entry |
| hb_garden_runC | Run a stored command if execution is explicitly enabled |
| hb_api_probeC | Probe a URL using all strategies (OpenAPI, wordlist, pattern, HATEOAS) |
| hb_api_discoverC | Auto-detect API schema from a base URL |
| hb_api_exportC | Export probe results as Markdown or JSON |
| hb_api_historyC | List previous probe results |
| hb_test_listB | List available test batteries |
| hb_test_runC | Run a test battery or single test |
| hb_test_resultsC | Get results of last test run |
| hb_conn_listB | List configured connectors |
| hb_conn_sendB | Queue a message for a connector without network delivery |
| hb_conn_receiveB | Get recent local inbox messages for a connector |
| hb_conn_statusB | Check local connector health and queue counts |
| hb_auto_list_chainsB | List available local automation chain definitions |
| hb_auto_runB | Queue a local automation chain plan without executing external backends |
| hb_auto_statusB | Check local automation run status |
| hb_auto_resultC | Get the recorded local automation run result |
| hb_plug_listB | List discovered local plugins |
| hb_plug_infoC | Get local plugin metadata |
| hb_plug_runB | Record a plugin dry-run without executing plugin code |
| hb_plug_discoverC | Scan a local directory for plugin metadata |
| hb_policy_resolveC | Resolve the authoritative policy/rule/decision for a scope via the real policy-registry engine (read-only, canonical-only). |
| hb_policy_listC | List policy-registry entries (read-only, canonical-only), optionally filtered. |
| hb_ticket_listA | List tickets in one lifecycle category (INBOX/ACTIONABLE/QUEUED/BLOCKED/WAITING/USER/PARKED/SOLVED) -- header fields only, read-only. |
| hb_ticket_showB | Show one ticket's header fields by ID (e.g. T-20260825-196589547), read-only. |
| hb_lock_listA | List all currently active locks across configured roots (read-only). |
| hb_lock_checkA | Check whether a project directory currently has an active lock -- call this BEFORE any write action there (read-only). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
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.