@greatnxy/web-search-mcp
Provides web search functionality through the Brave Search API, returning ranked results with titles, URLs, and snippets. It is used as a fallback provider when Tavily is unavailable or returns no results.
Click on "Deploy 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., "@@greatnxy/web-search-mcpwhat are the latest developments in renewable energy?"
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.
@greatnxy/web-search-mcp
A focused MCP server that gives your MCP client a straightforward way to search the web and receive structured results through a single tool: web_search.
This server integrates with Tavily and Brave because both services provide free usage options, making it practical to get started with web search. See their plans and pricing: Tavily Plans & Pricing · Brave Search API Plans.
Install and run
npm install
$env:TAVILY_API_KEY = "tvly-..."
$env:BRAVE_API_KEY = "BSA..."
npm run build
npm startIf you want to use only Brave's free quota, be sure to set a usage limit for your Brave Search account. Configure it inBrave Search usage limits.
For key rotation within each provider, use comma-separated values.
$env:TAVILY_API_KEYS = "tvly-first,tvly-second"
$env:BRAVE_API_KEYS = "brave-first,brave-second"Keys are chosen randomly from each provider's currently available pool. A 429 pauses that Key until the provider's response says it can be retried. An authentication or quota error removes the Key until the server is restarted.
Related MCP server: AIE7-MCP
VS Code configuration
Create or edit your MCP configuration and keep secrets in password inputs:
{
"inputs": [
{
"type": "promptString",
"id": "tavily-api-key",
"description": "Tavily API key",
"password": true
},
{
"type": "promptString",
"id": "brave-api-key",
"description": "Brave Search API key",
"password": true
}
],
"servers": {
"web-search": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@greatnxy/web-search-mcp"],
"env": {
"TAVILY_API_KEY": "${input:tavily-api-key}",
"BRAVE_API_KEY": "${input:brave-api-key}"
}
}
}
}Environment variables
Variable | Default | Purpose |
| required | One key or a comma-separated Tavily key pool. |
| required | One key or a comma-separated Brave key pool. |
|
| Tavily and Brave HTTP request timeout. |
Search behavior
The gateway calls Tavily first. It calls Brave when Tavily returns no results, times out, is unavailable, is rate-limited, or reports exhausted plan/PAYG quota. Each request randomly selects an available key from the chosen provider's pool.
Tool input and output
web_search accepts query, optional max_results (1–20), freshness (day, week, month, year), ISO country code, and include/exclude domain lists.
It returns query, selected provider, fallback state and reason, providers tried, and ranked title/url/snippet results.
Verify
npm run check
npm test
npm run buildAvailable Tools
1 toolweb_searchA
Search the web. Tavily is used first; Brave is used only when Tavily is unavailable, out of quota, rate-limited, or returns no results.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The web-search query. | |
| country | No | ISO 3166-1 alpha-2 country code, such as CN or US. | |
| freshness | No | Only return recently published or updated results. | |
| max_results | No | Maximum number of results. Defaults to 5. | |
| exclude_domains | No | Exclude these domains. | |
| include_domains | No | Only search these domains. |
TDQS
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 clearly explains the provider fallback behavior (Tavily first, Brave only under specific failure conditions), which is non-obvious and valuable. However, it does not detail output format, error handling, or rate limits, but the core behavioral nuance is covered.
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?
The description is a single sentence, front-loaded with the primary purpose ('Search the web.'), followed by a concise fallback explanation. Every word earns its place; no filler or 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?
Given the tool's simplicity and the schema's complete parameter coverage, the description is adequate. It adds key provider behavior that is not inferable from the schema. The lack of an output schema is a minor gap, but for a web search tool the return type is intuitive. Overall, the description is sufficient for an agent to select and invoke the tool correctly.
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?
The input schema provides 100% coverage of parameter descriptions, so the baseline applies. The description does not add any additional parameter-level details, but relies on the schema to explain query, country, freshness, max_results, and domain restrictions.
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 verb and resource: 'Search the web.' It also adds specific provider fallback logic (Tavily then Brave), which distinguishes the tool's behavior. Though no siblings are present, the purpose is unambiguous and not a tautology.
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?
Usage is implied by the tool's name and description ('Search the web.'), but there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The fallback note hints at availability conditions but does not provide direct usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.0.0- First observed
web_search
TDQS
Scored across 1 tool
There is only one tool, so there is no possibility of confusion between tools. The purpose of the server is unambiguous.
The single tool name 'web_search' follows a clear verb_noun pattern, consistent and self-explanatory.
With only one tool, the server is minimal but might feel thin for broader search needs. However, for a focused web search purpose, it is acceptable.
For a web search server, the single tool covers the essential functionality of searching the web. There are no obvious gaps for the stated purpose.
Maintenance
Related MCP Connectors
Docs: https://docs.keenable.ai/mcp-server Keenable is a free, remote MCP server that gives agents access to the web index. Search the web with ranked results and date/site filters, then fetch any indexed page as clean markdown. Works out of the box with no account or API key.
Serper MCP — wraps the Serper Google Search API (serper.dev)
Related MCP Servers
- AlicenseBqualityDmaintenanceA local MCP server that exposes Tavily search as a tool and rotates across multiple API keys for reliability.1MIT
- FlicenseAqualityDmaintenanceMCP server that provides web search capabilities using the Tavily API.3-
- AlicenseBqualityDmaintenanceMCP server providing search, extract, map, and crawl tools powered by Tavily for real-time web data access.413 npmMIT
- FlicenseNot gradedqualityBmaintenanceMCP server that gives AI agents access to current web information through web_search and fetch_url tools, using Tavily, Brave, and DuckDuckGo providers with automatic fallback.-