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 targets a distinct resource and action: recall searches confirmed memory, get_context seeds a session, propose queues new memory, manage handles lifecycle by id/queue state, and say/board write and read the shared board. Descriptions explicitly cross-reference each other to resolve the few tempting confusions (recall vs get_context vs manage list_pending), so an agent can select reliably.
Names mix bare verbs (recall, propose, say, manage), a bare noun (board), and a verb_noun form (get_context), so there is no single predictable pattern. Every name is still readable and memorable, so the inconsistency is stylistic rather than harmful.
Six tools is well matched to a memory server with a shared board: one each for search, session seeding, proposal, lifecycle management, board write, and board read. No tool looks redundant and none of the needed operations are crammed together beyond manage's clearly enumerated actions.
The memory lifecycle is well covered end to end: propose, discover via recall/get_context, review pending, read by id, soft-delete with restore, and discard. The main gaps are the absence of any way to edit a pending or confirmed entry's content and no richer board operations (e.g., replying to or addressing a specific message), which agents can mostly work around.