Skip to main content
Glama
PedroDnT

MCP Deep Web Research Server

parallel_search

Execute multiple Google searches simultaneously to accelerate web research by processing queries in parallel.

Instructions

Perform multiple Google searches in parallel

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queriesYesArray of search queries to execute in parallel
maxParallelNoMaximum number of parallel searches

Implementation Reference

  • src/index.ts:125-147 (registration)
    Registration of the 'parallel_search' tool in the MCP server, including name, description, and input schema definition.
    {
        name: 'parallel_search',
        description: 'Perform multiple Google searches in parallel',
        inputSchema: {
            type: 'object',
            properties: {
                queries: {
                    type: 'array',
                    items: {
                        type: 'string'
                    },
                    description: 'Array of search queries to execute in parallel'
                },
                maxParallel: {
                    type: 'number',
                    description: 'Maximum number of parallel searches',
                    minimum: 1,
                    maximum: 5
                }
            },
            required: ['queries']
        }
    },
  • MCP server handler for 'parallel_search' tool call: validates input, limits queries, delegates to DeepResearch.parallelSearch.parallelSearch(), and returns JSON result.
    case 'parallel_search': {
        const args = request.params.arguments as unknown as ParallelSearchArgs;
        if (!args?.queries) {
            throw new McpError(ErrorCode.InvalidParams, 'Queries array is required');
        }
    
        const limitedQueries = args.queries.slice(0, 5);
        console.log(`Starting parallel search with ${limitedQueries.length} queries`);
        const result = await deepResearch.parallelSearch.parallelSearch(limitedQueries);
    
        return {
            content: [
                {
                    type: 'text',
                    text: JSON.stringify(result, null, 2)
                }
            ]
        };
    }
  • Core handler function: performs parallel Google searches by launching browser contexts, executing searches on google.com, extracting results with relevance scoring, saving to files, and returning structured results with summary.
    public async parallelSearch(queries: string[]): Promise<{
        results: ParallelSearchResult[];
        summary: {
            totalQueries: number;
            successful: number;
            failed: number;
            totalExecutionTime?: number;
            averageExecutionTime?: number;
        };
    }> {
        const startTime = this.options.includeTimings ? Date.now() : undefined;
        await this.initialize();
    
        const results: ParallelSearchResult[] = [];
        const chunks: string[][] = [];
    
        // Split queries into chunks of maxParallel size
        for (let i = 0; i < queries.length; i += this.options.maxParallel) {
            chunks.push(queries.slice(i, i + this.options.maxParallel));
        }
    
        // Process each chunk
        for (const chunk of chunks) {
            const chunkPromises = chunk.map((query, index) => {
                const searchId = `search_${Date.now()}_${index + 1}_of_${chunk.length}`;
                // Stagger the searches
                return new Promise<ParallelSearchResult>(async (resolve) => {
                    await new Promise(r => setTimeout(r, index * this.options.delayBetweenSearches));
                    const result = await this.singleSearch(
                        this.contexts[index % this.contexts.length],
                        query,
                        searchId
                    );
                    resolve(result);
                });
            });
    
            const chunkResults = await Promise.all(chunkPromises);
            results.push(...chunkResults);
    
            // Add a small delay between chunks
            if (chunks.indexOf(chunk) < chunks.length - 1) {
                await new Promise(r => setTimeout(r, 1000));
            }
        }
    
        const endTime = Date.now();
        const successful = results.filter(r => !r.error).length;
        const failed = results.filter(r => r.error).length;
    
        const summary = {
            totalQueries: queries.length,
            successful,
            failed,
            ...(this.options.includeTimings && startTime ? {
                totalExecutionTime: endTime - startTime,
                averageExecutionTime: Math.round((endTime - startTime) / queries.length)
            } : {})
        };
    
        // Add individual execution times to results if timing is enabled
        const timedResults = this.options.includeTimings ? results.map(r => ({
            ...r,
            executionTime: r.executionTime || 0
        })) : results;
    
        return {
            results: timedResults,
            summary
        };
    }
  • TypeScript interface defining input arguments for parallel_search tool.
    interface ParallelSearchArgs {
        queries: string[];
        maxParallel?: number;
    }
  • Type definitions for SearchResult (single search result) and ParallelSearchResult (result per query), used as output schema for parallel_search.
    export interface SearchResult {
        title: string;
        url: string;
        snippet: string;
        relevanceScore: number;
    }
    
    export interface ParallelSearchResult {
        searchId: string;
        query: string;
        results: SearchResult[];
        error?: string;
        executionTime?: number;
    }
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. It mentions 'parallel' execution but doesn't describe rate limits, error handling, authentication needs, or what the output looks like. For a tool that performs multiple external operations, this is a significant gap.

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, efficient sentence that communicates the core functionality without unnecessary words. It's appropriately sized and front-loaded with the essential information.

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 tool that performs multiple external operations with no annotations and no output schema, the description is incomplete. It doesn't address what the tool returns, how errors are handled, or any constraints beyond parallelism. The agent would need to guess about the tool's behavior and output format.

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%, so the schema already documents both parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema. The baseline of 3 is appropriate when the schema does the heavy lifting.

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 action ('Perform multiple Google searches') and the key characteristic ('in parallel'), which distinguishes it from basic search tools. However, it doesn't explicitly differentiate from sibling tools like 'deep_research' or 'visit_page' beyond the parallelism aspect.

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 'deep_research' or 'visit_page'. It doesn't mention use cases, prerequisites, or limitations beyond what's implied by the name and parameters.

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/PedroDnT/mcp-DEEPwebresearch'

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