web-tools-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PROXY_URL | No | Proxy URL for direct fetches. Format: http://user:pass@host:port or socks5://user:pass@host:port | |
| HTTP_PROXY | No | Alternative to PROXY_URL (standard env var) | |
| HTTPS_PROXY | No | Alternative to PROXY_URL (standard env var) | |
| JINA_API_KEY | No | Jina Reader API key for higher rate limits. Free tier works without it. | |
| BRAVE_API_KEY | Yes | Brave Search API subscription token |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| web_searchA | Search the web using the Brave Search API. Returns titles, URLs, descriptions, and snippets. This tool replaces the native web_search with anti-detection capabilities — queries go through the Brave Search API with your own API key, avoiding IP blocks. Args:
Returns: Search results with title, url, description for each result. Includes extra_snippets when available. Examples:
|
| web_fetchA | Fetch the contents of a web page with anti-detection capabilities. This tool replaces the native web_fetch. It uses rotating real-browser user agents, optional proxy (Bright Data or any HTTP/SOCKS5), and automatic fallback to Jina Reader API for sites that block direct access. Three fetch strategies:
For fetching multiple URLs at once, use web_bulk_fetch instead — it's faster and uses a single tool call. Args:
Returns: Page content (HTML for direct, markdown for Jina), HTTP status, final URL after redirects, and which strategy was used. |
| web_bulk_fetchA | Fetch multiple URLs in parallel with anti-detection capabilities. Much faster than calling web_fetch multiple times. Use this after web_search to fetch the top 3-4 results in a single call instead of making separate web_fetch calls. Args:
Returns: Combined results for all URLs, each with page content, HTTP status, strategy used, and content size. Failed URLs are clearly marked. Example: urls=["https://docs.python.org/3/library/asyncio.html", "https://nodejs.org/en/docs/guides/event-loop"] |
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_fetch retrieves a single page, web_bulk_fetch retrieves multiple pages in parallel, and web_search performs a web search. There is no overlap between these operations; even web_fetch and web_bulk_fetch are clearly differentiated by the number of URLs they handle.
All tool names follow a consistent verb_noun pattern with a web_ prefix: web_fetch, web_search, web_bulk_fetch. The naming is predictable and clearly indicates the action and resource, with 'bulk' correctly modifying the fetch verb.
With only three tools, the set is well-scoped for a web utility server. Each tool covers a distinct primary use case (single fetch, bulk fetch, search), and the size is appropriate without being bloated or too sparse.
The tool surface covers the core operations for the domain: searching the web and fetching one or multiple pages, with strategy options (auto/direct/jina) for different anti-blocking needs. No obvious gaps for typical web research workflows, as pagination via count/offset is available in web_search.