OnlyMCP

Walk the memory graph

memory_graph

Read-only

The graph around one memory file, up to three hops. Depth 1: the files, skills, agents and servers it links to or is linked from, its folder, type, project and tags, and links that land on nothing (→ links to (missing) name). From depth 2 on only links out of a file reached by a link are followed: a backlink, folder, type, project or tag is listed at depth 1 and never walked through. Pick the depth yourself; 1 is the default and usually enough, 2-3 follow a chain of links further, the files most of the previous depth links to first. Grouped by depth; each line names the edge (→ links to, ← linked from, → has type ...) and, from depth 2, the node it was reached through. types, folder and project narrow what is listed, not the walk.

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": {
      "path": "<path>"
    },
    "name": "memory_graph"
  }
}

Input Schema

Name	Required	Description
`path`	Yes	Path of the memory file to start from.
`depth`	No	Hops to walk, 1 to 3. Default 1.
`types`	No	Comma-separated node kinds to list: memory, skill, agent, mcp, tool, folder, type, project, tag, collection.
`folder`	No	Only memory files and folders under this folder (full path, or its last part).
`project`	No	Only nodes about this project (and the project itself).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 11, 2026
- addedInput schema / properties / depth / maximum
```
Added value: +3
```
- addedInput schema / properties / depth / minimum
```
Added value: +1
```
- changedInput schema / properties / depth / type
```
Previous value: -"string"New value: +"integer"
```

Changed1 schema field changedNov 11, 2026

changedInput schema / properties / folder / description

Previous value: -"Only memory files and folders under this folder."New value: +"Only memory files and folders under this folder (full path, or its last part)."

AddedNov 11, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations only cover read-only and closed-world safety, while the description adds substantial behavioral detail: backlinks, folder, type, project and tag edges are listed at depth 1 but never walked through, missing targets are rendered as "→ links to (missing) name," and output is grouped by depth with each line naming its edge and origin node. With no output schema present, this return-format disclosure carries the full burden and does so.

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 purpose is front-loaded in the first sentence and the depth rubric follows in the order an agent would reason about it. The second sentence is long and clause-heavy, but nearly every clause adds a distinct rule that would otherwise cause a wrong call.

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 read-only traversal tool with no output schema, the description supplies depth semantics, filtering semantics and the shape of returned lines, which is most of what an agent needs. It omits practical bounds such as how large a three-hop result can get, but nothing essential for a correct invocation is missing.

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 meaning the schema does not: it clarifies that depth 2+ only follows outbound links from link-reached files, and explicitly states that types, folder and project "narrow what is listed, not the walk" – a non-obvious scoping constraint on three of the five parameters.

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 graph around one memory file, up to three hops" names the specific resource and the traversal operation in one clause, and the depth explanation makes clear this is a graph walk rather than a plain link list. It does not name a sibling such as memory_links to draw the boundary explicitly, so it falls short of a 5.

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 gives real selection guidance for the depth parameter: "1 is the default and usually enough, 2-3 follow a chain of links further," plus the note that filters narrow the listing rather than the walk. It stops short of stating when to prefer this over a sibling tool, so it is clear context without explicit alternatives.

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

All OnlyMCP tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?