Skip to main content
Glama

forget

Delete memories permanently from your knowledge graph to remove outdated facts, reversed decisions, or duplicates.

Instructions

Remove a specific memory permanently from your knowledge graph.

This action is irreversible — the memory and its embeddings are deleted. Use recall or list_memories first to find the correct memory_id.

Use this when:

  • A fact is no longer true: forget("mem_abc123")

  • A decision was reversed and the old one is misleading

  • Removing duplicate or incorrect memories

Do NOT use this to "update" a memory — instead, forget the old one and remember the corrected version.

Args: memory_id: The unique memory identifier (e.g., "mem_abc123") obtained from remember, recall, or list_memories results.

Returns: Confirmation that the memory was deleted. Returns an error if the memory_id doesn't exist or has already been deleted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
memory_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The forget tool handler function. It is decorated with @mcp.tool() and accepts a memory_id parameter. The function proxies the call to a remote Astria instance via _proxy(). Includes full docstring describing the tool's purpose, arguments, and return values.
    @mcp.tool()
    async def forget(memory_id: str) -> str:
        """Remove a specific memory permanently from your knowledge graph.
    
        This action is irreversible — the memory and its embeddings are deleted.
        Use `recall` or `list_memories` first to find the correct memory_id.
    
        Use this when:
        - A fact is no longer true: `forget("mem_abc123")`
        - A decision was reversed and the old one is misleading
        - Removing duplicate or incorrect memories
    
        Do NOT use this to "update" a memory — instead, forget the old one
        and `remember` the corrected version.
    
        Args:
            memory_id: The unique memory identifier (e.g., "mem_abc123") obtained
                from `remember`, `recall`, or `list_memories` results.
    
        Returns:
            Confirmation that the memory was deleted. Returns an error if the
            memory_id doesn't exist or has already been deleted.
        """
        return await _proxy("forget", memory_id=memory_id)
  • The _proxy helper function that forwards tool calls to the remote Astria instance via SSE transport. All tools including forget use this to communicate with the backend memory service.
    async def _proxy(tool_name: str, **kwargs) -> str:
        """Proxy a tool call to the remote Astria instance."""
        headers = {}
        if API_KEY:
            headers["Authorization"] = f"Bearer {API_KEY}"
    
        try:
            transport = SSETransport(sse_url, headers=headers)
            async with Client(transport) as client:
                result = await client.call_tool(tool_name, kwargs)
                # FastMCP 3.2: result is CallToolResult with .content list
                if hasattr(result, 'content'):
                    parts = result.content
                    if parts and len(parts) > 0:
                        return parts[0].text if hasattr(parts[0], 'text') else str(parts[0])
                # Fallback for older API
                if hasattr(result, 'text'):
                    return result.text
                return str(result)
        except Exception as e:
            return f"Connection error: {e}. Verify your ASTRIA_ENDPOINT and ASTRIA_API_KEY."
  • server.py:26-26 (registration)
    The FastMCP server instance creation. Tools are registered to this instance using the @mcp.tool() decorator.
    mcp = FastMCP("Astria")
Behavior5/5

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

With no annotations provided, the description carries full burden and excels: it discloses irreversibility ('the memory and its embeddings are deleted'), error conditions ('Returns an error if the memory_id doesn't exist'), and return values ('Confirmation that the memory was deleted'). This provides critical safety context for a destructive operation.

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?

Despite length, every sentence serves a critical purpose for a destructive tool: irreversibility warning is front-loaded, prerequisite steps are explicit, usage scenarios are bulleted for scanability, and Args/Returns sections compensate for schema gaps. No redundancy exists; structure enhances clarity.

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 high complexity (irreversible deletion, prerequisite lookups needed) and 0% schema coverage, the description is remarkably complete. It covers the action, safety implications, prerequisite workflow, usage scenarios, anti-patterns, parameter semantics, and return behavior—sufficient for safe autonomous operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% (memory_id lacks description field), but the description fully compensates: it explains the parameter represents 'The unique memory identifier', provides format example ('mem_abc123'), and specifies provenance ('obtained from `remember`, `recall`, or `list_memories` results'), giving the agent complete semantic context.

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 opens with a specific verb ('Remove') + resource ('memory') + scope ('permanently from your knowledge graph'). It clearly distinguishes from siblings by contrasting with `remember` (for creating/updating) and `recall`/`list_memories` (for retrieving), establishing its unique place in the CRUD lifecycle.

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 prerequisites ('Use `recall` or `list_memories` first'), three specific 'Use this when' scenarios with examples, and a clear anti-pattern ('Do NOT use this to "update" a memory') with the correct alternative workflow. This covers when-to-use, when-not-to-use, and alternatives comprehensively.

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/PL-ODIN/astria-plugin'

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