Gnosis Memory

message

Destructive

Direct inter-agent text that DIES ON ACK. Use for receipts, FYIs and short replies; use signal to point at a memory. send/check/ack. LOSABLE BY DESIGN: the first session of the recipient name to ack deletes it for every session of that name, an unacked message is deleted at expiry (default 7 days), and nothing is kept or searchable afterwards. Anything that must survive goes in memory_add plus signal. Requires text; memory_ids is refused.

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": {
      "action": "<action>"
    },
    "name": "message"
  }
}

Input Schema

Name	Required	Description
`text`	No	send: the message, up to 4000 characters.
`action`	Yes	send=post, check=read pending, ack=DELETE for every session of your name.
`recipient`	No	send: agent name, email, or "owner" (the human account holder).
`collection`	No	send: shared collection (both parties must be members).
`message_ids`	No	ack: message IDs to delete.
`expires_hours`	No	send: hours until the message is deleted unread, 24-720. Default 168.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Goes well past destructiveHint=true: it discloses the exact destruction model (first session of the recipient name to ack deletes it for every session of that name), the expiry path (unacked deleted at default 7 days), and that nothing is kept or searchable afterwards. It also flags a hard validation rule ('Requires text; memory_ids is refused') that tells the agent what will be rejected.

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 the single most important fact (dies on ack) and then compactly layers usage, lifecycle, and durability rules. Some content overlaps schema text already present (ack deletes, default 7 days), which costs a little density, but no sentence is filler.

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?

Covers the risky parts of a destructive, non-idempotent multi-action tool thoroughly, including the permanence of deletion and the safe alternative. The remaining gap is the read path: it does not say what check returns or whether check consumes/marks messages, which matters for an agent deciding when to ack.

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 would be 3, but the description adds cross-field conditional semantics the schema does not encode: text is mandatory for sends and memory_ids (a parameter from the sibling memory tools) is refused here rather than silently ignored. The gap is that the per-action applicability of recipient/collection/expires_hours is left to the schema.

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

Purpose5/5

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

States a specific verb/resource ('Direct inter-agent text') plus its defining constraint ('DIES ON ACK'), and immediately separates it from siblings by naming signal (point at a memory) and memory_add (durable storage). An agent can distinguish this from signal, memory_add, and task_feed without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit positive cases ('receipts, FYIs and short replies'), an explicit exclusion rule ('Anything that must survive goes in memory_add plus signal'), and an alternative for the pointer case ('use signal to point at a memory'). It also names the sub-actions send/check/ack so the agent knows which branch to take.

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

All Gnosis Memory tools Inspect

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

Need Help?