Skip to main content
Glama

memory_list

Lists every memory in a specified project scope, providing the total count and source breakdown. Use to audit the full inventory and verify if specific memories still exist.

Instructions

List every memory in a scope, with counts and source breakdown.

Use this when you want to see the full inventory of what Cortex has stored — e.g. to audit which projects have the most memories, to check if a specific memory you wrote earlier is still present, or to find a memory whose exact title you remember but whose keywords are ambiguous.

Behaviour:

  • Read-only. No mutations at all, not even telemetry bumps.

  • No authentication required.

  • No rate limits. Latency scales linearly with memory count; typical sub-second on corpora up to ~10k.

  • Data access scope: reads ~/obsidian-brain/cortex/memories/ markdown files via filesystem glob. Nothing leaves the machine.

  • Idempotent and deterministic for a given filesystem state.

  • Failure modes: returns "No memories in scope: " for an empty scope. Never raises.

Use memory_list when:

  • You want to see everything, not a ranked subset

  • You need to audit the current memory inventory

  • You're about to run a cleanup/purge operation and want a preflight

  • You suspect memory_recall is missing something and want to confirm

Do NOT use for:

  • Searching for specific content (use memory_recall — faster, ranked)

  • Assembling a context briefing (use context_assemble)

Returns: A markdown listing with the total memory count, source type breakdown (mined/user/import), and one line per memory showing its short ID, title, and project. Memories are sorted newest-first by creation date.

Example output: 47 memories Sources: mined:32, user:12, import:3

- [63d6570e] JWT algorithm — RS256 only in prod | project:my-webapp
- [a8b12c44] Pytest fixtures must use tmp_path | project:default
- ...

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scope_idNoProject scope to list. "default" lists every memory across all projects. A specific project name lists only memories tagged with that project.default

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Provides extensive behavioral details: read-only, no auth, no rate limits, linear latency, filesystem access scope, idempotency, failure modes. No annotations provided, so description carries full burden and exceeds it.

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?

Well-structured with clear sections. Front-loaded with purpose and usage. Every sentence adds value. Appropriate length for the complexity.

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?

Covers all aspects: purpose, usage guidance, behavioral transparency, parameter semantics, output format with example. Complete for a simple tool with one optional parameter.

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% and description adds meaning: clarifies default scope lists all projects, specific project name filters. The extra context elevates beyond baseline.

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?

Clearly states the tool lists memories in a scope with counts and source breakdown. Differentiates from siblings like memory_recall and context_assemble. Describes specific use cases.

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 states when to use (audit, check existence, preflight for cleanup) and when not to (searching, context briefing) with alternative tool names. Provides clear guidance.

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/TT-Wang/memem'

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