Skip to main content
Glama

get_memory

Read-onlyIdempotent

Retrieve a specific memory by ID to inspect its content, encoding time and place, tags, salience, metadata, and sensory details before editing or forgetting it.

Instructions

Read one memory by id (as returned by remember, recall, sense or pending_recollections): its content, when and where it was encoded, tags, salience, metadata and which senses it was recorded with. Use it to look at a specific memory before editing or forgetting it; to search by content, place or time use recall instead. No side effects. Returns the memory as JSON, or an error if no memory has that id.

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": {
      "memory_id": "<memory_id>"
    },
    "name": "get_memory"
  }
}

Input Schema

NameRequiredDescriptionDefault
memory_idYesThe memory's id (e.g. 'mem_0189a3f2c1d4_9f3c2a7b1e').

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is largely covered. The description nonetheless adds value by stating there are no side effects, that the result is JSON, and that an error is returned when the id does not exist. It does not discuss failure modes beyond a missing id, so it is not fully comprehensive.

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 definition is two tight sentences: the first leads with the core action and payload, the second handles usage, return shape, and the not-found case. No sentence is filler, and the primary purpose is front-loaded.

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?

For a single-parameter read tool with no output schema, the description covers the returned fields, the error behavior, and the sibling alternative. Nothing an agent needs to call it correctly or interpret the response 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 single memory_id parameter is already documented with an example format. The description goes further by explaining the id's provenance — that it comes from remember, recall, sense, or pending_recollections — which tells the agent where to obtain a valid value, something the schema does not say.

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 and resource (read one memory by id) and immediately enumerates what is returned: content, encoding time/place, tags, salience, metadata, and senses. It explicitly separates itself from the recall sibling for content/place/time searching, so an agent can pick the right tool without opening a 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?

It gives an explicit when-to-use case (inspect a specific memory before editing or forgetting it) and names the alternative for a different need (recall for search by content, place, or time). Both the positive and negative routing conditions are stated.

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