Skip to main content
Glama

m9k_delete_session

DestructiveIdempotent

Remove a session from the index to delete all associated chunks and search data while preserving the original source file.

Instructions

Delete a session from the index. Removes all chunks and search data. Does NOT delete the source JSONL file.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sessionIdYesThe session ID to delete

Implementation Reference

  • The tool m9k_delete_session is registered and implemented in src/tools/manage.ts using the server.registerTool function. The handler verifies the session existence, prevents the deletion of a reserved session, and then cleans up chunks and updates the session status in the database.
    server.registerTool(
      'm9k_delete_session',
      {
        description:
          'Delete a session from the index. Removes all chunks and search data. Does NOT delete the source JSONL file.',
        inputSchema: {
          sessionId: z.string().describe('The session ID to delete'),
        },
        annotations: {
          readOnlyHint: false,
          destructiveHint: true,
          idempotentHint: true,
          openWorldHint: false,
        },
      },
      async ({ sessionId }) => {
        // Guard: never delete the manual memories session
        if (sessionId === '__manual_memories__') {
          return {
            content: [
              {
                type: 'text' as const,
                text: JSON.stringify({
                  error:
                    'Cannot delete __manual_memories__ session. Use m9k_save to manage manual memories.',
                }),
              },
            ],
            isError: true,
          };
        }
    
        // Check if session exists
        const session = ctx.db
          .prepare('SELECT id, project FROM conv_sessions WHERE id = ?')
          .get(sessionId) as { id: string; project: string } | undefined;
    
        if (!session) {
          return {
            content: [
              {
                type: 'text' as const,
                text: JSON.stringify({ error: 'Session not found', sessionId }),
              },
            ],
            isError: true,
          };
        }
    
        // Count chunks before deletion
        const chunkCount = (
          ctx.db
            .prepare('SELECT COUNT(*) AS cnt FROM conv_chunks WHERE session_id = ?')
            .get(sessionId) as {
            cnt: number;
          }
        ).cnt;
    
        // Soft delete: hard-delete chunks (clean search), tombstone session row
        ctx.db.prepare('DELETE FROM conv_chunks WHERE session_id = ?').run(sessionId);
        ctx.db
          .prepare(
            "UPDATE conv_sessions SET deleted_at = datetime('now'), chunk_count = 0 WHERE id = ?",
          )
          .run(sessionId);
    
        return {
          content: [
            {
              type: 'text' as const,
              text: JSON.stringify({
                deleted: true,
                sessionId,
                project: session.project,
                chunksRemoved: chunkCount,
              }),
            },
          ],
        };
      },
    );
Behavior4/5

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

Annotations establish the destructive and idempotent profile, but the description adds crucial behavioral specifics: it details exactly what data is destroyed ('chunks and search data') and provides a vital safety constraint that source files are preserved. This goes beyond the binary destructiveHint annotation.

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?

Three dense sentences with zero waste. The description leads with the core action, follows with specific destruction details, and ends with the critical negative constraint. Every word serves the agent's decision-making process.

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

Completeness4/5

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

Given the simple single-parameter schema and rich safety annotations, the description adequately covers the essential behavioral concerns for a destructive operation. It addresses the key ambiguity (source file safety) that annotations alone don't resolve. Minor gap: doesn't hint at idempotency behavior or return values.

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

Parameters3/5

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

With 100% schema description coverage ('The session ID to delete'), the schema is self-documenting. The description adds no specific syntax, format constraints, or semantic clarification for the sessionId parameter beyond what the schema already provides, which warrants the baseline score of 3.

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 specifies the exact action ('Delete'), the resource ('session from the index'), and distinguishes scope by clarifying it removes index data while preserving the source JSONL file. This clearly differentiates it from file-deletion siblings.

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

Usage Guidelines4/5

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

While it doesn't name explicit sibling alternatives, it provides critical usage boundaries by clarifying what IS deleted (chunks, search data) versus what is NOT deleted (source JSONL file). This implicit guidance helps users understand when to use this tool versus file-system operations.

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/louis49/melchizedek'

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