Skip to main content
Glama

memory_visual

Render a deterministic Mermaid diagram of the memory store—choose dag, relations, tiers, or sessions view to inspect blocks, edges, lifecycle, or activity.

Instructions

Render the store as ONE deterministic Mermaid diagram (a generated view — nmemory writes no files; the caller pastes the string returned under the response's mermaid key into any mermaid renderer). view is a CLOSED set: "dag" projects the blocks-dag as graph TD — ready (zero live blockers), blocked, and done nodes each styled distinctly; blocks-edge participants only, superseded/tombstoned capsules dead to it (they vanish); a WITNESSED participant is DONE (u-r3: proof-carrying closure — styled distinctly and KEPT in the graph since it stays live and recallable, unlike a dead node); FAIL-CLOSED on a live blocks-cycle among non-done members EXACTLY like memory_digest — the diagram renders ONLY the concrete cycle members plus a fail-closed banner (repair: supersede, forget, or witness a member, then re-digest), never a partial healthy graph. "relations" projects every edge as graph LR, one arrow per relation kind with the kind as the edge label, in memory_export's ## relations order (kind rank, then from, then to). "tiers" groups capsule ids by effective lifecycle tier (active/archived/quarantined) as a flowchart, each node annotated with the SHARED first-line headline (~140 chars, …-terminated when cut). "sessions" projects the exact store-local BINARY union of bracket rows, capsule labels, and grounded recall-receipt labels as a flowchart TD: capsule ROWS are saves (including retained tombstone skeletons), receipt ROWS are recalls (never returned_ids), local brackets are open/closed, and a label with no local bracket is label only. Local brackets order by started_at then exact label; label-only rows follow in exact BINARY label order. Merge-imported labels remain label only unless they collide with a local bracket, in which case matching capsule counts aggregate under that local state. Determinism: byte-identical across two calls on the same store — the view carries NO timestamp, and a leading %% provenance comment pins counts plus a body sha256 over the diagram statements (memory_export's precedent), so regeneration of an unchanged store reproduces it and any hand edit breaks the sha. Syntax safety: capsule ids are safe identifiers, and headlines are entity-encoded so no stored byte (quotes, brackets, pipes, newlines, unicode) can break the diagram. Session node ids are ordinals; before Mermaid entity encoding, session labels receive an injective visible escape: literal backslashes double and controls/U+2028/U+2029 become uppercase minimal \u{HEX}; no raw control reaches Mermaid and exact labels never collapse. project_prefix applies ONLY to view=tiers — it fences the capsule set to a subtree (exact id or id + "/...") exactly like memory_digest's capsule sections (an empty or "/"-terminated prefix is rejected with a teaching error rather than answering an empty diagram). view=dag, view=relations, and view=sessions are STORE-GLOBAL exactly like memory_digest and take NO fence: a project_prefix passed with any of them is REJECTED with a teaching error, never silently ignored. That is what makes the fail-closed-on-cycle law hold UNCONDITIONALLY on the dag view — a live blocks-cycle ALWAYS collapses to the concrete cycle members + banner, never a partial healthy graph, no matter the prefix. Read-only, ADVISORY_NOT_AUTHORITY DATA: a generated view, never an authority surface.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
viewYesWhich projection to render — closed set `dag` | `relations` | `tiers` | `sessions`.
project_prefixNoOptional subtree fence honored ONLY by `view=tiers` (the capsule-set view), exactly like `memory_digest`'s capsule sections (exact id or id + `/...`; an empty or `/`-terminated prefix is rejected with a teaching error). `dag`, `relations`, and `sessions` are STORE-GLOBAL like `memory_digest` and take no fence: a prefix passed with any of them is rejected by the handler, never silently ignored.
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: deterministic generation, no timestamp, syntax safety, node id handling, read-only advisory nature, and failure modes. This is comprehensive.

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?

The description is dense and front-loaded with purpose, but the length is justified given the complexity. Every sentence provides important detail, though it could be slightly more concise.

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

Completeness5/5

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

Given two parameters, no output schema, and no annotations, the description covers all aspects: view behaviors, parameter constraints, failure modes, determinism, and safety. It leaves no significant gaps.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds significant meaning: it explains how project_prefix works, allowed views, and edge cases (rejection of invalid prefixes). This enriches understanding beyond the schema alone.

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?

The description clearly states it renders the store as a deterministic Mermaid diagram, listing four distinct views (dag, relations, tiers, sessions) with specific behaviors. This differentiates it from siblings like memory_digest or memory_export.

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?

The description explains when to use each view and explicitly states that project_prefix only applies to tiers and is rejected for others. It also mentions fail-closed behavior for cycles, but lacks explicit guidance on choosing this tool over alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/menot-you/n-memory'

If you have feedback or need assistance with the MCP directory API, please join our Discord server