Skip to main content
Glama

memxus

by com.memxus

List memories

list_memories
Read-onlyIdempotent

List recent memories in reverse-chronological order (read-only). When to use: audit what is saved, browse a collection, or collect memory IDs for get_memory or forget. When NOT: semantic search by topic → recall; one full record → get_memory; aggregate counts only → memory_stats. Behavior: default 20 results (plan-capped), ordered by created_at descending; empty set returns a message suggesting remember; full_content controls preview in the message text (120 chars); structured memories[] always includes full content. To list a team workspace instead of personal memory, pass workspace: .

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNoOptional tags. A tag like project:my-app also sets collection automatically.
typeNoMemory category: general, preference, fact, instruction, or conversation. Omit to include all types.
limitNoPositive integer max results. Omit for server default (20). Capped per your plan.
group_idNoUUID of a shared group. Required with visibility=shared when group_name is not set.
workspaceNoTo operate on a team workspace, pass its exact name, slug, or ID (e.g. "Acme"). Omit — or pass "personal" — for your personal memory (default). Every response echoes resolved_workspace so you can confirm where the operation actually happened. Call list_collections when unsure of the exact workspace name.
collectionNoScope slug (e.g. project:memxus, personal:preferences). GitHub/Notion connector syncs use project:<slug> — one collection per project. Partial names work; call list_collections when unsure.
group_nameNoExact group name (case-insensitive). Alternative to group_id for shared memories.
visibilityNoOptional. Defaults to user dashboard preference (private unless include_group_memories_in_context is on).
full_contentNoWhen true, message text shows full memory content. When false, message previews truncate at 120 chars; memories[].content in structured output is always full.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYesMemories returned (0–limit). Zero triggers empty-state message.
messageYesHuman-readable listing; previews truncate at 120 chars unless full_content=true.
memoriesYesNewest-first matches. Each item includes full content in structured output.
resolved_workspaceNoThe workspace this call actually operated on (defense against writing to the wrong team by typo or name collision). id=null means Personal.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already indicate read-only and non-destructive, but the description adds critical behavioral details: default limit 20 capped by plan, ordering by created_at descending, empty set message suggesting 'remember', and the effect of full_content parameter on preview vs structured output.

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?

Well-structured with front-loaded purpose and usage guidelines. Could be slightly more concise, but every sentence adds value without excessive verbosity.

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 the tool has 9 optional parameters and a full output schema, the description covers all key behaviors, constraints, and usage patterns. Nothing essential is missing for an AI agent to use it 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 baseline is 3. The description adds meaningful context for parameters like full_content (preview truncation vs full in structured), workspace (default vs team), collection (partial name matching), and visibility (dashboard preference). Slightly redundant with schema but adds clear value.

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 clearly states the tool lists memories in reverse-chronological order, and distinguishes itself from siblings like recall, get_memory, and memory_stats by specifying when to use each alternative.

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 provides when-to-use scenarios (audit, browse, collect IDs) and when-not-to-use with specific alternative tools (recall, get_memory, memory_stats). Also clarifies workspace vs personal memory.

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

All memxus toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clear, distinct purpose: forget deletes, remember saves, update modifies, recall searches, list_memories lists, get_memory retrieves full details, get_context builds a context block, list_collections lists folders, memory_stats shows counts. There is no functional overlap that would confuse an agent.

Naming Consistency3/5

Names mix conventions: forget, recall, remember, update are single verbs; get_context, get_memory, list_collections, list_memories follow verb_noun; memory_stats is noun_noun. This inconsistency can make it harder for an agent to predict tool names.

Tool Count5/5

With 9 tools, the server is well-scoped for a memory management system. Each tool addresses a core operation (CRUD, search, stats, context building) without unnecessary redundancy. The count is appropriate for the domain.

Completeness4/5

The surface covers create (remember), read (list_memories, get_memory, recall, get_context), update (update), delete (forget), plus metadata tools (list_collections, memory_stats). Missing explicit filtering by tags or bulk operations, but these are minor gaps given the semantic search capability.

Resources