Skip to main content
Glama
Sign In

Gnosis Memory

by com.gnosismemory
OverviewDiscussionsAdmin

memory_add

Store a memory. Several memories in one call -> memories=[{content, topics, ...}]; top-level topics then apply to every item.

BEFORE params decide: (1) TYPE? (2) what search finds this later? (3) happened, or aspirational? (4) WHO must act on it?

TYPE by example: "User prefers dark mode" -> preference "Team chose JWT for auth" -> decision "Config at /etc/app.conf" -> path "Wants to install Windsurf" -> task + topic "aspirational" "API limit 1000/min" -> fact

ADDRESSING: a memory FOR someone is delivered ONLY by signal -- topics/names in content deliver to NO ONE. another agent -> signal:"" (or "owner") your own next session -> signal:""

content: atomic, front-loaded, self-contained. Sentence 1 = subject + WHY, stands alone (it IS the search preview). Present tense. GOOD "User prefers Python backend -- type safety catches bugs early" BAD "Prefers Python" (no subject, no why) BAD "Type safety is why the user picked Python" (subject buried, not front-loaded) Durable output, not scratchpad: no conversation context, no superlatives -- wrong memories poison future retrieval permanently.

topics: words you would SEARCH, not categories. GOOD [docs, api, express] BAD [documentation, path, local]

aspirational (not yet done/built/tried) -> add topic "aspirational", else it reads as fact later. GOOD "Bakes sourdough weekly" -> fact BAD "Wants to try croissants" -> +aspirational

path -> name WHAT lives there. GOOD "Chat backend at /opt/api -- Express+Socket.io" BAD "Workspace at /opt/api"

preference -> first topic "user". +topic "behavioral" = auto-loaded every session.

task -> title + steps[] (milestones, not to-dos), or content with "- [ ]" lines. summary = state/blockers. task_done when all steps complete.

format: topics + macro_topics = single lowercase words; split compounds (bug_fix -> bug, fix).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "topics": "<topics>"
    },
    "name": "memory_add"
  }
}

Input Schema

NameRequiredDescriptionDefault
refNoParent task/ticket id -> auto-added to topics. e.g. "a1b2c3d4", "GH-142".
typeNofact=knowledge, preference=user pattern, decision=choice+reason, path=location, task=actionable, task_done=complete, result=an output or finding.
forceNoSkip dup check. Testing only.
stepsNoTask checklist -> "- [ ]" boxes. Requires title.
titleNoTask title (structured). Requires type="task". Not with content.
signalNoAlso signal recipient (email, agent, "owner"). Needs a SHARED collection ("me"/personal rejected up-front — nothing stored).
statusNoInitial task status. Default pending.
topicsYesREQUIRED. Then the specific search keywords: single lowercase, no _ or -. First = "user" for preferences. Not macro_topics.
contentNoMemory text — plain prose only, never a serialized object. topics, macro_topics and type are their OWN parameters; put them there, never inside this text. Self-contained: subject + why, front-loaded. e.g. "User prefers Python backend -- catches bugs early with type hints"
summaryNoTask prose: state/blockers/decisions -> "## Summary" block. type task/task_done. Not type="summary" (that is memory_consolidate).
artifactNoCommit SHA or filename -> auto-added to topics. e.g. "f4e5d6c", "oauth.py".
memoriesNoSeveral memories at once: each item takes the same fields as this call (content, topics, type...). Top-level topics/macro_topics are added to every item.
ephemeralNoAuto-expire 90d.
collectionNoShared collection by name. Omit=default. "me"/"personal"/agent name=own namespace; "owner"/"parent"=account primary (member-gated).
expires_atNoYYYY-MM-DD, or "never". Overrides ephemeral.
macro_topicsNoThe project or domain this memory is ABOUT — decide this first. 1-3 lowercase (e.g. gnosis, magi). Optional, but it almost always applies: use it when the memory belongs to a named project; it keeps the label out of the content instead of "GNOSIS: ...". Searched exactly like topics. An empty one is fine and is not an error.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only give the generic mutation profile (readOnly=false, destructive=false, idempotent=false); the description adds the consequential details: a duplicate check exists and `force` bypasses it, signal is the ONLY delivery path to another agent (topics/names in content deliver to no one), shared collections are required for signal or nothing is stored, and bad memories "poison future retrieval permanently." That is real behavioral context an agent cannot infer from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and batch syntax, then organized into labeled blocks (TYPE, ADDRESSING, content, topics, path, preference, task) with GOOD/BAD contrast pairs that are easy to scan. It is long and repeats some content-style rules that also appear in the `content` and `topics` schema descriptions, costing it a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter tool this covers the hard parts: the type taxonomy, addressing/delivery, content quality, topic formatting, and task workflow (steps, summary, task_done). The notable gap is response shape — there is no output schema and the description never says what is returned (e.g., a memory id or dup-check outcome), which an agent needs to chain a follow-up edit or delete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description goes beyond it by explaining what topics should look like (search words, not categories), why macro_topics is decided first, the aspirational-topic convention, and the fact that signal requires a shared collection. These are semantic rules the schema states only tersely.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening verb+resource ("Store a memory") is unambiguous and the body distinguishes subtypes from memory_consolidate ("Not type=\"summary\" (that is memory_consolidate)"). However, it never names the sibling memory_add_batch, instead folding batch behavior into a `memories` param, so an agent cannot cleanly tell which of the two batch paths to pick from the description alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Strong decision scaffolding: the "BEFORE params decide" checklist forces type/searchability/fact-vs-aspirational/recipient reasoning, and the TYPE-by-example table maps real utterances to enum values. It stops short of explicit when-NOT guidance and doesn't route to memory_search/memory_edit/memory_add_batch as alternatives, which keeps it below a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Gnosis Memory toolsInspect
Try in Browser
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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources