Multi-Search MCP Server
Provides web search capabilities through Brave Search API, supporting search queries with customizable result counts as part of a multi-provider search fallback system.
Enables web search through DuckDuckGo without requiring an API key, offering search functionality with customizable result counts as part of a multi-provider search system.
Provides web search capabilities through Google Custom Search API, enabling customizable web searches with configurable result counts as part of a multi-provider search fallback system.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Multi-Search MCP Serversearch for latest AI developments in quantum computing"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP Search Server
This package exists to provide a unified MCP (Model Context Protocol) interface for multi-provider web search. It allows you to leverage the free monthly quota given by multiple search services (such as Google and Tavily) by automatically falling back between them, maximizing your available search capacity for automation and AI workflows.
Features
Supports Google Custom Search, Tavily Search, DuckDuckGo Search, and Brave Search.
Exposes a single MCP tool:
search.Allows specifying a provider directly or uses a priority-based fallback (default: Tavily, Google, DuckDuckGo, Brave).
Standardizes search results into a common format.
Configurable via environment variables.
Brave Search support (requires API key passed via MCP env, not .env).
Related MCP server: Search MCP Server
Getting Free API Credentials
Tavily
Go to Tavily and sign up for a free account.
After verifying your email, log in to your Tavily dashboard.
Navigate to the API section and generate a free API key.
Copy the API key and use it as
TAVILY_API_KEYin your configuration.
Brave Search
Go to Brave Search API and click "Get started".
Sign in or create a Brave account.
Follow the instructions to subscribe to the Brave Search API (free tier available).
Once subscribed, go to your Brave dashboard and generate an API key.
Copy the API key and use it as
BRAVE_API_KEYin your MCP client configuration (must be passed via MCP env, not .env).
Google Custom Search
Go to the Google Cloud Console and create a new project (or select an existing one).
Enable the Custom Search API for your project.
Go to the Custom Search Engine and create a new search engine.
For "Sites to search", you can enter
www.example.com(you can edit this later to search the entire web).After creation, go to the control panel of your search engine and enable "Search the entire web" in the "Sites to search" section.
Copy the Search Engine ID (CX) and use it as
GOOGLE_CX.In the Cloud Console, go to APIs & Services > Credentials and create an API key.
Use this API key as
GOOGLE_API_KEYin your configuration.
Setup
Installing via Smithery
To install multi-search-mcp for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @guptabhishek/multi-search-mcp --client claudeInstalling Manually
After updating your configuration or credentials, run:
npm run build
npm startClone/Download: Get the server code.
Install Dependencies:
npm installConfigure API Keys (via MCP Client Settings):
Instead of using a
.envfile, you can configure the API keys and optional port directly within your MCP client's JSON settings (e.g., Cline'scline_mcp_settings.json).Add or modify the server entry for
mcp-search-serverand provide the necessary keys in theenvobject:
{ "servers": { // ... other servers ... "search": { // Or your chosen name for this server "autoApprove": [], "disabled": false, // Set to false to enable "timeout": 120, "command": "npx", // Or the command to run the server "args": [ "-y", "mcp-search-server" ], "env": { // Required API Keys "TAVILY_API_KEY": "YOUR_TAVILY_API_KEY", "GOOGLE_API_KEY": "YOUR_GOOGLE_API_KEY", "GOOGLE_CX": "YOUR_GOOGLE_CUSTOM_SEARCH_ENGINE_ID", "BRAVE_API_KEY": "YOUR_BRAVE_SEARCH_API_KEY", // Brave Search API Key (must be passed via MCP env, not .env) // DuckDuckGo does not require an API key. // Optional: Configure providers and strategy "SEARCH_PROVIDERS": "tavily,google,duckduckgo,brave", // Comma-separated list of providers in desired priority "SEARCH_STRATEGY": "random", // Or "priority" // Optional Port Override "PORT": "3002" // Example: run on port 3002 instead of default }, "transportType": "stdio" // Assuming stdio transport } // ... other servers ... } }Replace the placeholder values (
YOUR_..._KEY,/path/to/your/MCP/...) with your actual keys and the correct path to the builtindex.jsfile.Ensure you provide keys for the providers you intend to use.
Running the Server
npm startThe server will start, typically on port 3001 (or the port specified in .env). It will print the available tool name and the status of loaded API keys.
MCP Tool: search
Description: Performs a web search using multiple providers (Tavily, Google, DuckDuckGo, Brave) with priority fallback.
Input Schema:
query(string, required): The search term.provider(string, optional, enum: ["google", "tavily", "duckduckgo", "brave"]): Specify a provider directly. If omitted, uses priority fallback.num_results(integer, optional, default: 10): Number of results desired (min: 1, max: 20).
Output: A JSON object containing an array of content objects, where each object represents a structured search result:
{ "content": [ { "type": "search_result", // Or another appropriate type "title": "Result Title", "link": "https://example.com/result", "snippet": "Description or snippet of the result.", "provider": "tavily" // Indicates which provider returned this result }, // ... more results ] }
Connecting to Cline (or other MCP clients)
Add the server command (e.g., node build/index.js) or connection details to your MCP client's configuration. Cline should then detect the search tool.
Modifying Provider Priority
Edit the PROVIDER_LIST array in src/config.ts (and rebuild) to change the fallback order. The default is ['tavily', 'google', 'duckduckgo', 'brave'].
Available Tools
1 toolsearchB
Performs a web search using multiple providers (google, tavily, duckduckgo, brave).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query. | |
| provider | No | Optional: Specify a provider directly (google, tavily, duckduckgo, brave). If omitted, uses priority fallback. | |
| num_results | No | Number of results desired (default: 10). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as how results are returned, how provider fallback works, rate limits, or authentication requirements. This leaves the agent with insufficient context for safe operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 11 words that front-loads the action ('Performs a web search') and includes key details, achieving maximum efficiency with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description omits critical information: expected output format, response structure, error behavior, and how provider priority fallback works. This hinders effective agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds minimal value—it lists providers, but the schema already does so via enum. No additional semantics about parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a web search and lists the supported providers, which is specific and distinguishes it from potential tools with different search capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for web searches but does not provide explicit guidance on when to use this tool versus alternatives (though there are no siblings), nor does it mention prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
Only one tool exists, so there is no possibility of confusion between tools. Agents can reliably select the search tool for web search tasks.
With a single tool named 'search', naming is perfectly consistent within its own context. No pattern conflicts arise.
One tool is borderline for a search server. While it provides core search functionality, it is minimal and could benefit from separate tools for different providers or result handling.
The tool covers the primary search operation and abstracts multiple providers, fulfilling the server's stated purpose. Minor gaps like provider-specific parameters or result filtering are absent but not critical.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Web search for AI agents — one tool across 6 engines, routed to the cheapest + cached.
The best web search for your AI Agent
LLM-ready web search + instant answers + URL-to-clean-text fetch for agents and RAG.
Web search, fetch, extract, and research for AI agents. Markdown output + AI-synthesized answers.
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceProvides web search capabilities using the Tavily API, enabling AI models to search the internet and retrieve up-to-date information.
- AlicenseAqualityBmaintenanceEnables AI agents to perform unified web searches, GitHub, and GitLab searches with caching, reranking, and fallback across multiple providers.44918MIT
- FlicenseNot gradedqualityCmaintenanceEnables AI agents to search the web and extract content using multiple search providers, with caching, retry logic, and options for JavaScript-heavy page rendering.
- AlicenseNot gradedqualityCmaintenanceProvides multi-provider web search capabilities with fallback chains, semantic reranking, and content extraction for grounded agent retrieval.MIT
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/guptabhishek/multi-search-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server