cogmem
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| recallA | Surface the most relevant past lessons, decisions, and rules for a task, ranked by semantic similarity.
Returns {count, memories:[{id, scope, score, text}]}, where score is rerank confidence (higher = more relevant).
Use at the start of a task or whenever unsure how the user wants something done, instead of guessing. Read-only — to save a new memory use |
| noteA | Record a decision, finding, or correction into memory mid-task so it can be recalled in future sessions.
Returns {ok, noted}. The text is captured as a candidate and deduped against existing knowledge by the background pipeline.
Use when the user states a durable preference or you learn something worth keeping; not for transient chatter. To retrieve memories use |
| statusA | Report the health of the verifiable-memory system.
Returns {agentDid, logEntries, logIntegrity, merkleRoot} — the agent's did:key identity, transparency-log size, its integrity ('ok' or a reason), and the current Merkle root.
Use for a fast health/identity check. For a full per-memory credential audit use |
| verifyA | Cryptographically verify every stored memory's W3C Verifiable Credential and the integrity of the hash-chained transparency log.
Returns a summary of memories checked, how many are valid, and any failure reasons.
Use to detect tampered or poisoned memories before trusting them. This is the deep audit; |
| receiptA | Produce an RFC 6962-style cryptographic proof that a specific memory is committed in the signed transparency log.
Returns the inclusion receipt (leaf index, audit path, tree size, signed root).
Use to prove to a third party that a memory existed and was logged. Requires the memory's id — get ids from |
| tree_headA | Return the current signed Merkle tree head — the log's tamper-evident commitment to every memory so far.
Returns {rootHash, treeSize, signature, ...}.
Use as the anchor a verifier checks inclusion receipts against, or to detect log forks. Pair with |
| progressA | Summarize momentum, stalls, and dependencies across the user's projects as a narrative. Returns {narrative}. Use to orient at session start or when the user asks 'where are we'. Read-only synthesis of project-state memory. |
| review_pendingA | List always-load (Layer-A) rules awaiting human approval before they enter the always-on context.
Returns {pending}.
Use to see what the system wants to promote. Approval itself is a human action via the |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| User model | cogmem's evolving model of the user |
TDQS
Scored across 8 tools
Each tool has a clearly distinct purpose: note saves memories, recall retrieves them, progress summarizes project state, receipt provides cryptographic proofs, review_pending lists pending rules, status reports system health, tree_head returns the Merkle root, and verify performs deep audit. No overlapping functionality.
All tool names are lowercase with underscores for compounds (e.g., review_pending, tree_head). They follow a consistent pattern of verbs or noun phrases that clearly indicate the action or output, with no style mixing.
With 8 tools, the set is well-scoped for a verifiable memory system. It covers storing, retrieving, verifying, and monitoring without being bloated or too sparse.
The tools provide core operations (create, read, verify, audit). Missing explicit update/delete tools is a minor gap, but this aligns with the system's append-only, tamper-evident design. A tool for exact-match retrieval could be useful, but semantic recall covers most needs.