hive-memory
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HIVE_MCP_URL | No | Hive MCP endpoint. Defaults to http://127.0.0.1:8768/mcp. | http://127.0.0.1:8768/mcp |
| HIVE_AGENT_ID | Yes | Agent id issued by your own Hive. | |
| HIVE_AGENT_TOKEN | Yes | Access token issued when the agent was registered. Keep it secret. |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| recallA | Search the human's confirmed memory by natural-language query and return the closest stored entries. Use this to find what was previously decided, recorded, or agreed. Do not use it at session start when you have no query yet - use get_context instead. Do not use it to review entries still awaiting approval - use manage with action list_pending. Annotations already declare this read-only, so this text covers what they cannot: results come from the confirmed store only, private vaults are omitted for agents not permitted to read them, and an empty list means no match rather than no memory. |
| proposeA | Submit a memory for the human to approve. It lands in a pending queue and changes no confirmed memory. Use it when the human says to remember something, or when a decision is reached that will still matter later. Do not use it as a scratchpad for transient reasoning or for data you merely fetched. This tool cannot confirm its own writes: the entry stays pending until the human accepts it inside their own Hive, so a success response means queued, not stored. Supply client_id to make retries idempotent. |
| manageA | Inspect or change the lifecycle of a specific stored memory, addressed by id or by queue state. Use list_pending to review what is awaiting the human's approval, and get_by_id to read one entry in full. forget soft-deletes and is reversible with restore; discard_pending permanently drops an entry that was never confirmed. To search confirmed memory by topic instead of by address, use recall. Except for discard_pending, every action here is reversible, which is why this is not marked destructive. |
| get_contextA | Pull a short digest of recent memory from the human's active threads and open tasks, to seed a conversation before they ask anything. Call this once at session start. For answering a specific question, use recall instead, since that searches all confirmed memory rather than only what is recent. For entries still awaiting approval, use manage with action list_pending. Annotations already declare this read-only; what they cannot say is that the digest reflects the most recent activity, so two calls minutes apart may differ. |
| sayA | Post a message to the shared board so the human and other agents see what was done or what is being handed over. Use it when finishing a unit of work, or to hand work to another agent. Do not use it to report routine steps the human did not ask about - the human reads this board. To read what others have posted, use board. Identity comes from your credential, so a caller cannot post as another agent. |
| boardA | Read the shared board, optionally only what arrived since your last read. Use it to poll for messages or hand-offs addressed to you. To post, use say. Pass the previous cursor as since so a poll returns only new messages instead of the whole board. Annotations declare this read-only; note that messages expire, so an empty result can mean nothing was posted or that earlier messages have aged out. |
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 6 tools
Each tool has a clearly delineated role, and the descriptions actively resolve boundary cases (recall vs get_context vs manage list_pending; say vs board; propose vs manage). No two tools compete for the same action, so misselection is unlikely.
Names are uniformly short and lowercase, but the style is slightly mixed: mostly bare verbs (recall, propose, manage, say) alongside a verb_noun (get_context) and a bare noun (board). It remains readable and predictable in tone, just not a strict single pattern.
Six tools cleanly cover the memory lifecycle plus agent communication, with no redundant or filler entries. Each tool earns its place for a focused memory server.
Full read/create/pending-inspect/soft-delete/restore lifecycle is present, plus session bootstrap and a messaging channel; no dead ends in the core flow. The one visible gap is revising the content of an already-confirmed memory (only forget/restore, not edit), which agents must work around via propose.