agent-web-search
This server provides a single MCP web_search tool that searches the web through multiple independent providers and returns normalized results.
Search the web with a complete natural-language
queryusing enabled providers (DuckDuckGo, Exa, and Parallel by default).Optionally narrow a request to a subset of enabled providers via
providers.Control how many results are returned with
max_results(1–20, default 10).Control how many search queries/keywords to generate with
max_keyword(1–10, default 3).Filter results by recency using
time_range(d,w,m, ory).Receive normalized
resultsper successful provider; failed providers are omitted from successful responses.If every enabled provider fails, the server returns a tool error with code
all_providers_failedplus per-provider diagnostics.
Provides web search integration via DuckDuckGo, returning normalized search results alongside other providers.
Registers the standard web_search tool for Hermes, replacing its built-in search with the multi-provider search core.
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., "@agent-web-searchWhat changed in the latest OpenAI Codex CLI?"
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.
Agent Web Search
Agent-native web search for AI agents — aggregating model-native search and agent search providers, not traditional search engines.
English | 简体中文
Works with Codex CLI, Claude Code, OpenCode, Hermes, ordinary shell scripts, Python applications, and remote Streamable HTTP MCP clients.
Use with an agent · Providers · Shared interface · Configuration · Other interfaces · Troubleshooting · Architecture · Development
Agent Web Search gives an agent two ways to reach the same provider-neutral search core: a native MCP tool, or a CLI taught through a standard Agent Skill.
This is not a Google/Bing/Baidu metasearch wrapper. Traditional search aggregation fans a keyword query out to conventional engines and merges their result pages. Agent Web Search instead aggregates search capabilities built for agents: model-native web grounding, agent-oriented search APIs, and context-ready sources that accept natural-language questions and return answers, citations, or structured evidence in forms an agent can use directly. DDGS is the only conventional search backend in the current provider set.
Natural-language question
│
▼
SearchEngine
┌─────┼──────────────┐
▼ ▼ ▼
DDGS Model providers Agent search providers
ARK · Gemini Exa · Parallel · Brave
Grok · DeepSeek Perplexity · Tavily · You.com
Codex Alpha Zhipu Web Search
Zhipu ChatWhy Agent Web Search
Traditional search aggregation (Google/Bing/Baidu wrappers, scraped SERPs) sends a keyword query to conventional engines and merges result pages. Agent Web Search instead aggregates search capabilities built for agents: one tool call returns structured, citation-ready evidence — or, through model-native grounding providers, a synthesized answer with explicit citations. A measured benchmark shows the practical difference: on a natural-language Chinese query asking for official sources, conventional SERP backends returned no government-domain results in the top 5, while the grounding provider returned the 海关总署 figures with a working citation.
Agent-native by design. The primary interface is a complete natural-language question, not a thin keyword fan-out to Google, Bing, or Baidu.
Model-native search backends. ARK, Gemini, Grok, DeepSeek, Zhipu Chat Search, and Codex Alpha can combine web retrieval with model-generated synthesis and explicit citations.
Agent search providers. Exa, Parallel, Brave, Perplexity, Tavily, You.com, and Zhipu Web Search expose search APIs intended to provide structured, citation-friendly, or context-ready evidence to downstream agents.
One provider-neutral contract. Every backend is available through the same MCP tool, CLI, Python API, and normalized
results; model-backed providers may also return ananswer.Independent providers. Selected providers run concurrently, and one provider's failure never discards another provider's successful result.
DDGS remains a simple fallback. DDGS is the only conventional search backend; it requires no API key and keeps the project usable without paid provider credentials. Exa and Parallel are also keyless by default.
No telemetry, no shared secrets. Provider keys stay in runtime environment variables; there is no shared API-key service.
Related MCP server: GroundRoute
Providers
The provider list is intentionally split by the kind of search capability it provides. Only DDGS is a conventional search backend; the other two groups are built around model-native grounding or agent-facing search services.
Free, keyless defaults: DDGS, Exa, and Parallel all work without an API key. Exa and Parallel automatically use their free MCP transports until a paid API key is provided.
Traditional search backend
Provider | Website | Search backend | API key | Enabled by default |
DDGS | Conventional DuckDuckGo search | Free · no key required | Yes |
Model providers
These providers use a model-native search or grounding surface. Their responses can include a model-generated answer together with citations or other explicit search evidence.
Provider | Website | Model-native search surface | API key | Enabled by default |
ARK | Responses API with Doubao web-search grounding |
| No | |
Codex Alpha (experimental) | Alpha Search-compatible gateway | Model-backed Alpha Search surface |
| No |
DeepSeek | Anthropic Messages API with native web search |
| No | |
Gemini | Gemini Google Search grounding |
| No | |
Grok | xAI web search and X Search |
| No | |
Zhipu Chat Search | GLM Chat Completions with native web search |
| No |
Agent search providers
These providers expose search services for agent consumption: natural-language queries, structured source rows, high-signal excerpts, or citation-friendly metadata rather than a conventional search-page experience.
Provider | Website | Agent-facing search surface | API key | Enabled by default |
Exa | Semantic Search API or free MCP fallback | Free without key · optional | Yes | |
Parallel | Context-oriented search API or free MCP | Free without key · optional | Yes | |
Brave | Structured Web Search API |
| No | |
Perplexity | Native structured Search API |
| No | |
Tavily | Agent-oriented Search API |
| No | |
You.com | Unified web and news Search API |
| No | |
Zhipu Web Search | Standalone structured Web Search API |
| No |
The provider architecture is intentionally open: another search-capable backend can be added without changing the MCP, Hermes, CLI, or Python-facing interfaces.
Use with an agent
Requirements: Python 3.10+. The default providers — DDGS, Exa, and
Parallel — need no API key. Choose one integration shape for your agent; both
use the same package and search engine. The PyPI package installs both
agent-web-search-mcp and agent-web-search commands.
Option 1: MCP
Choose MCP when the agent supports tool servers and you want typed discovery,
protocol-level errors, or remote access. The same agent-web-search-mcp
command supports local stdio and stateless Streamable HTTP.
Local stdio MCP
Install the package once:
# Recommended isolated installation
pipx install agent-web-search-mcp
# Or install into the active Python environment
python -m pip install agent-web-search-mcpThen configure the MCP client to launch agent-web-search-mcp:
{
"mcpServers": {
"agent-web-search": {
"command": "agent-web-search-mcp",
"args": []
}
}
}If uvx is already available, a client can run the package without a
persistent install by using command uvx with args ["agent-web-search-mcp"].
# Codex CLI
codex mcp add agent-web-search -- agent-web-search-mcp
# Claude Code
claude mcp add agent-web-search -- agent-web-search-mcpOpenCode:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"agent-web-search": {
"type": "local",
"command": ["agent-web-search-mcp"],
"enabled": true
}
}
}Remote MCP over HTTPS
Use one of the deployment buttons at the top of this README, or run the same server yourself:
python -c "import secrets; print(secrets.token_urlsafe(32))"
export AGENT_WEB_SEARCH_AUTH_TOKEN="<your-generated-token>"
agent-web-search-mcp --transport httpThe server exposes authenticated POST /mcp and public GET /healthz. A
remote MCP client connects like this:
{
"mcpServers": {
"agent-web-search": {
"url": "https://your-deployment.example/mcp",
"headers": {
"Authorization": "Bearer your-deployment-token"
}
}
}
}Every public deployment must set AGENT_WEB_SEARCH_AUTH_TOKEN to at least 32
characters. The server is stateless and does not create MCP-Session-Id values.
Option 2: CLI + Skill
Choose this shape when the agent already has shell access and supports Agent
Skills. The Skill teaches the agent how to invoke the CLI, select controls,
interpret results, and handle structured failures; no MCP configuration is
needed.
Install the CLI:
pipx install agent-web-search-mcp # Or: python -m pip install agent-web-search-mcpInstall the included
agent-web-searchSkill:npx skills add JerryLiu369/agent-web-search --skill agent-web-searchIf the agent does not use the
skillsinstaller, copyskills/agent-web-searchinto that client's Skills directory.Verify the CLI, then let the agent search:
agent-web-search --version agent-web-search "What changed in the latest OpenAI Codex CLI?"
The CLI writes one JSON document to stdout on success. If every provider fails,
it writes the shared all_providers_failed JSON to stderr and exits with status
1, so shell-capable agents can distinguish a real failure from empty results.
| CLI option | MCP argument | Values | Default |
| --- | --- | --- |
| positional QUERY | query | 1–4,000 character natural-language question | required |
| --provider (repeatable) | providers | enabled provider names | all enabled |
| --max-results | max_results | 1–20 | 10 |
| --time-range | time_range | d, w, m, y | — |
| --grok-search-mode | grok_search_mode | web_search, x_search, both | web_search |
pipx install 'git+https://github.com/JerryLiu369/agent-web-search.git'Do not place API keys in shell history, source code, Git commits, screenshots, or checked-in MCP configuration. Supply them through server-side or local environment variables.
Shared request and response
MCP exposes one tool named web_search; the CLI maps to the same inputs.
Argument | Type | Required | Default | Description |
| string, 1–4,000 characters | Yes | — | Complete natural-language search question |
| integer, 1–20 | No |
| Desired maximum number of results |
|
| No | — | Past day, week, month, or year |
| string array | No | All enabled | Narrow the request to enabled providers |
|
| No |
| Available only when Grok is enabled |
Example call:
{
"query": "GPU kernel generation papers from the past month",
"max_results": 5,
"time_range": "m",
"providers": ["ddgs", "exa"]
}Provider selection has two levels:
AGENT_WEB_SEARCH_PROVIDERSdefines the provider set when the process starts.The request-level
providersargument may narrow that set, but cannot enable a provider that was disabled at startup.
Response format
Each selected provider that succeeds appears under providers; failed
providers are omitted:
{
"query": "GPU kernel generation papers from the past month",
"providers": {
"ddgs": {
"results": [
{
"title": "Example result",
"url": "https://example.com/paper",
"description": "Excerpt of the matching page",
"published_at": "2026-08-02"
}
]
}
}
}Field | Meaning |
| Provider-generated prose answer, when the backend produces one; omitted otherwise |
| Result rows: |
If every selected provider fails, MCP returns a tool error. The CLI writes the
same payload to stderr and exits with status 1. Both use the stable code
all_providers_failed and include per-provider diagnostics:
{
"error": {
"code": "all_providers_failed",
"message": "All enabled search providers failed. Check provider configuration, credentials, quotas, and network access.",
"provider_errors": {
"ddgs": "RuntimeError: rate limited"
}
},
"query": "GPU kernel generation papers from the past month"
}Python API
The CLI, MCP servers, and Hermes plugin are thin wrappers around
agent_web_search.SearchEngine, which is the public Python API.
SearchRequest accepts the same fields as the MCP tool arguments:
from agent_web_search import SearchEngine, SearchRequest
engine = SearchEngine() # reads AGENT_WEB_SEARCH_* variables at construction
response = engine.search(
SearchRequest(query="latest MCP spec changes", max_results=5, time_range="m")
)
for name, provider in response.providers.items():
print(f"{name}: searched={provider.searched}, results={len(provider.results)}")
if response.all_providers_failed:
print(response.failed_provider_errors)Configuration
Configuration is read from environment variables when the CLI, MCP server, or Hermes plugin starts. Restart the process after changing provider settings. See .env.example for a commented template of every variable.
General settings
Variable | Default | Purpose |
|
| Comma-separated startup-enabled provider set |
|
| Socket timeout for a single upstream HTTP call. Multi-step providers multiply it: keyless Parallel makes up to 3 calls (worst case 3×), ARK may append a continuation call (worst case 2×), so the whole search can take up to |
Example:
export AGENT_WEB_SEARCH_PROVIDERS="ddgs,exa,brave"
export AGENT_WEB_SEARCH_TIMEOUT="30"$env:AGENT_WEB_SEARCH_PROVIDERS = "ddgs,exa,brave"
$env:AGENT_WEB_SEARCH_TIMEOUT = "30"HTTP transport settings
Variable | Default | Purpose |
|
|
|
|
| HTTP bind host for container deployments |
|
| HTTP bind port; explicit value overrides platform |
| — | Required HTTP Bearer Token, at least 32 characters |
|
| Explicitly disables HTTP auth for trusted/demo environments |
| — | Optional comma-separated Host allowlist |
| — | Optional comma-separated Origin allowlist; requires allowed hosts |
|
| Uvicorn log level for the container server |
HTTP settings remain environment-only; the deployment files do not introduce a second application configuration format.
Provider settings
Provider-specific settings below include the credential and model controls for all providers. The supported-provider overview above is grouped by capability; this section is the detailed configuration reference.
1. DDGS
DDGS uses DuckDuckGo and requires no API key or provider-specific environment
variables. The ddgs Python dependency is installed with the package.
2. Exa
Exa supports both paid and keyless modes.
Variable | Required | Purpose |
| No | Uses the paid Search API when present |
| No | Overrides the free MCP endpoint when no API key is set |
Without EXA_API_KEY, Exa falls back to its free MCP endpoint on a best-effort
basis. The paid API generally provides higher quota and reliability.
3. Parallel
Parallel returns information-dense excerpts ranked for LLM context. One
parallel provider automatically selects its transport:
Without a key, it uses Parallel's free Search MCP.
With
PARALLEL_API_KEY, it uses the paid Search REST API.
Both transports map excerpts into the common result description, so the
calling agent does not need to distinguish parallel-free from parallel.
Variable | Required | Purpose |
| No | Enables the paid API; omit it to use the free MCP |
Parallel is enabled by default and its key is optional.
4. ARK (Recommended)
Volcengine ARK uses model-backed search grounding through the Responses API.
Add ark to AGENT_WEB_SEARCH_PROVIDERS after providing the key.
Variable | Required | Purpose |
| Yes | One key, or multiple comma/newline-separated keys |
| No | Comma/newline-separated ARK model IDs |
One model stays fixed; multiple models are selected round-robin for successive requests. When multiple ARK keys are configured, a key is selected per request.
Agent Web Search does not require participation in a rewards program. ARK users may optionally review the official Volcengine Collaboration Rewards Program. Quota, supported models, validity periods, and data-authorization terms can change. Check the official terms before opting in. Participation is not required to use Agent Web Search.
5. Brave
Variable | Required | Purpose |
| Yes | Brave Web Search API credential |
Add brave to AGENT_WEB_SEARCH_PROVIDERS after providing the key.
6. Gemini
Variable | Required | Purpose |
| Yes | Google AI API credential |
| No | Comma/newline-separated Gemini model IDs |
Gemini maps common result and time controls into best-effort prompt constraints. One configured model stays fixed; multiple models are selected round-robin for successive requests.
7. Grok
Variable | Required | Purpose |
| Yes | xAI API credential |
| No | Comma/newline-separated Grok model IDs |
One configured model stays fixed; multiple models are selected round-robin for successive requests.
When Grok is enabled, the public tool schema adds grok_search_mode:
web_searchsearches the web.x_searchsearches X with native date filters when available.bothexposes both server-side tools in one request and lets Grok choose; it does not issue two independent model requests.
8. Codex Alpha (experimental)
The codex_alpha provider uses only a gateway API key and a complete endpoint
implementing /v1/alpha/search; it does not handle Codex OAuth tokens. Set the
endpoint, key, and optional model, then add codex_alpha to
AGENT_WEB_SEARCH_PROVIDERS:
Variable | Required | Purpose |
| Yes | Complete Alpha Search endpoint URL |
| Yes | Gateway Bearer API key |
| No | Model ID, default |
The provider sends a normal search_query command and returns standard web
search results.
9. DeepSeek
DeepSeek uses the official Anthropic-compatible Messages API and the native
web_search_20250305 server tool. It preserves the final model-generated text
and maps only explicit web_search_result blocks into normalized results. A
valid response may therefore have an answer with an empty results list.
Variable | Required | Purpose |
| Yes | DeepSeek API credential |
| No | Anthropic API base URL; defaults to |
| No | Comma/newline-separated model IDs; defaults to |
Add deepseek to AGENT_WEB_SEARCH_PROVIDERS after providing the key. The
provider appends /v1/messages to the configured base URL. Multiple models are
selected round-robin for successive requests.
10. Perplexity
This provider uses Perplexity's native structured Search API. It returns result rows rather than a Sonar-generated prose answer; OpenRouter compatibility is intentionally outside this provider's scope.
Variable | Required | Purpose |
| Yes | Perplexity Search API credential |
Add perplexity to AGENT_WEB_SEARCH_PROVIDERS after providing the key.
11. Tavily
Variable | Required | Purpose |
| Yes | Tavily Search API credential |
Add tavily to AGENT_WEB_SEARCH_PROVIDERS after providing the key.
12. You.com
You.com returns unified web and news sections. Agent Web Search merges both,
deduplicates URLs, and applies max_results to the combined result list.
Variable | Required | Purpose |
| Yes | You.com Search API credential |
Add you to AGENT_WEB_SEARCH_PROVIDERS after providing the key.
13. Zhipu Web Search
Zhipu Web Search uses the China standalone Web Search API and returns structured search rows. It is a separate Provider from Zhipu Chat Search; the implementation does not fall back between the two surfaces.
Variable | Required | Purpose |
| Yes | Zhipu Web Search API credential |
| No | China API base URL; defaults to |
Add zhipu_web_search to AGENT_WEB_SEARCH_PROVIDERS after providing the key.
The Provider appends /api/paas/v4/web_search to the configured base URL.
14. Zhipu Chat Search
Zhipu Chat Search uses the China GLM Chat Completions API with native web search. It returns the model answer plus only explicit top-level search rows; URLs mentioned in answer prose are not treated as citations. It is a separate Provider from Zhipu Web Search and has no API/Chat fallback.
Variable | Required | Purpose |
| Yes | Zhipu Chat Search API credential |
| No | China API base URL; defaults to |
| No | Comma/newline-separated GLM model IDs; defaults to |
Add zhipu_chat_search to AGENT_WEB_SEARCH_PROVIDERS after providing the key.
The Provider appends /api/paas/v4/chat/completions to the configured base URL.
Multiple configured models are selected round-robin for successive requests.
Common search controls
Each provider maps the shared controls to its native API when possible and ignores unsupported controls.
Provider |
|
|
DDGS | Native | Native |
Exa | Native result count | Native publish date |
Parallel | REST: native | Ignored |
ARK | Native | Prompt constraint |
Brave | Native | Native |
Gemini | Prompt constraint | Prompt constraint |
Grok | Prompt constraint | Prompt; X Search also uses native dates |
Codex Alpha | Local result truncation | Ignored |
DeepSeek | Local search-result truncation | Prompt constraint |
Perplexity | Native | Native recency filter |
Tavily | Native | Native |
You.com | Native | Native |
Zhipu Web Search | Native | Native recency filter |
Zhipu Chat Search | Native | Native recency filter |
Prompt-based controls are best-effort and are not strict guarantees.
Other interfaces
Native Hermes plugin
Install the native plugin directly from GitHub:
pip install 'ddgs>=9.0'
hermes plugins install JerryLiu369/agent-web-search --no-enable
hermes plugins enable agent-web-search --allow-tool-overrideThe plugin intentionally replaces Hermes' built-in web_search tool, so the
explicit --allow-tool-override grant is required. Start a new Hermes session
after enabling it; restart the gateway when using a messaging channel.
Hermes can also connect through its generic MCP integration instead of the native plugin.
Troubleshooting
all_providers_failed— every selected provider errored. MCP marks the call as an error; the CLI writes diagnostics to stderr and exits 1. Check keys, quotas, and network access. A single retry may help a transient limit.agent-web-searchis not found — install the PyPI package withpipxorpip, then start a new shell so its scripts directory is onPATH.HTTP 401
invalid_token— theAuthorization: Bearer …header must matchAGENT_WEB_SEARCH_AUTH_TOKEN, which must be at least 32 characters.A provider is missing from a response — failed providers are omitted from successful responses. The Python API exposes the reasons in
response.failed_provider_errors.Provider changes have no effect — provider settings are read once at startup; restart the CLI, MCP server, or Hermes plugin after changing them.
MCP client times out before the tool returns —
AGENT_WEB_SEARCH_TIMEOUTbounds a single upstream HTTP call, not the whole search. Keyless Parallel issues up to 3 calls and ARK may append a continuation request, so the worst case is3 × AGENT_WEB_SEARCH_TIMEOUT; configure your MCP client's tool timeout accordingly.
Development
Using uv keeps the development environment
isolated and reproducible:
git clone https://github.com/JerryLiu369/agent-web-search.git
cd agent-web-search
uv venv
uv pip install -e '.[dev]'
uv run pytest -q
uv run ruff check .python -m venv .venv
# Linux/macOS: source .venv/bin/activate
# Windows PowerShell: .venv\Scripts\Activate.ps1
python -m pip install -e '.[dev]'
pytest -q
ruff check .ARCHITECTURE.md is the design source of truth, and
AGENTS.md lists the non-negotiable invariants. Read both before
changing transports, configuration, authentication, deployment, providers, or
tool schemas, keep stdio and HTTP behavior identical, and keep pytest and
ruff green in the same change.
License
Available Tools
1 toolweb_searchA
Search the web through multiple providers. Enabled providers: DuckDuckGo web search; Exa web search; Parallel LLM-optimized web search. Use a complete natural-language question. Failed providers are omitted from successful responses. If every enabled provider fails, the call returns a tool error with code all_providers_failed and per-provider diagnostics.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A complete natural-language search question. | |
| providers | No | Optional subset of the providers enabled at startup. | |
| time_range | No | Optional time filter: past day, week, month, or year. | |
| max_results | No | Desired maximum number of results. Providers enforce this natively or as a best-effort prompt constraint. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden and does so well: it reveals that failed providers are omitted from successful responses and that total failure surfaces a specific error code all_providers_failed with per-provider diagnostics. It doesn't cover output shape or rate limits, but core operational behavior is disclosed.
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?
Four short sentences, each carrying unique information: purpose, provider list, query format, and failure semantics. It is front-loaded and free of filler.
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?
The description covers purpose, query format, providers, and failure behavior, which is enough for an agent to select and invoke the tool correctly. The absence of an output schema means the return format is not described, but this is a minor gap for a general search tool.
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%, so each parameter is already described in the input schema. The description adds a little by naming the providers and re-emphasizing the natural-language query style, but it doesn't materially enrich the meaning of time_range or max_results beyond their schemas.
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?
States a clear verb+resource: 'Search the web through multiple providers,' and enumerates the exact providers (DuckDuckGo, Exa, Parallel). Although there are no sibling tools, the description fully establishes what the tool does and its scope.
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?
It gives clear usage context—use a complete natural-language question—and explains provider/error behavior, so an agent knows how to frame calls. No sibling tools exist to contrast with, and no explicit when-not-to-use exclusion is provided, so it stops short of a 5.
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.7.2- Changed
web_search3 fields changed- removed
Input schema / properties / max_keywordRemoved value: -{ - "default": 3, - "description": "Desired maximum number of distinct search queries or keywords. Providers without an equivalent control ignore it.", - "maximum": 10, - "minimum": 1, - "type": "integer" -} - changed
Input schema / properties / max_results / descriptionPrevious value: -"Desired maximum number of results or cited sources. Providers enforce this natively or as a best-effort prompt constraint."New value: +"Desired maximum number of results. Providers enforce this natively or as a best-effort prompt constraint." - added
Input schema / properties / query / maxLengthAdded value: +4000
1 tool update
v0.3.0- Changed
web_search1 field changed- changed
Input schema / properties / providers / items / enumPrevious value: -[ - "ark", - "ddgs", - "exa" -]New value: +[ + "ddgs", + "exa", + "parallel" +]
1 tool update
v0.1.0- First observed
web_search
TDQS
Scored across 1 tool
There is only one tool, so there is no possibility of confusing it with another. The tool's purpose is clearly defined as web search.
The single tool name 'web_search' follows a clear verb_noun pattern. With only one tool, there are no inconsistencies to evaluate.
The server has only one tool, which feels thin for a typical toolset. However, the server is narrowly scoped to web search, so the single tool is reasonable, though borderline.
The web search tool covers the full domain by supporting multiple providers, natural-language queries, and graceful failure diagnostics. No obvious missing operations for a web-search-only server.
Maintenance
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.
Agent-native search engine with live web research optimized for AI agents.
Related MCP Servers
- AlicenseAqualityCmaintenanceProvides unified web search across multiple providers (Google, Tavily, DuckDuckGo, Brave) with automatic fallback, maximizing free API quota usage for AI workflows.1257MIT
- AlicenseAqualityDmaintenanceWeb search for AI agents across 6 engines (Serper, Brave, Exa, Tavily, Firecrawl, Perplexity) through one search tool. Routes each query to the cheapest engine that clears a quality bar and caches repeats. Hosted, streamable-HTTP, BYOK supported.11MIT
- AlicenseAqualityBmaintenanceEnables AI agents to perform unified web searches, GitHub, and GitLab searches with caching, reranking, and fallback across multiple providers.42218MIT
- FlicenseNot gradedqualityCmaintenanceA universal web search and content retrieval tool for AI agents, supporting multiple search providers and content extraction.-