agent-web-search
Agent Web Search
Búsqueda web multiproveedor para agentes de IA.
Agent Web Search ofrece a Hermes, Codex CLI, Claude Code, OpenCode y scripts ordinarios una herramienta de búsqueda web coherente. Ejecuta proveedores independientes de forma concurrente y devuelve resultados normalizados. El conjunto de proveedores predeterminado es:
ARK grounding — Volcengine ARK Responses API +
web_search(Doubao)DDGS — Búsqueda de DuckDuckGo
Exa — Búsqueda Exa MCP (mejor esfuerzo; la disponibilidad depende del endpoint)
También se implementan proveedores opcionales:
Gemini — Google Search grounding mediante Gemini Interactions API
Grok — xAI Responses API con búsqueda web nativa y X Search
Tavily — Tavily Search API con filtros nativos de recuento de resultados y rango de fechas
La arquitectura está basada en proveedores, por lo que se pueden añadir DeepSeek, Brave y otros proveedores con capacidad de búsqueda sin cambiar las interfaces MCP o Hermes.
Inicio rápido
# Omit this line when the ARK provider is not enabled.
export ARK_API_KEY="your_ark_api_key"
pipx install 'git+https://github.com/JerryLiu369/agent-web-search.git'
agent-web-search-mcpNo pongas claves de API en el historial del shell, el código fuente, los commits de Git ni las capturas de pantalla. Usa un gestor local de .env/secretos y exporta la variable en el entorno del proceso.
Related MCP server: GroundRoute
Uso desde Codex CLI
export ARK_API_KEY="your_ark_api_key"
codex mcp add agent-web-search -- \
agent-web-search-mcp
codex mcp listUso desde Claude Code
export ARK_API_KEY="your_ark_api_key"
claude mcp add agent-web-search -- \
agent-web-search-mcpO añade un .mcp.json de proyecto:
{
"mcpServers": {
"agent-web-search": {
"command": "agent-web-search-mcp",
"args": [],
"env": {"ARK_API_KEY": "${ARK_API_KEY}"}
}
}
}Uso desde OpenCode
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"agent-web-search": {
"type": "local",
"command": ["agent-web-search-mcp"],
"environment": {"ARK_API_KEY": "${ARK_API_KEY}"},
"enabled": true
}
}
}Uso desde Hermes
Instala el plugin nativo directamente desde GitHub:
pip install 'ddgs>=9.0'
hermes plugins install JerryLiu369/agent-web-search --no-enable
hermes plugins enable agent-web-search --allow-tool-overrideEl plugin registra la herramienta estándar web_search y llama al mismo núcleo de Agent Web Search que usan MCP y CLI. Si prefieres la ruta MCP genérica, Hermes también puede conectarse con hermes mcp add.
El instalador de GitHub instala el paquete y sus dependencias opcionales:
pipx install 'git+https://github.com/JerryLiu369/agent-web-search.git'Hermes requiere la concesión explícita --allow-tool-override porque este plugin reemplaza intencionadamente su herramienta integrada web_search. Inicia una nueva sesión de Hermes después de habilitarlo; reinicia la puerta de enlace si usas un canal de mensajería.
CLI
agent-web-search "What changed in the latest OpenAI Codex CLI?"
agent-web-search "GPU kernel generation papers from the past month" --time-range m --max-results 5
agent-web-search "latest news" --provider ark --provider ddgsRecompensas de colaboración de Volcengine
Agent Web Search no requiere participar en ningún programa de recompensas. Los usuarios que decidan usar ARK pueden crear su propia clave de API y, opcionalmente, revisar el Programa de recompensas de colaboración de Volcengine oficial. El programa puede proporcionar recursos de recompensa según sus reglas actuales, pero la cuota, los modelos compatibles, el período de validez y los términos de autorización de datos pueden cambiar. Consulta la página oficial antes de aceptar. La participación implica aceptar los términos de autorización de datos del proveedor; no es necesario para usar Agent Web Search.
Configuración
ARK_API_KEY: opcional; solo se requiere cuando el proveedor ARK está habilitado. Se aceptan claves separadas por comas/saltos de línea.AGENT_WEB_SEARCH_PROVIDERS: conjunto de proveedores habilitados al inicio; el valor predeterminado esark,ddgs,exa.AGENT_WEB_SEARCH_TIMEOUT: tiempo de espera por proveedor en segundos (predeterminado60).AGENT_WEB_SEARCH_ARK_MODELS: IDs de modelo ARK separados por comas.EXA_MCP_URL: anulación opcional del endpoint Exa MCP.GEMINI_API_KEY: clave opcional del proveedor Gemini.AGENT_WEB_SEARCH_GEMINI_MODEL: ID de modelo Gemini opcional.XAI_API_KEY: clave opcional del proveedor Grok.AGENT_WEB_SEARCH_GROK_MODEL: ID de modelo Grok opcional.TAVILY_API_KEY: clave opcional del proveedor Tavily.
El conjunto de proveedores se resuelve cuando se inicia el plugin de Hermes o el servidor MCP. El esquema público web_search se genera a partir de ese conjunto. Una solicitud puede reducir el conjunto con providers, pero no puede activar un proveedor que se deshabilitó al inicio. Si grok está habilitado al inicio, el esquema también expone grok_search_mode con los valores web_search, x_search y both. both pasa ambas herramientas del lado del servidor de xAI en una sola solicitud y deja que Grok decida cuál llamar; no envía dos solicitudes independientes.
Controles de búsqueda comunes
La interfaz pública mantiene un conjunto de controles neutrales para el proveedor. Cada backend los asigna a su API nativa cuando es posible e ignora silenciosamente los controles no compatibles:
Control | ARK | DDGS | Exa | Gemini / Grok | Tavily |
| nativo | nativo | nativo | restricción de prompt en inglés | nativo |
| nativo | ignorado | ignorado | restricción de prompt en inglés | ignorado |
| restricción de prompt en inglés | nativo | filtro de fecha de publicación nativo | Gemini: prompt; Grok web: prompt; Grok X: fechas nativas + prompt | nativo |
Las restricciones de prompt son de mejor esfuerzo para los proveedores respaldados por modelos; no se presentan como garantías estrictas.
Principios de diseño
Un núcleo, múltiples adaptadores.
Un proveedor con fallo no descarta a los proveedores que tuvieron éxito.
Las respuestas de los proveedores se marcan con
searched,errorymodelen lugar de fingir que cada HTTP 200 fue una búsqueda exitosa.Sin telemetría y sin servicio compartido de claves de API.
Desarrollo
python -m venv .venv
. .venv/bin/activate
pip install -e '.[dev,ddgs,mcp]'
pytest -q
ruff check .Licencia
MIT.
Available Tools
1 toolweb_searchA
Search the web using agent-native semantic search and LLM-grounding backends. Optimized for complete natural-language questions rather than traditional keyword queries. 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, detailed natural-language question or intent. Do NOT use fragmented keyword queries (e.g. avoid 'NVDA earnings'); instead pass the full question (e.g. 'What were the key highlights and market reactions to NVIDIA latest earnings?'). Model-native and semantic providers reason over full sentences to retrieve, read, and synthesize grounded evidence. | |
| 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?
No annotations are present, so the description carries the full burden, and it delivers real behavioral detail: failed providers are silently dropped from successful responses, and total failure surfaces as a tool error with code all_providers_failed plus per-provider diagnostics. It does not disclose result ordering, latency, rate limits, or the shape of successful results.
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?
Front-loaded with purpose and provider list, then failure semantics, with every sentence carrying content. Slightly dense in the middle where the natural-language guidance is repeated from the schema, which is mild redundancy rather than padding.
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?
With no output schema, the description would ideally explain the return structure; it hints at aggregation ('omitted from successful responses') and error diagnostics but never describes what a successful result contains. For a multi-provider aggregation tool this is a modest gap, offset by unusually thorough failure-mode disclosure.
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 description coverage is 100%, so all four parameters are already documented, including the natural-language versus keyword guidance and the providers enum. The description largely restates what the schema's query description already says, adding the provider names but no new parameter-level semantics. Baseline 3 is appropriate.
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 specific verb+resource ('Search the web') and immediately qualifies it with the mechanism (agent-native semantic search and LLM-grounding backends) plus the three concrete providers enabled (DuckDuckGo, Exa, Parallel). An agent knows exactly what this does without opening the schema.
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?
Gives an explicit usage instruction repeated twice ('Use a complete natural-language question', 'Optimized for complete natural-language questions rather than traditional keyword queries'), which steers invocation strongly. There are no sibling tools, so no when-not-to-use or alternative routing exists to state; the only gap is that exclusions are impossible to provide.
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.8.0- Changed
web_search2 fields changed- changed
Input schema / properties / max_results / defaultPrevious value: -10New value: +5 - changed
Input schema / properties / query / descriptionPrevious value: -"A complete natural-language search question."New value: +"A complete, detailed natural-language question or intent. Do NOT use fragmented keyword queries (e.g. avoid 'NVDA earnings'); instead pass the full question (e.g. 'What were the key highlights and market reactions to NVIDIA latest earnings?'). Model-native and semantic providers reason over full sentences to retrieve, read, and synthesize grounded evidence."
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
With only one tool in the set, there is no possibility of confusing it with another tool. Its purpose—semantic web search for natural-language questions—is unambiguous and clearly stated.
The single tool uses a clean snake_case verb_noun name (web_search) that is readable and conventional. No competing conventions exist to create inconsistency.
A search server can legitimately be a one-tool server, so the scope is defensible. However, a single tool is thin for a search surface that could reasonably offer companion operations (e.g., page fetch/retrieval), placing it at the borderline end of the rubric.
Search itself is well covered, including multi-provider fallback and diagnostics, but the lifecycle dead-ends there: an agent getting only snippets has no tool to retrieve or read a specific result page. This is a notable gap an agent must work around.
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.124 npm7MIT
- 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
- AlicenseAqualityCmaintenanceEnables AI agents to perform unified web searches, GitHub, and GitLab searches with caching, reranking, and fallback across multiple providers.413 npm18MIT
- FlicenseNot gradedqualityDmaintenanceA universal web search and content retrieval tool for AI agents, supporting multiple search providers and content extraction.-