Tirith

Official

Overview Schema Source Related Servers Discussions Admin

memory_read

Read-only

Read a full memory note by permalink, id, or title, optionally including linked notes up to 3 hops deep. Use after search to get complete content and context.

Instructions

Read one memory note in full by permalink, id or exact title. It is the only tool that returns a note's body; depth 1 to 3 adds the notes linked to it, as digests. Use after memory_search or a claim's brief names the note; to find notes use memory_search. not_found if there is none.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	A permalink, an id, or an exact title.
`agent`	Yes	Your stable agent name.
`depth`	No	How many relation hops of related notes to include, 0 to 3.

Output Schema

TableJSON Schema

Name	Required	Description
`note`	No	The whole note, body included: id, permalink, title, kind, body, observations, relations, paths, tags, author, updated_by, created_at, updated_at.
`status`	Yes	ok. not_found: no such note. invalid: depth above 3.
`message`	No	Human-readable detail, on most outcomes other than ok.
`related`	No	With depth above 0, at most 20 linked notes as digests: permalink, title, kind, paths, tags, updated_at, and a 160-character excerpt.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.1.2Sep 18, 2026

addedInput schema / properties / agent / description
```
Added value: +"Your stable agent name."
```

addedInput schema / properties / depth / description

Added value: +"How many relation hops of related notes to include, 0 to 3."

addedInput schema / properties / name / description

Added value: +"A permalink, an id, or an exact title."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "description": "Any result may also carry lost, inbox, inbox_more and persist_error; see guide.",
+  "properties": {
+    "message": {
+      "description": "Human-readable detail, on most outcomes other than ok.",
+      "type": "string"
+    },
+    "note": {
+      "description": "The whole note, body included: id, permalink, title, kind, body, observations, relations, paths, tags, author, updated_by, created_at, updated_at.",
+      "type": "object"
+    },
+    "related": {
+      "description": "With depth above 0, at most 20 linked notes as digests: permalink, title, kind, paths, tags, updated_at, and a 160-character excerpt.",
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "status": {
+      "description": "ok. not_found: no such note. invalid: depth above 3.",
+      "enum": [
+        "ok",
+        "conflict",
+        "not_found",
+        "none",
+        "invalid",
+        "cancelled"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "status"
+  ],
+  "type": "object"
+}

First observedv1.1.1Sep 18, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value beyond that by disclosing the depth behavior ('depth 1 to 3 adds the notes linked to it, as digests') and the error case ('not_found if there is none'), which are genuine behavioral traits not derivable from the annotations or schema alone.

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?

Four sentences with the core action front-loaded in sentence one, followed by scoping, usage routing, and error behavior. Each sentence earns its place; slightly denser than strictly necessary but no wasted words.

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?

Complete for a read tool: output schema covers return values, annotations cover safety, all parameters are documented, the usage sequence is specified, the depth semantics are clarified, and the not_found failure mode is disclosed. Nothing an agent needs to call it correctly is missing.

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 coverage is 100%, so the baseline of 3 applies — the schema already documents name, agent, and depth. The description adds a small increment by clarifying that depth returns linked notes 'as digests,' but it largely restates the name parameter's meaning in the first sentence.

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 and resource ('Read one memory note in full') plus the identification methods (permalink, id, or exact title). It also differentiates from siblings by asserting 'It is the only tool that returns a note's body,' which cleanly separates it from memory_search.

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?

Explicitly names the sequence and the alternative: 'Use after memory_search or a claim's brief names the note; to find notes use memory_search.' This tells the agent exactly when this tool is appropriate versus its sibling, leaving nothing to inference.

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