Skip to main content
Glama
jumasheff

RAG Documentation MCP Server

by jumasheff

run_queue

Process and index queued documentation URLs to make them searchable through vector search. Handles URLs sequentially with error handling and progress updates.

Instructions

Process and index all URLs currently in the documentation queue. Each URL is processed sequentially, with proper error handling and retry logic. Progress updates are provided as processing occurs. Use this after adding new URLs to ensure all documentation is indexed and searchable. Long-running operations will process until the queue is empty or an unrecoverable error occurs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • Core handler logic for the 'run_queue' tool. Reads URLs from queue.txt sequentially, processes each with AddDocumentationHandler, tracks success/failure, removes processed URLs, and returns summary.
    async handle(_args: any): Promise<McpToolResponse> {
      try {
        // Check if queue file exists
        try {
          await fs.access(QUEUE_FILE);
        } catch {
          return {
            content: [
              {
                type: 'text',
                text: 'Queue is empty (queue file does not exist)',
              },
            ],
          };
        }
    
        let processedCount = 0;
        let failedCount = 0;
        const failedUrls: string[] = [];
    
        while (true) {
          // Read current queue
          const content = await fs.readFile(QUEUE_FILE, 'utf-8');
          const urls = content.split('\n').filter(url => url.trim() !== '');
    
          if (urls.length === 0) {
            break; // Queue is empty
          }
    
          const currentUrl = urls[0]; // Get first URL
          
          try {
            // Process the URL using add_documentation handler
            await this.addDocHandler.handle({ url: currentUrl });
            processedCount++;
          } catch (error) {
            failedCount++;
            failedUrls.push(currentUrl);
            console.error(`Failed to process URL ${currentUrl}:`, error);
          }
    
          // Remove the processed URL from queue
          const remainingUrls = urls.slice(1);
          await fs.writeFile(QUEUE_FILE, remainingUrls.join('\n') + (remainingUrls.length > 0 ? '\n' : ''));
        }
    
        let resultText = `Queue processing complete.\nProcessed: ${processedCount} URLs\nFailed: ${failedCount} URLs`;
        if (failedUrls.length > 0) {
          resultText += `\n\nFailed URLs:\n${failedUrls.join('\n')}`;
        }
    
        return {
          content: [
            {
              type: 'text',
              text: resultText,
            },
          ],
        };
      } catch (error) {
        return {
          content: [
            {
              type: 'text',
              text: `Failed to process queue: ${error}`,
            },
          ],
          isError: true,
        };
      }
    }
  • MCP tool schema definition for 'run_queue' including name, detailed description, and empty input schema (no parameters required).
    {
      name: 'run_queue',
      description: 'Process and index all URLs currently in the documentation queue. Each URL is processed sequentially, with proper error handling and retry logic. Progress updates are provided as processing occurs. Use this after adding new URLs to ensure all documentation is indexed and searchable. Long-running operations will process until the queue is empty or an unrecoverable error occurs.',
      inputSchema: {
        type: 'object',
        properties: {},
      },
    } as ToolDefinition,
  • Registration of the RunQueueHandler instance in the HandlerRegistry's handlers Map under the key 'run_queue'.
    this.handlers.set('run_queue', new RunQueueHandler(this.server, this.apiClient));
  • Import declaration for RunQueueHandler used in registration.
    RunQueueHandler,
  • Helper constant defining the path to the queue.txt file used for storing pending URLs.
    const __filename = fileURLToPath(import.meta.url);
    const __dirname = path.dirname(__filename);
    const QUEUE_FILE = path.join(__dirname, '..', '..', 'queue.txt');
Behavior4/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. It effectively describes key behavioral traits: sequential processing, error handling with retry logic, progress updates, and long-running nature until queue empty or unrecoverable error. It doesn't mention side effects like resource consumption or rate limits, but covers core operational behavior well.

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 structured with three sentences that each serve a distinct purpose: stating the core operation, describing behavioral characteristics, and providing usage guidelines. It's front-loaded with the main action and contains no redundant or unnecessary information.

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 tool's complexity (long-running queue processing with error handling) and lack of annotations/output schema, the description provides good coverage of what the tool does and when to use it. It could benefit from mentioning what 'indexed and searchable' means or potential side effects, but it's sufficiently complete for an agent to understand the tool's role.

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 input schema has 0 parameters with 100% coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on the tool's operational context and behavior, which adds value beyond the empty schema.

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's purpose with specific verbs ('process and index') and resources ('URLs currently in the documentation queue'), distinguishing it from siblings like clear_queue, extract_urls, and list_queue. It explicitly mentions the target resource (URLs in queue) and the outcome (making documentation indexed and searchable).

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?

The description provides explicit guidance on when to use this tool ('Use this after adding new URLs to ensure all documentation is indexed and searchable'), distinguishing it from alternatives like list_queue (for viewing) or clear_queue (for removal). It clearly states the intended context and timing for invocation.

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/jumasheff/mcp-ragdoc-fork'

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