Skip to main content
Glama
stoneskin

open-memex

by stoneskin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

memory_list

Read-only

List stored memories by scope and type, newest first, as a numbered inventory for recall, filtering, or audit review.

Instructions

List memories in a scope, newest first, as a numbered inventory. Each line keeps the raw fields — [type] id=… created=… source=… — say them back to the user in plain words (source=user → 'you told me this'; inference → 'I inferred this, check me'; keyword → 'caught from your own wording'), never read the raw id aloud unless they ask. When the user asks 'what do you remember about me?', use scope=both and present the inventory conversationally. The user may point at an entry by its number ('delete #3'): numbers are only valid for the listing you just produced — re-run memory_list, read the candidate back in full, and get a confirmation before calling memory_forget (deletion is permanent). include=all is the audit view (superseded versions, retracted, archived also shown). type filters to one memory type; limit caps how many entries come back.

Input Schema

NameRequiredDescriptionDefault
typeNoOnly list memories of this type (e.g. decision, preference, gotcha).
limitNoMax entries to list, newest first (default 20).
scopeNoWhich scope(s) to list. `project` = tied to this repo. `personal` = global across all your projects. `both` lists each scope's newest. Default: project.
includeNoD68: `active` (default) shows what is currently remembered — newest version of each fact, retracted/archived hidden. `all` is the audit view: every stored row including superseded versions and hidden ones. The default CHANGED in D68: superseded versions no longer appear unless include=all.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.7.3
    • addedInput schema / properties / limit / description
      Added value: +"Max entries to list, newest first (default 20)."
    • changedInput schema / properties / scope / enum
      Previous value: -[
-  "project",
-  "personal",
-  "user",
-  "both"
-]New value: +[
+  "project",
+  "personal",
+  "both"
+]
    • addedInput schema / properties / type / description
      Added value: +"Only list memories of this type (e.g. decision, preference, gotcha)."
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true and openWorldHint=false, and the description does not contradict them. It adds genuinely non-obvious behavioral context beyond the annotations: entry numbers are ephemeral to the last listing, and the default now hides superseded versions. It stops short of describing volume/performance characteristics, but with annotations covering the safety profile this is a solid contribution.

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?

Front-loaded with the core action and output format, then moves to presentation and deletion-safety rules. The quoted phrasing guidance ('source=user → "you told me this"') is chatty and slightly crowds out tool behavior, but each sentence carries actionable instruction rather than filler.

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?

With no output schema, the description carries the burden of describing the return value, and it does: a numbered inventory with per-line raw fields and an explanation of what each source value means. Combined with the include=all audit behavior and the deletion safety loop, an agent has everything needed to call and interpret this tool correctly.

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 baseline is 3, but the description adds usage-conditional meaning the schema lacks: scope=both is the right setting for recall-style questions, and include=all is framed as 'the audit view'. The type and limit mentions largely restate the schema, so the gain is real but partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('List memories in a scope, newest first, as a numbered inventory') and even specifies the output shape, so an agent knows exactly what it gets. It does not explicitly distinguish itself from memory_search or memory_status, so sibling differentiation is only implied by 'inventory' vs. a search tool.

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?

Gives explicit triggering conditions ('When the user asks "what do you remember about me?", use scope=both'), names the audit-view condition for include=all, and routes to memory_forget with a required re-list-and-confirm precondition. It also warns that numbers are only valid for the most recent listing, which is exactly the kind of usage constraint an agent would otherwise get wrong.

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

Deploy Server

Other Tools