Universal Web Retrieval MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TAVILY_API_KEY | No | Tavily keyed mode; absent → official keyless (X-Tavily-Access-Mode: keyless) | |
| ANYSEARCH_API_KEY | No | AnySearch keyed mode; absent → official keyless | |
| WEB_RETRIEVAL_TIMEOUT | No | Overall chain deadline in seconds (default 45) | 45 |
| WEB_RETRIEVAL_LOG_LEVEL | No | Log level; logs go to stderr (stdout is MCP JSON-RPC) | WARNING |
| WEB_RETRIEVAL_MAX_RESULTS | No | Cap for web_search.limit (default 20) | 20 |
| WEB_RETRIEVAL_DDGS_TIMEOUT | No | DDGS overall timeout in seconds (default 15s) | 15 |
| WEB_RETRIEVAL_TAVILY_TIMEOUT | No | Tavily read timeout in seconds (default 20s) | 20 |
| WEB_RETRIEVAL_ANYSEARCH_TIMEOUT | No | AnySearch read timeout in seconds (default 20s) | 20 |
| WEB_RETRIEVAL_EXTRACT_CHAR_LIMIT | No | Max fetched-content chars (default 15000) | 15000 |
| WEB_RETRIEVAL_TAVILY_CONNECT_TIMEOUT | No | Tavily connect timeout in seconds (default 5s) | 5 |
| WEB_RETRIEVAL_ANYSEARCH_CONNECT_TIMEOUT | No | AnySearch connect timeout in seconds (default 5s) | 5 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| web_searchA | Web search through a configurable provider chain with automatic failover. Two modes: |
| web_fetchA | Fetch one URL's page content as Markdown with automatic provider failover (default: AnySearch -> Tavily -> DDGS.extract; operators can reorder the chain with UWR_FETCH_CHAIN). Auth is automatic (keyed when a key is configured, else official keyless). Accepts a single url string, or urls array (max 5) for batch. |
| list_providersA | List every provider this server knows: capabilities (search/fetch), whether it is usable right now (configured / key present), whether it is enabled, and its 1-based position in each active chain. Also reports the active search mode (failover/fanout) and the fan-out fan width/grace. Never returns key values. Use it to decide what to pass in web_search/web_fetch |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool has a distinct purpose: web_search performs search, web_fetch retrieves page content, and list_providers reports provider/chain metadata. There is no overlap that would cause an agent to reasonably choose the wrong tool.
The names are in readable snake_case with verb_noun structure for web_search and web_fetch, while list_providers slightly deviates by omitting the web_ prefix. The inconsistency is minor and does not impair predictability.
Three tools are well-scoped for a web retrieval server: one for search, one for fetching, and one for provider discovery. Each earns its place without redundant surface area.
The core lifecycle of discovering providers, searching, and fetching content is covered. Minor gaps remain around dedicated provider health checks, richer extraction options, or batch search, but agents can work around them.