MCP server for web search and URL/resource loading. It works without API keys by default and stays local-first: search uses free providers, fetch_url extracts useful content from URLs, and binary/media downloads only happen when explicitly requested.
search_web - multi-provider web search with automatic fallback across DuckDuckGo, Bing, and SearXNG.
fetch_url - universal URL/resource loader for HTML, PDF, text, Markdown, JSON, XML, CSV, media metadata, and supported site-specific URLs.
Clean normalized output with one content field plus metadata, pagination, links, media, attachments, and warnings.
Reddit thread extraction through Reddit JSON endpoints instead of brittle Reddit HTML scraping.
Long-resource pagination with max_length, start_index, and next_start_index.
Optional HTML link/media summaries.
Optional local download artifacts with download: true.
SSRF protection for localhost, private IPs, link-local ranges, IPv6 private ranges, and unsafe redirects.
No paid API required.
Related MCP server: tavily-mcp
Node.js 18+
Chrome/Chromium only if you use the Bing provider
{
"mcpServers": {
"web-search": {
"command": "npx",
"args": ["-y", "@zhafron/mcp-web-search"]
}
}
}{
"mcp": {
"web-search": {
"type": "local",
"command": ["npx", "@zhafron/mcp-web-search"]
}
}
}{
"mcpServers": {
"web-search": {
"command": "npx",
"args": ["-y", "@zhafron/mcp-web-search"],
"env": {
"DEFAULT_SEARCH_PROVIDER": "duckduckgo",
"SEARXNG_URL": "http://localhost:8099"
}
}
}
}Search the web through one provider or through the fallback chain.
Input:
{
"q": "openai codex reddit review",
"limit": 10,
"lang": "en",
"provider": "duckduckgo"
}Options:
Option | Description |
| Search query |
| Number of results, 1-50 |
| Search language, default |
| Optional provider: |
Output:
{
"items": [
{
"title": "Example Result",
"url": "https://example.com",
"snippet": "Result summary...",
"source": "duckduckgo"
}
],
"providerUsed": "duckduckgo",
"fallbackUsed": false,
"triedProviders": ["duckduckgo"]
}Fallback order:
DuckDuckGo → SearXNG → Bing
SearXNG → DuckDuckGo → Bing
Bing → DuckDuckGo → SearXNG
Fetch a URL and return extracted content plus metadata in a normalized envelope.
Input:
{
"url": "https://example.com/article",
"format": "markdown",
"max_length": 8000,
"start_index": 0,
"include_links": true,
"include_media": true
}Options:
Option | Description |
| URL to fetch |
|
|
| Maximum returned content characters, default 25000 |
| Start content from this character index |
|
|
| Include extracted links for HTML pages |
| Include extracted image/video/audio references for HTML pages |
| Include comments for site adapters that support comments, default true for Reddit |
| Maximum comments for comment-capable adapters, max 100 |
|
|
| Maximum comment nesting depth |
| Request timeout override |
| Bypass in-memory cache |
| Save original fetched bytes to a managed local file and return it in |
| Optional output directory for downloads; defaults to the system temp directory |
| Cleanup TTL for managed downloads, default 86400 seconds |
| Response/download byte cap override, additionally capped by |
Output:
{
"url": "https://example.com/article",
"final_url": "https://example.com/article",
"title": "Example Article",
"content_type": "text/html",
"resource_type": "html",
"format": "markdown",
"content": "# Example Article\n\n...",
"metadata": {
"status": 200,
"content_type": "text/html",
"byte_length": 12345,
"extractor": "html",
"fetched_at": "2026-05-03T00:00:00.000Z"
},
"links": [],
"media": {
"images": [],
"videos": [],
"audio": []
},
"truncated": false,
"original_length": 1200,
"start_index": 0,
"next_start_index": null,
"warnings": []
}Resource | Behavior |
HTML pages | Extracts readable article content, title, metadata, optional links, and optional media references |
Text and Markdown | Returns text directly with pagination support |
JSON | Pretty-prints JSON when |
XML and CSV-like text | Returns as text/data content |
Extracts text and PDF metadata | |
Images | Returns metadata by default; saves the file only with |
Audio and video | Returns metadata by default; saves the file only with |
Archives and binary files | Returns metadata by default; downloads only when explicitly requested; archives are not auto-extracted |
Reddit threads | Uses Reddit JSON endpoints and can include comments with limits |
fetch_url does not download binary/media files to disk by default. This avoids surprise disk usage and persistent local copies of arbitrary web content.
Use download: true when you need the original file available to another tool:
{
"url": "https://httpbin.org/image/png",
"format": "metadata",
"download": true,
"download_ttl_seconds": 86400
}Download attachments look like this:
{
"kind": "download",
"path": "/tmp/mcp-web-search/downloads/mcp-fetch-id-image.png",
"filename": "mcp-fetch-id-image.png",
"original_filename": "image.png",
"content_type": "image/png",
"resource_type": "image",
"byte_length": 8090,
"sha256": "...",
"expires_at": "2026-05-04T00:00:00.000Z"
}Download safety behavior:
Downloads are opt-in only.
Files are written with 0600 permissions.
Filenames are sanitized and prefixed with a managed artifact ID.
SHA-256 is returned for verification.
Expired managed artifacts are cleaned up through sidecar metadata.
Cleanup only touches managed artifacts inside the configured download directory.
Archives are never auto-extracted.
Reddit thread URLs are handled by a site adapter and fetched through Reddit JSON endpoints.
Input example:
{
"url": "https://www.reddit.com/r/codex/comments/abc123/gpt55_is_so_good/",
"include_comments": true,
"comment_limit": 30,
"comment_sort": "top",
"max_depth": 2
}The output uses resource_type: "site" and metadata.extractor: "reddit-thread".
Reddit public JSON can still rate-limit or return 403/429 depending on Reddit, subreddit rules, and request frequency. When that happens, retry later or reduce request frequency.
Provider | API Key Required | Notes |
DuckDuckGo | No | Default, simple, no browser required |
Bing | No | Uses Chrome/Chromium through Puppeteer |
SearXNG | No | Best option for self-hosted high-volume usage |
Variable | Default | Description |
|
| Default search provider: |
|
| SearXNG instance URL |
|
| Request timeout in milliseconds |
|
| Maximum fetched response/download size |
| unset | Set to |
SearXNG is a free self-hosted meta-search engine.
Quick setup with Docker:
mkdir -p ~/docker/searxngCreate ~/docker/searxng/settings.yml with JSON enabled, then run the SearXNG container. The important setting is search.formats containing both html and json.
Example relevant setting:
search:
formats:
- html
- jsonThen set:
export SEARXNG_URL="http://localhost:8099"OS | Command |
Ubuntu/Debian |
|
Fedora |
|
Arch |
|
macOS |
|
Custom path:
export CHROME_PATH="/path/to/chrome"Some MCP clients have weak schema parsers and fail during discovery on array-valued JSON Schema nodes such as enum or required.
If discovery fails, set:
export MCP_COMPAT_MODE="legacy"This only simplifies advertised tools/list schemas. Tool execution behavior stays the same.
fetch_url blocks unsafe targets before fetching and before following redirects.
Blocked targets include:
localhost hostnames
.localhost and .local hostnames
private IPv4 ranges
IPv4 loopback, link-local, carrier-grade NAT, benchmark, multicast, and selected special-use ranges
IPv4-mapped IPv6 addresses that resolve to blocked IPv4 ranges
IPv6 loopback, unspecified, unique-local, multicast, and link-local ranges
redirects that resolve to blocked addresses
The HTTP transport resolves and validates addresses before connecting, then connects to the vetted address while preserving the original host/SNI for normal HTTPS behavior.
src/server.ts - MCP server and tool schemas
src/providers/ - search providers
src/fetch/ - URL/resource loading pipeline
src/fetch/content/ - shared content helpers such as Markdown conversion and readability fallback
src/fetch/extractors/ - resource extractors for HTML, text/data, PDF, and media metadata
src/fetch/site-adapters/ - domain-specific extractors such as Reddit threads
src/utils/ - shared utilities
test/ - Node test runner tests
Issue | Solution |
Chrome not found | Install Chrome/Chromium or set |
SearXNG 403 | Enable JSON API in |
Timeout | Increase |
MCP discovery error: | Set |
Reddit 429 or 403 | Reddit rate limited or blocked the JSON endpoint; retry later or reduce request frequency |
Download missing from output | Set |
Download rejected as too large | Increase |
MIT
Fetches content from a URL (HTML/PDF) and extracts readable text. Supports truncation modes: compact (~3000 chars), standard (~8000 chars, default), full (no truncation). Output formats: markdown (default), text, html.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| mode | No | ||
| max_length | No | ||
| format | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and discloses key behavioral traits: it describes truncation modes with character limits, default settings (standard mode, markdown format), and output formats. However, it lacks details on error handling, rate limits, or authentication needs.
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 front-loaded with the core purpose, followed by specific features in a structured list. Every sentence adds value without redundancy, making it efficient and easy to parse.
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 no annotations and no output schema, the description provides good coverage of the tool's behavior and parameters. It could be more complete by addressing error cases or response structure, but it adequately supports the 4-parameter input schema and distinguishes from siblings.
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 0%, so the description compensates by explaining the semantics of 'mode' (truncation options with character estimates) and 'format' (output formats with default). It does not cover 'max_length' or 'url' beyond what the schema implies, but adds meaningful context for two parameters.
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 specific action ('fetches content from a URL and extracts readable text'), identifies the resource (URL content), and distinguishes from siblings by specifying content types (HTML/PDF) and extraction focus, unlike search_web or summarize_url which imply different operations.
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?
The description implies usage for fetching and extracting text from URLs, but does not explicitly state when to use this tool versus alternatives like search_web (likely for broader web searches) or summarize_url (likely for summarization). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Two-tier web search: runs fast DuckDuckGo HTML search by default, escalates to Puppeteer/Bing if results are insufficient. No API keys required.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| limit | No | ||
| lang | No | en | |
| mode | No | auto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: the two-tier architecture, default behavior (fast first), escalation conditions, and that 'No API keys required' (important authentication context). It doesn't mention rate limits or error handling, keeping it from a perfect score.
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 extremely efficient - just two sentences that pack essential information about the tool's architecture, default behavior, escalation logic, and authentication requirements. Every word earns its place with no wasted text.
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?
For a 4-parameter search tool with no annotations and no output schema, the description covers the behavioral architecture well but leaves significant gaps: no explanation of what the search returns, no parameter semantics, and no error handling information. It's adequate for basic understanding but incomplete for full operational context.
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?
With 0% schema description coverage, the description doesn't explain any of the 4 parameters beyond what's implied by 'mode' (fast/deep/auto). It doesn't clarify what 'q', 'limit', or 'lang' represent, though the schema provides constraints. The description adds minimal value beyond the schema's structural information.
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 tool performs 'Two-tier web search' with specific implementations (DuckDuckGo and Puppeteer/Bing), distinguishing it from sibling tools like fetch_url (single URL retrieval) or wiki_get (Wikipedia-specific). It specifies the verb 'search' and resource 'web' with implementation details.
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?
The description provides clear context about when to use different modes (fast vs deep) and the default escalation behavior, but doesn't explicitly state when to use this tool versus alternatives like fetch_url or wiki_get. It mentions 'if results are insufficient' as a trigger for escalation, giving practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches content from a URL and generates a concise summary.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states basic functionality. It doesn't disclose behavioral traits such as rate limits, authentication needs, content type handling, error conditions, or summary length/format. This is inadequate for a tool that fetches external content.
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, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for a simple tool.
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 no annotations, no output schema, and low schema coverage, the description is incomplete. It lacks details on summarization behavior (e.g., length, style), error handling, or output format, which are critical for an AI agent to use this tool effectively.
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 0%, so the description must compensate but only mentions 'url' generically. It adds no meaning beyond the schema's basic type/format, such as URL validation rules, supported protocols, or content restrictions. Baseline 3 is appropriate as the schema defines the parameter minimally.
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 tool's purpose with specific verbs ('fetches content', 'generates a concise summary') and identifies the resource (URL content). It distinguishes from 'fetch_url' by adding the summarization aspect, though it doesn't explicitly differentiate from all siblings like 'search_web' or 'wiki_get'.
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?
No guidance is provided on when to use this tool versus alternatives like 'fetch_url' (which might fetch without summarizing) or 'search_web' (which might search multiple sources). The description implies usage for URL summarization but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves a Wikipedia summary for a given title. Supports multiple languages (default: en).
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| lang | No | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool retrieves a summary and supports multiple languages, but lacks details on error handling, rate limits, authentication needs, or what constitutes a 'summary' (e.g., length, format). This is a significant gap for a tool with no annotation coverage.
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, efficient sentence that front-loads the core purpose and includes essential details (language support and default). There is no wasted text, making it highly concise and well-structured.
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 low complexity, no annotations, no output schema, and 2 parameters with 0% schema coverage, the description is minimally adequate. It covers the basic purpose and parameters but lacks behavioral context and output details, leaving room for improvement in completeness.
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 schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'title' is for the Wikipedia article and 'lang' specifies language with a default of 'en', which clarifies beyond the bare schema. However, it doesn't detail parameter constraints (e.g., valid language codes) or usage nuances, leaving some gaps.
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 tool's purpose with a specific verb ('Retrieves') and resource ('Wikipedia summary'), and identifies the key input ('given title'). It doesn't explicitly differentiate from sibling tools like 'wiki_multi', but the purpose is unambiguous.
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?
The description implies usage for Wikipedia summaries and mentions language support, but provides no explicit guidance on when to use this tool versus alternatives like 'wiki_multi' or 'search_web'. The context is clear but lacks comparative or exclusionary advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves Wikipedia summaries in multiple languages for a given term. Uses langlinks to map titles accurately across languages.
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | ||
| baseLang | No | en | |
| langs | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'langlinks to map titles accurately' which adds useful context about title resolution behavior, but doesn't describe error handling, rate limits, authentication needs, response format, or what happens when languages aren't available. For a 3-parameter tool with no annotation coverage, this leaves significant behavioral gaps.
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?
Two concise sentences with zero waste. First sentence states core functionality, second adds important implementation detail about title mapping. Every word earns its place, and the description is appropriately front-loaded with the main purpose.
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?
For a 3-parameter tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain the return format (what 'summaries' look like), error conditions, parameter interactions, or practical usage examples. The langlinks mention is helpful but doesn't compensate for the overall lack of operational context.
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 0%, so the schema provides no parameter documentation. The description mentions 'term' and implies language parameters through 'multiple languages' and 'langlinks', but doesn't explain what 'baseLang' and 'langs' represent, their format (language codes), or how they interact. It adds minimal semantic value beyond what can be inferred from parameter names.
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 specific action ('Retrieves Wikipedia summaries') and resource ('for a given term'), with explicit scope ('in multiple languages'). It distinguishes from sibling 'wiki_get' by specifying multi-language capability and mentioning 'langlinks' for cross-language title mapping.
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?
The description implies usage context through 'multi-language' and 'langlinks' terminology, suggesting this is for cross-lingual Wikipedia lookups. However, it doesn't explicitly state when to use this versus alternatives like 'wiki_get' or 'search_web', nor does it provide exclusion criteria or comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes: fetch_url extracts content, search_web performs web searches, summarize_url summarizes content, and wiki_get/wiki_multi retrieve Wikipedia data. However, fetch_url and summarize_url both fetch content from URLs, which could cause minor confusion about when to use each, though their outputs differ (raw content vs. summary).
All tool names follow a consistent snake_case pattern with clear verb_noun structures: fetch_url, search_web, summarize_url, wiki_get, and wiki_multi. This predictability makes it easy for agents to understand and select tools without naming confusion.
With 5 tools, this server is well-scoped for its web calculation and information retrieval purpose. Each tool serves a specific function (e.g., fetching, searching, summarizing, Wikipedia access), and none appear redundant or excessive, fitting typical expectations for such a domain.
The tool set covers key web-based operations: content fetching, web searching, summarization, and Wikipedia access. Minor gaps exist, such as no explicit tools for updating or deleting data, but this is reasonable given the server's focus on retrieval and analysis. Agents can likely work around this with the provided tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Hosted MCP server for live public-data APIs and Skills for AI agents.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tickernelz/mcp-web-search'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
