Skip to main content
Glama

List memories (no query)

memory_list
Read-onlyIdempotent

List stored memories with optional filters by type, scope, project, or vault folder. Ordered by recency or importance. Use to browse or enumerate memories before searching. Supports detail levels to control token cost.

Instructions

Browse stored memories with optional filters — ordered by recency/importance. Read-only. Use to enumerate by type/scope/project. Prefer memory_search whenever you have keywords (relevance ranking). Use the same detail levels to control token cost.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_pathNoOptional absolute project path filter. Empty string lists across all projects.
memory_typeNoOptional type filter (e.g. `decision`). Empty string returns all types.
scopeNoOptional scope filter — `project`, `global`, or `team`. Empty string returns all scopes.
pinned_onlyNoIf true, only return pinned memories.
limitNoMaximum number of memories to return (1-200). Default 20.
detailNoDisclosure level — `index` (cheapest), `summary`, or `full` (default). Drop to `index` when listing many rows to keep token cost down.full
include_file_memoriesNoIf true, also include markdown file-memory sources. Off by default since lists are usually about SQLite-backed memories.
vault_kindNoOptional vault subtype filter when listing vault notes.
vault_folderNoOptional vault subfolder filter (relative to vault root).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
detailYesDisclosure level used to render this list.
countYesNumber of SQLite/file memories returned.
memoriesYesListed memories ordered by recency/importance.
vault_resultsYesObsidian vault matches when the vault is enabled and `vault_kind`/`vault_folder` filters apply. Empty otherwise.
Behavior5/5

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

Declares 'Read-only' which aligns with annotations. Adds ordering by recency/importance and token cost considerations. No contradictions with annotations (readOnlyHint, destructiveHint, idempotentHint are all consistent).

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?

Three concise sentences front-loading the core action, then usage guidance, then sibling alternative and tip. No redundancy.

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 9 optional parameters (all with schema descriptions) and an output schema, the description covers purpose, when-to-use, behavioral traits, and parameter guidance sufficiently.

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 has 100% coverage, but description adds value by explaining the token cost trade-off for `detail` parameter and the role of filters. Slightly above baseline of 3.

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?

Explicitly states 'Browse stored memories' with optional filters, distinguishes from sibling `memory_search` by noting it's for enumerating without keywords, and title reinforces 'no query'.

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?

Provides clear when-to-use: 'Use to enumerate by type/scope/project.' and when-not: 'Prefer memory_search whenever you have keywords.' Also advises on token cost control via detail levels.

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/lfrmonteiro99/memento-mcp'

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