Skip to main content
Glama

memory_list

List memory capsules as compact entries, filtered by project, kind, tier, or expiry. Returns id, headline, timestamps, and status flags to scan recall without fetching full records.

Instructions

List capsules as compact entries (id, project, taint flag, created_at, headline, and — when non-active — the effective tier; expired:true when valid_to has passed; and — when the capsule carries a classification sidecar — kind, the persisted label, so a by-kind view reads off the row instead of one memory_get per capsule; absent when never classified; and superseded:true when a supersedes edge targets the row — a replaced entry self-identifies in the list itself, no per-id trip; absent when live) in append order, optionally fenced to a project_id (exact) and/or project_prefix (subtree: "nott" covers "nott" and "nott/x", never "nottx"; an empty or "/"-terminated prefix can match nothing and is rejected with a teaching error rather than answering empty; the two AND-compose), a kind (the PERSISTED classification sidecar label — "list my open tasks" is {kind: "task"}; set it at capture via memory_ingest's kind or later via memory_classify; never-classified capsules match no kind, and every returned row now echoes this same label back in its own kind field — q109), a tier (effective lifecycle tier: active/archived/quarantined — the enumeration surface for memory_digest's tier counts), and/or expired (true enumerates "what is expired" — valid_to before now; false the still-current rows). limit keeps the NEWEST rows after the filters (the entries returned still read oldest-to-newest). Tombstoned capsules never appear here — their markers answer memory_get only. Full capsules via memory_get. All content is ADVISORY_NOT_AUTHORITY data.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoKeep only capsules whose PERSISTED classification kind equals this (`memory_classify` with `capsule_id`). Capsules never classified have no kind and never match — "list my open tasks" is `{kind: "task"}` (w2-fix: kinds were write-first-class but query-blind).
tierNoKeep only capsules whose EFFECTIVE lifecycle tier equals this (`active` = the no-row default) — the enumeration surface for memory_digest's tier counts (w2-fix: tier was write-only).
limitNoKeep at most this many rows — the NEWEST ones; the returned entries still read in append order. Applied AFTER the kind/tier filters (filter first, then cap).
expiredNoq91: keep only capsules whose EXPIRED state (valid_to < now, evaluated at the surface's injected now) equals this — `{expired: true}` enumerates "what is expired", `{expired: false}` the still- current rows. Composes filter-first-then-limit with kind/tier.
project_idNoKeep only capsules whose scope.project_id equals this.
review_stateNob2 staged review: keep only capsules whose STANDING review verdict equals this — `{review_state: "proposed"}` enumerates open proposals, `"rejected"` the rejected ones, `"ratified"` the promoted ones. A never-staged capsule has no review state and matches none. Composes filter-first-then-limit with kind/tier/expired.
project_prefixNoScope-hierarchy fence: keep capsules whose project_id equals this prefix exactly OR starts with it + "/" — "nott" covers "nott" and "nott/x", never "nottx". AND-composes with project_id. Character-exact (no glob, no case folding).
Behavior5/5

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

Despite no annotations, the description fully discloses behavioral traits: returns compact entries, append order, filter effects, project_prefix substring matching with examples, rejection of empty/terminated prefixes, no tombstoned capsules, and advisory data status.

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 description is dense but front-loaded with the core purpose. It packs many details into a single paragraph with parentheticals, making it thorough but slightly hard to scan. Could be broken into clearer sections, but every sentence adds value given 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?

For a tool with 7 optional parameters, no output schema, and no annotations, the description is exceptionally complete. It covers all filters, edge cases (empty prefix rejected), data volume (advisory), and return field semantics. No gaps.

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?

With 100% schema coverage, baseline is 3. The description adds significant meaning beyond schema: explains by-kind view for 'kind', subtree matching for 'project_prefix' with edge cases, and composition of filters. However, some schema descriptions already cover the basics, so not a 5.

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 explicitly states the verb ('list') and resource ('capsules as compact entries'), detailing the fields returned and the append order. It clearly distinguishes from sibling tools like memory_get (full capsules) and others like memory_digest for tier counts.

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 explicit guidance on when to use (listing with filters) and when not (tombstoned capsules never appear, use memory_get for full detail). Mentions specific use cases like 'list my open tasks' with kind filter, and explains filter composition.

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/menot-you/n-memory'

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