Skip to main content
Glama

delete_documents

Remove documents from your local PocketMCP knowledge base by specifying document IDs or external identifiers. Clean up SQLite vector storage to maintain accurate semantic search results and optimize offline database performance.

Instructions

Delete documents by ID or external ID

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
doc_idsNoDocument IDs to delete
external_idsNoExternal IDs to delete

Implementation Reference

  • The handleDeleteDocuments function is the main handler that validates arguments (doc_ids or external_ids required) and calls ingestManager.deleteDocuments(). Returns JSON with deleted_doc_ids and deleted_chunks.
    async function handleDeleteDocuments(args: any, ingestManager: IngestManager): Promise<any> {
        const { doc_ids, external_ids } = args;
    
        if (!doc_ids && !external_ids) {
          throw new McpError(ErrorCode.InvalidParams, 'Either doc_ids or external_ids must be provided');
        }
    
      const result = await ingestManager.deleteDocuments(doc_ids, external_ids);
    
      return {
        content: [
          {
            type: 'text',
            text: JSON.stringify({
              deleted_doc_ids: result.deletedDocIds,
              deleted_chunks: result.deletedChunks,
            }, null, 2),
          },
        ],
      };
  • The input schema definition for delete_documents tool. Defines two optional properties: doc_ids (array of strings) and external_ids (array of strings) for specifying which documents to delete.
    {
      name: 'delete_documents',
      description: 'Delete documents by ID or external ID',
      inputSchema: {
        type: 'object',
        properties: {
          doc_ids: {
            type: 'array',
            items: { type: 'string' },
            description: 'Document IDs to delete',
          },
          external_ids: {
            type: 'array',
            items: { type: 'string' },
            description: 'External IDs to delete',
          },
        },
      },
    },
  • The IngestManager.deleteDocuments() method that performs the actual deletion. Handles both external ID-based deletion and doc ID-based deletion. Iterates through IDs, fetches documents, deletes them via database, and returns aggregated results.
    async deleteDocuments(docIds?: string[], externalIds?: string[]): Promise<{
      deletedDocIds: string[];
      deletedChunks: number;
    }> {
      const deletedDocIds: string[] = [];
      let totalDeletedChunks = 0;
    
      // Handle deletion by external IDs
      if (externalIds && externalIds.length > 0) {
        for (const externalId of externalIds) {
          const doc = this.db.getDocumentByExternalId(externalId);
          if (doc) {
            const result = this.db.deleteDocument(doc.doc_id);
            deletedDocIds.push(doc.doc_id);
            totalDeletedChunks += result.deletedChunks;
          }
        }
      }
    
      // Handle deletion by doc IDs
      if (docIds && docIds.length > 0) {
        for (const docId of docIds) {
          const result = this.db.deleteDocument(docId);
          if (result.deletedChunks > 0) {
            deletedDocIds.push(docId);
            totalDeletedChunks += result.deletedChunks;
          }
        }
      }
    
      return {
        deletedDocIds,
        deletedChunks: totalDeletedChunks
      };
    }
  • src/server.ts:251-252 (registration)
    The switch case in the tool call handler that routes 'delete_documents' tool calls to the handleDeleteDocuments function.
    case 'delete_documents':
      return await handleDeleteDocuments(args, ingestManager);
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure but offers only the word 'Delete'. It fails to specify whether deletions are permanent or soft, what occurs if IDs don't exist, or how the tool handles the case where zero required parameters means both ID arrays are optional (which could imply bulk-deletion behavior).

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 efficiently compressed into six words with the action verb front-loaded. Every word serves a purpose with no redundant filler, making it appropriately sized for the tool's scope.

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

Completeness2/5

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

For a destructive operation with no output schema and no annotations, the description is incomplete. It omits critical behavioral context such as return values, error handling for non-existent IDs, the consequence of calling with zero parameters (since none are required), and whether deletions are atomic.

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?

Schema description coverage is 100%, documenting both 'doc_ids' and 'external_ids' as arrays for deletion. The description merely restates these parameter purposes ('by ID or external ID') without adding semantic value regarding format constraints, validation rules, or the implications of providing both versus neither parameter.

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 provides a clear verb ('Delete') and resource ('documents') with specific identifier types ('ID or external ID'). It distinguishes from siblings like 'list_documents' and 'search' (read operations) and 'upsert_documents' (create/update) through the destructive verb.

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, nor does it warn about the destructive nature or prerequisites like confirmation requirements. It fails to clarify the relationship with 'upsert_documents' despite both being mutation 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/Kailash-Sankar/PocketMCP'

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