Mnemoverse Memory

memory_graph

Read-onlyIdempotent

Reads the association edges around given concepts: which concepts the memory has linked together, with each link's weight, outcome valence and co-activation count. Use to inspect what a memory store has learned or to explain why a read expanded to a concept. Read-only.

Input Schema

TableJSON Schema

Name	Required	Description
`depth`	No	Hops to expand from the seeds (1-3, default 1). At depth 2 or 3, if min_weight is omitted the engine floors edge weight at 0.05 at EVERY hop — including the first — so a hub concept cannot fan out across the whole store before limit applies; pass min_weight explicitly (0 included) to see every edge anyway.
`limit`	No	Max edges to return (1-500, default 100 — mirrors memory_read's top_k bounds).
`seeds`	Yes	Concepts to center the graph on (1-20, each ≤200 chars, non-blank) — e.g. ['deploy', 'staging']. An unrecognised concept simply contributes no edges; it is not an error.
`domain`	No	Read a shared room's graph instead of your own: pass that room's address (e.g. 'xroom:room_01ABC'). Find room addresses with memory_list_rooms. Unlike memory_read, any OTHER value has no effect here — the association store has no domain column, so a plain domain name behaves exactly like omitting this field.
`min_weight`	No	Only include edges at or above this weight (≥ 0). Omit for no floor at depth 1; at depth 2/3 the engine applies its own 0.05 floor when this is omitted (see depth) — pass 0 to see every edge at every depth.

Output Schema

TableJSON Schema

Name	Required	Description
`edges`	Yes	Association edges found within the requested depth.
`nodes`	Yes	Concepts touched by edges below. A seed with no surviving edge (unrecognised concept, or every edge fell below the weight floor) is not listed.
`truncated`	Yes	True when a per-hop server cap or limit cut the walk short — the store may hold more edges than are reported here.
`min_weight_applied`	Yes	The weight floor actually used at every hop: your min_weight when you set one (0 included); otherwise 0.05 from depth 2, or 0 at depth 1.

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 27, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the explicit 'Read-only' adds no new safety information. The description does add scoping context (edges around given concepts) and the returned edge attributes, but deeper behavioral quirks such as depth-based weight flooring and the domain no-op live in the schema rather than the description.

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

Conciseness5/5

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

The description is two tight sentences that front-load the core operation and then state concrete use cases. The trailing 'Read-only' is redundant with annotations but negligible, and there is no filler.

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?

Between the rich schema documentation, the output schema, and the annotations, an agent has everything needed to call this tool correctly. The description supplies the conceptual purpose and use cases without needing to repeat return-value details.

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

Parameters3/5

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

Schema description coverage is 100%, with all five parameters fully documented including defaults, bounds, and special cases. The tool description does not add parameter-level meaning, so the baseline 3 applies.

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 names a specific verb ('Reads'), a specific resource ('association edges around given concepts'), and the concrete output fields (weight, outcome valence, co-activation count). It is clearly distinct from siblings like memory_read by focusing on the graph structure rather than raw memory entries.

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 second sentence gives concrete use cases: inspecting what a memory store has learned and explaining why a read expanded to a concept. It does not explicitly name alternatives or state when not to use this tool, so it falls just short of a 5.

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

All Mnemoverse 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.