Skip to main content
Glama

list_memories

Retrieve stored conversation histories from the MITM proxy memory system to review past interactions and maintain context across sessions.

Instructions

List all stored conversation memories

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
user_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The handler function for the 'list_memories' MCP tool. Registered via @mcp.tool decorator. Accepts optional user_id, fetches all memories via memory_service, includes logging and error handling.
    @mcp.tool(name="list_memories", description="List all stored conversation memories")
    async def list_memories(user_id: str | None = None) -> list[dict[str, Any]]:
        """
        List all memories for a user, providing a complete conversation history.
    
        ## When to Use
    
        - User wants to see their complete conversation history
        - You need to browse through all memories
        - Performing a comprehensive review or audit
        - Search didn't find specific memories
        - Getting an overview of all stored conversations
    
        ## Example Usage
    
        ```python
        # List all memories for default user
        memories = await list_memories()
    
        # List memories for specific user
        memories = await list_memories(user_id="alice@example.com")
        ```
    
        ## Example Response
    
        ```json
        [
            {
                "id": "mem_xyz789",
                "memory": "Discussion about implementing OAuth2 with refresh tokens...",
                "created_at": "2024-01-20T14:30:00Z",
                "metadata": {"type": "conversation", "topic": "authentication"}
            },
            {
                "id": "mem_abc123",
                "memory": "User mentioned preferring PostgreSQL over MySQL...",
                "created_at": "2024-01-19T09:15:00Z",
                "metadata": {"type": "preference"}
            }
        ]
        ```
    
        Note: This returns ALL memories. For large histories, prefer search_memories() for specific topics.
    
        Args:
            user_id: User ID (optional, defaults to DEFAULT_USER_ID from settings)
    
        Returns:
            List of all memories sorted by creation date (newest first), each containing:
            - id: Unique memory identifier
            - memory/content: The stored conversation text
            - created_at: ISO timestamp of memory creation
            - metadata: Additional context
        """
        try:
            results = await memory_service.get_all_memories(user_id=user_id)
            logger.info("Memory list retrieved", memory_count=len(results))
            return results
        except Exception as e:
            logger.error("List failed", error=str(e))
            raise RuntimeError(f"List failed: {str(e)}") from e
  • The MemoryService.get_all_memories method called by the tool handler. Uses Mem0's AsyncMemoryClient to retrieve all memories for the given user_id.
    async def get_all_memories(
        self, user_id: str | None = None
    ) -> list[dict[str, Any]]:
        """Get all memories for a user asynchronously.
    
        Args:
            user_id: User identifier (defaults to settings.default_user_id)
    
        Returns:
            List of all memories for the user
        """
        user_id = user_id or settings.default_user_id
    
        try:
            self._logger.info("Getting all memories", user_id=user_id)
    
            results = await self.async_client.get_all(user_id=user_id, version="v2")
    
            self._logger.info(
                "Retrieved memories", user_id=user_id, memory_count=len(results)
            )
            return results
    
        except Exception as e:
            self._logger.error("Failed to get memories", user_id=user_id, error=str(e))
            raise
  • The @mcp.tool decorator that registers the list_memories function as an MCP tool.
    @mcp.tool(name="list_memories", description="List all stored conversation memories")
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure but only states the basic action. It doesn't mention whether this is a read-only operation, if it requires authentication, how results are paginated or sorted, or what the output format entails, leaving critical behavioral traits unspecified.

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?

The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse at a glance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (one optional parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, it lacks details on behavioral aspects like permissions or result structure that would enhance completeness for a tool interacting with stored data.

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?

The description implies no parameters are needed to list all memories, but the schema includes an optional 'user_id' parameter. Since schema description coverage is 0%, the description should compensate but doesn't explain this parameter's purpose. However, with only one optional parameter, the gap is minor, warranting a score above baseline.

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?

The description clearly states the verb ('List') and resource ('all stored conversation memories'), making the tool's function unambiguous. However, it doesn't differentiate from sibling tools like 'search_memories' or 'analyze_conversations' that also involve memory retrieval, which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'search_memories' (which might filter memories) or 'analyze_conversations' (which might process them). It lacks any context about prerequisites, timing, or exclusions, leaving usage decisions entirely to inference.

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/terrymunro/mcp-mitm-mem0'

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