What can you do with this server?

This server provides advanced web search, URL fetching, and deep research capabilities for MCP clients. Key tools: * web_search: Search across 6 engines (DuckDuckGo, Bing, BingCN, Baidu, Sogou, 360) with automatic language-based engine selection or manual override (including engine='all'). Returns up to 30 results per engine (default 8), cached with frequency‑aware TTLs (e.g., 30 min for search pages). * fetch_url: Fetch any URL and return clean markdown (default up to 16,000 chars, max 50,000), with boilerplate removed. Automatically routes CN domains directly and international domains through a proxy. Falls back to TLS/JA3 fingerprint impersonation (via curl_cffi) when sites return 403 (e.g., Cloudflare-protected pages). * deep_research: Conduct thorough multi‑engine research. Fans out queries across engines, deduplicates results using exact URL matching and SimHash near‑duplicate detection, ranks merged results with Reciprocal Rank Fusion (RRF), fetches the top‑K pages (default 4, max 10), and synthesizes a cited markdown report. Configurable per‑engine result count (up to 20) and fetch character limit (up to 20,000). Additional features include per‑host token bucket rate limiting with exponential backoff to defeat anti‑bot measures, and proxy/cache settings configurable via environment variables.

Which integrations are available for this server?

Allows performing web searches using Baidu, optimized for Chinese-language queries. Allows performing web searches using DuckDuckGo, returning relevant results and links. Allows performing web searches using Sogou, with support for Chinese-language queries.

How do I use Web Search MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Web Search MCP Server deep research on the impact of AI on software development" 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.

Web Search MCP Server

by nuoyax

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

web-search MCP server

A self-hosted web search MCP server for Claude Code / any MCP client. Multi-engine (CN-direct + international-via-proxy auto-routing), three tools, and research-backed optimizations: RRF rank fusion, SimHash near-duplicate dedup, per-host rate limiting, frequency-aware caching, and TLS/JA3 fingerprint impersonation fallback.

中文文档

Installation

Prerequisites

Node.js ≥ 18
Python 3 + curl_cffi (optional, for TLS impersonation on protected sites):
```
pip install curl_cffi
```
A proxy on 127.0.0.1:7890 (e.g) — set PROXY_URL="" to disable.

Build

git clone git@github.com:nuoyax/web-search-mcp.git
cd web-search-mcp
npm install

Wire into Claude Code

User-level (available in all projects):

claude mcp add web-search -s user -e PROXY_URL=http://127.0.0.1:7890 \
  -- node /absolute/path/to/web-search-mcp/index.js

Or add to .mcp.json (project-level):

{
  "mcpServers": {
    "web-search": {
      "command": "node",
      "args": ["/absolute/path/to/web-search-mcp/index.js"],
      "env": { "PROXY_URL": "http://127.0.0.1:7890" }
    }
  }
}

Verify

node index.js          # start the MCP server (stdio)
node test-smoke.js     # smoke test every engine + fetch

(Recommended) Disable Claude Code's built-in `WebFetch`

Claude Code ships a built-in WebFetch tool that fetches via claude.ai's server-side domain-safety check. On a restricted network it errors with Unable to verify if domain … is safe to fetch … blocking claude.ai, and it can't use your proxy. Since this server's fetch_url already fetches through 127.0.0.1:7890 (and TLS-impersonates on 403), disable the built-in one so Claude always uses fetch_url.

Add WebFetch to permissions.deny in ~/.claude/settings.json (global, all projects):

{
  "permissions": {
    "deny": ["WebFetch"]
    // also common: "WebSearch" if you want web_search to fully replace it
  }
}

Or, project-only — D:\agents\web_search\.claude\settings.local.json (gitignored):

{ "permissions": { "deny": ["WebFetch"] } }

deny rules stack across the user → project → local layers and are honored even in bypassPermissions mode. Restart Claude Code after editing. Verify with /permissions.

Related MCP server: serp-it

Highlights

6 engines — DuckDuckGo / Bing (international, via proxy) + Bing CN / Baidu / Sogou / 360 (direct). Auto-selected by query language.
3 tools — web_search, fetch_url, deep_research (multi-engine fan-out → dedup → rank → fetch → cited report)
Auto proxy routing — CN hosts go direct, international hosts go through 127.0.0.1:7890; re-decided per redirect hop.
RRF rank fusion (k=60) across engines — robust without score normalization.
SimHash dedup — 64-bit, Hamming ≤ 3, merges syndicated copies across hosts.
Per-host token bucket + exponential backoff — defeats frequency-based anti-bot detection.
Disk cache with frequency-aware TTL (search 30 min / news 1 h / docs 7 d).
TLS/JA3 impersonation via curl_cffi for Cloudflare-protected sites (e.g. docs.anthropic.com).

Architecture

flowchart TB
    Client["Claude Code / MCP Client\n(stdio · JSON-RPC)"]

    subgraph Server["web-search MCP Server  (index.js)"]
        T1["web_search"]
        T2["fetch_url"]
        T3["deep_research"]
        Cache["cache.js\n disk KV · frequency-aware TTL"]
    end

    subgraph Core["Core layer"]
        Eng["engines.js\n6 engine adapters"]
        Fetch["fetcher.js\nHTML → markdown\n+ TLS fallback dispatch"]
        Res["research.js\nRRF fusion + SimHash dedup"]
    end

    subgraph HTTP["http.js  (undici primary path)"]
        Proxy["Proxy routing\nCN direct / Intl → 7890\nre-routed per hop"]
        Bucket["Token bucket\n1 concurrent / host\n+120ms interval"]
        Backoff["Exponential backoff\n429 / 5xx retry\n+ Retry-After"]
        Undici["decompress interceptor\n+ manual 3xx loop"]
        Sim["simhash.js\n64-bit Charikar near-dup"]
    end

    TLS["tlsbypass.js → curl_cffi (Python)\nbrowser JA3/JA4 impersonation"]

    CN["CN engines (direct)\nbaidu · bingcn · sogou · so"]
    Intl["International engines (proxy 127.0.0.1:7890)\nduckduckgo · bing"]

    Client <--> Server
    T1 --> Core
    T2 --> Core
    T3 --> Core
    T1 -.cache.-> Cache
    T2 -.cache.-> Cache
    T3 -.cache.-> Cache
    Core --> HTTP
    HTTP -- "403 / 429\nor hard-case host" --> TLS
    HTTP --> CN
    HTTP --> Intl

`deep_research` pipeline

flowchart TB
    Q(["query"]) --> S1["1. Engine selection\nCJK → CN first · Latin → Intl first\nor engines=[...] / all"]
    S1 --> S2["2. Fan-out search\nall engines in parallel · fault-tolerant"]
    S2 --> S3["3. Baidu redirect resolution\nbaidu.com/link?url= → real URL"]
    S3 --> S4["4. Two-stage dedup\nstage 1: exact URL · stage 2: SimHash Hamming ≤ 3"]
    S4 --> S5["5. RRF ranking\nscore = Σ 1/(60 + rank)"]
    S5 --> S6["6. Fetch top-K\nmax 4 concurrent · token bucket + backoff\nTLS → curl_cffi on 403"]
    S6 --> S7["7. Synthesize report\ncited markdown"]
    S7 --> R(["cited report"])

Principles

1. Auto proxy routing (CN direct / international via proxy)

src/http.js keeps a list of CN-domain suffixes (baidu.com / bing.com / so.com …). On each request the host suffix decides:

CN domain hit → direct (proxying CN sites is slower and trips their risk control)
International host → through 127.0.0.1:7890 (works around host-network issues reaching foreign sites)
On redirect, the route is re-decided per hop: a 301 from an international site to a CN CDN stops using the proxy
engine.search() may override with forceProxy / forceDirect (e.g. DuckDuckGo must be proxied)
Set PROXY_URL="" to disable the proxy (e.g. when a global VPN is active)

2. RRF rank fusion (Reciprocal Rank Fusion)

src/research.js. Each result's score = Σ_engine 1/(k + rankᵢ), with k=60.

Unsupervised: no score normalization needed; robust to engines returning different counts
Cross-engine consensus: results that appear in multiple engines near the top naturally surface
Query-term-in-title is only a 1e-4-scale tiebreaker; it never overrides cross-engine consensus
k=60 is the standard default from Cormack et al. (2009) and ranx.fuse

3. SimHash near-duplicate dedup

src/simhash.js. 64-bit SimHash (Charikar), tokenized with FNV-1a hashing + unigram/bigram.

Two stages: exact normalized-URL merge first, then SimHash Hamming ≤ 3 as near-duplicate
The fingerprint excludes the host, so syndicated copies across different hosts merge (the same article republished by different portals, or the same result wrapped differently by Baidu vs Bing)
Verified: identical text under different hosts → distance 0; reworded → 11; unrelated → 36 — discriminative

4. Per-host token bucket + exponential backoff (anti frequent-access detection)

src/http.js. Per host:

Concurrency 1 + ≥120 ms between requests (HOST_BUCKETS)
Transient errors (429/502/503/504) + network failures: exponential backoff 500·2^attempt + jitter, up to 2 retries
Honors the Retry-After response header
Different hosts still run in parallel (no throughput loss)

This directly targets the main cause of "frequent-access detection" — high request rate to a single host.

5. Result caching + frequency-aware TTL (incremental)

src/cache.js. Disk JSON KV with TTLs scaled by site update frequency:

Site category	TTL	Rationale
Search-engine result pages (baidu/bing/ddg…)	30 min	result ordering shifts fast
News aggregators (163/sina/cctv/reuters…)	1 h	high-churn
Docs/API/encyclopedia (docs./wikipedia/arxiv…)	7 d	stable content
Other	6 h	default

web_search / fetch_url / deep_research return cached results on hit (tagged _cached (age Nmin, ttl Mmin)_)
Only caches when there are results (empty results aren't cached, so the next call retries)
CACHE_DISABLED=1 disables; CACHE_DIR overrides the cache directory
Rationale: frequency-aware incremental crawling (2010) — refresh interval scaled by page change frequency

6. TLS/JA3 fingerprint impersonation fallback (curl_cffi)

src/tlsbypass.js + src/fetcher.js. Node undici's TLS ClientHello differs from a real browser, so heavily-protected sites (Cloudflare-protected docs.anthropic.com etc.) return 403. curl_cffi (Python) can impersonate a real browser's JA3/JA4 fingerprint + HTTP/2 settings.

Strategy:

Fast path: undici by default (fast, native)
Known hard-case hosts (docs/platform.anthropic.com etc.): go straight to curl_cffi
Generic fallback: on undici 403/429 or network error → auto-fallback to curl_cffi; if both fail, report honestly (with impersonated flag)
Reports tag TLS: impersonated (curl_cffi) or native (undici)
Requires Python + pip install curl_cffi; without it, degrades to undici-only (main flow unaffected)
Rationale: TLS Beyond the Browser (ACM IMC 2019) — non-browser TLS clients are fingerprintable; impersonation closes that gap

7. Engine adapters

Engine	Region	Route	Notes
duckduckgo	international	proxy	`html.duckduckgo.com/html/` no-key HTML endpoint
bing	international	proxy	`setmkt=en-US&cc=US`; reconstructs real URL from `<cite>` (bypasses the `ck/a` redirect wrapper)
bingcn	CN	direct	`cn.bing.com`
baidu	CN	direct	Detects CAPTCHA interstitial and errors out; reads `mu` attr for the real URL
sogou	CN	direct	Mobile + desktop dual fallback to dodge anti-bot
so (360)	CN	direct	`www.so.com`

A query with CJK characters defaults to CN engines first; pure-Latin queries go international first. engine='all' fans out to every engine.

8. Key undici v7 handling

interceptors.decompress(): auto-decompress gzip/br/deflate (Bing international returns brotli)
Manual 3xx redirect loop: undici v7's request() no longer accepts maxRedirections, and the redirect interceptor alone isn't enough (per-request opts default to 0 and short-circuit). The manual loop also lets us re-route proxy/direct per hop.

Tools

`web_search`

{ "query": "anthropic claude api pricing", "num": 8, "engine": "auto" }

engine: auto (default) | all | duckduckgo | bing | bingcn | baidu | sogou | so

`fetch_url`

{ "url": "https://example.com/page", "max_chars": 16000 }

Fetch a URL, strip boilerplate, return markdown. Auto-routes proxy/direct by domain; falls back to TLS impersonation on 403.

`deep_research`

{
  "query": "中国空间站 最新进展",
  "engines": ["bingcn", "baidu"],
  "num_per_engine": 8,
  "fetch_top_k": 4,
  "fetch_chars": 6000
}

Multi-engine fan-out → dedup & RRF rank → fetch top-K → cited markdown report.

Environment variables

Variable	Default	Effect
`PROXY_URL`	`http://127.0.0.1:7890`	proxy endpoint; empty string disables proxying
`CACHE_DISABLED`	`0`	set `1` to disable result caching
`CACHE_DIR`	`./cache`	cache directory

Referenced papers

Papers referenced in the implementation (DOIs verifiable; retrieved via the OpenAlex academic API + DuckDuckGo/Bing):

Result fusion / ranking

Paper	Year	Used for	DOI
ranx.fuse: A Python Library for Metasearch	2022 (CIKM)	RRF implementation reference; 25 fusion algorithms	10.1145/3511808.3557207
Comparing Rank and Score Combination Methods for Data Fusion in IR	2005	Comparison of CombMNZ etc.; basis for RRF k	10.1007/s10791-005-6994-4
The use of MMR, diversity-based reranking	1998 (Carbonell)	Foundational diversity reranking (not yet implemented)	10.1145/290941.291025
Fusion-based methods for result diversification in web search	2018 (Information Fusion)	Combining fusion and diversity	10.1016/j.inffus.2018.01.006

Near-duplicate detection

Paper	Year	Used for	DOI
A Review for Weighted MinHash Algorithms	2018	MinHash/SimHash survey	10.48550/arxiv.1811.04633
Improved Near-Duplicate Detection for Aggregated and Paywalled News	2025 (NAACL)	Recent advances in near-dup detection	10.18653/v1/2025.naacl-industry.73
Effective and Fast Near Duplicate Detection via Signature-Based	2016	Signature-based dedup engineering	10.1155/2016/3919043

Parallel / incremental crawling / rate limiting

Paper	Year	Used for	DOI
BUbiNG: Massive Crawling for the Masses	2016	Per-host politeness queue, linear scaling	10.48550/arxiv.1601.06919
SIMHAR — Smart Distributed Web Crawler for the Hidden Web	2020 (IEEE Access)	Distributed queue + SIM+Hash dedup	10.1109/access.2020.3004756
Design of a Priority Based Frequency Regulated Incremental Crawler	2010	Frequency-aware incremental crawling (caching)	10.5120/23-131
On the Feasibility of Geographically Distributed Web Crawling	2008	Geo-distributed crawling reduces latency	10.4108/icst.infoscale2008.3550

Anti-bot / blocking evasion

Paper	Year	Used for	DOI
TLS Beyond the Browser	2019 (ACM IMC)	TLS/JA3 fingerprint exposure (P1)	10.1145/3355369.3355601
FP-Crawlers: Studying the Resilience of Browser Fingerprinting	2020	Browser fingerprinting detection	10.14722/madweb.2020.23010
A First Look at User-Installed Residential Proxies	2024 (CNSM)	Residential-proxy ecosystem (proxy pool, planned)	10.23919/cnsm62983.2024.10814519

Full optimization plan and gap analysis: docs/optimization-research.md.

Project structure

web-search-mcp/
├── index.js              # MCP server entry (registers 3 tools, stdio)
├── src/
│   ├── http.js           # HTTP layer + proxy routing + token bucket + backoff
│   ├── engines.js        # 6 engine adapters
│   ├── fetcher.js        # HTML → markdown + TLS fallback dispatch
│   ├── research.js       # RRF fusion + SimHash dedup pipeline
│   ├── simhash.js        # 64-bit Charikar SimHash
│   ├── cache.js          # disk KV with frequency-aware TTL
│   └── tlsbypass.js      # curl_cffi TLS impersonation bridge
├── test-smoke.js         # smoke test
├── docs/
│   ├── optimization-research.md
│   ├── architecture.svg
│   └── pipeline.svg
├── .mcp.json             # project-level MCP registration
└── package.json

Known limitations

All network requests time out in 20–25 s; nothing hangs.
Baidu occasionally returns a CAPTCHA interstitial; that engine then errors and deep_research falls back to the other engines.
Bing international wraps result links in bing.com/ck/a; the real URL is reconstructed from the result's <cite>.
DuckDuckGo uses the no-key html.duckduckgo.com/html/ endpoint, which requires the proxy.
TLS impersonation depends on Python + curl_cffi. Without it, falls back to undici-only and hard-case sites (e.g. docs.anthropic.com) return 403; with it, impersonation is automatic.
The cache expires by TTL without background refresh; the next call after expiry re-fetches. Set CACHE_DISABLED=1 to disable.

License

MIT

Available Tools

3 tools

deep_researchA

Multi-engine deep research: fan out across engines (auto-selects CN vs international), dedupe + rank results, fetch the top pages, and synthesize a cited markdown report. Use for thorough, multi-source research.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Research question / query
`engines`	No	Engines to use; omit for auto-selection based on query language
`fetch_chars`	No
`fetch_top_k`	No
`num_per_engine`	No

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description discloses key behavioral traits: engine auto-selection (CN vs international), deduplication and ranking, fetching top pages, and producing a cited markdown report. This gives good insight into the internal pipeline, though lacks details on failure modes or operational limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core action, and every word adds value. No wasted information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with five parameters and no output schema, the description adequately explains the workflow and final output (cited markdown report). It omits some operational details but is sufficiently complete for an agent to select and invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 40%, and the description helps clarify 'engines' (auto-selection) and 'fetch_top_k' (fetch top pages), but fetch_chars and num_per_engine remain unexplained. The description adds some meaning but does not fully compensate for the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it performs multi-engine deep research by fanning out across engines, deduplicating and ranking results, fetching top pages, and synthesizing a cited markdown report. This specific verb+resource description effectively distinguishes it from sibling tools web_search and fetch_url.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description ends with 'Use for thorough, multi-source research,' providing clear context for when to select this tool over simpler siblings. However, it does not explicitly state when not to use it or name alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fetch_urlA

Fetch a URL, strip boilerplate, and return the page content as markdown. International hosts auto-route through the configured proxy; CN hosts (baidu/bing.cn/so/...) go direct.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	URL to fetch
`max_chars`	No	Max chars of markdown to return

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It explicitly discloses behavioral traits: 'strip boilerplate', returns markdown, and the proxy routing for international vs. CN hosts. This goes beyond minimal operational details, though it doesn't address error handling or auth requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary action, followed by a relevant network routing detail. Every sentence adds necessary context with no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with two parameters and no output schema, the description sufficiently covers the return value ('markdown') and key behavior (boilerplate stripping, proxy routing). It lacks mention of error handling or non-HTML content, but these are not critical given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so a baseline of 3 applies. The description adds little beyond the schema; 'Fetch a URL' paraphrases the url parameter, and max_chars is already described as 'Max chars of markdown to return.' No additional parameter semantics are provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('Fetch'), a specific resource ('a URL'), and the output format ('return the page content as markdown'). This clearly distinguishes it from sibling tools 'web_search' and 'deep_research', which are for searching/researching rather than fetching a known URL.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when the agent has a specific URL to retrieve, but it does not explicitly contrast with alternatives like web_search or deep_research. It lacks an explicit 'when to use' or 'when not to use' statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

web_searchA

Search the web across engines. Auto-selects CN or international engines based on the query language; international engines route through the configured proxy. Use engine='all' to fan out across every engine, or specify one (duckduckgo|bing|bingcn|baidu|sogou|so).

ParametersJSON Schema

Name	Required	Description	Default
`num`	No	Max results (per engine)
`query`	Yes	Search query
`engine`	No	Engine: auto \| all \| duckduckgo \| bing \| bingcn \| baidu \| sogou \| so	auto

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses meaningful behaviors: auto-selection of CN/international engines, proxy routing for international engines, and fan-out semantics for 'all'. These go beyond the basic schema, though it does not mention output format or rate limits, so it is not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the core purpose, and every sentence provides distinct value: purpose, proxy/auto-select behavior, and usage examples. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description provides sufficient invocation context for a moderately complex tool (3 params, no output schema). It explains engine choices and the proxy routing. However, since there is no output schema, a note about the result format would improve completeness, but the description is still adequate for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds significant meaning to the 'engine' parameter by explaining the 'auto' behavior, the 'all' fan-out, and listing valid values. It does not add detail for 'query' or 'num', but the engine semantics are substantially enriched.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Search the web across engines.' It clearly distinguishes itself from siblings like fetch_url (fetching a specific URL) and deep_research (presumably deeper analysis). The mention of engine auto-selection further narrows its unique role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear guidance on engine selection: use engine='all' to fan out or specify one of the listed engines. It also explains the auto-selection behavior based on query language. However, it does not explicitly contrast this tool with alternatives like deep_research or fetch_url, so a fully explicit when-to-use is absent.

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.

3 tool updatesv1.0.0Aug 8, 2026
- First observeddeep_research
- First observedfetch_url
- First observedweb_search

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-08-08 06:25 across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: web_search for searching, fetch_url for fetching a specific page, and deep_research for multi-step synthesis. While deep_research uses search, it is clearly a higher-level workflow, so no ambiguity.

Naming Consistency4/5

web_search and fetch_url follow a consistent verb_noun pattern, but deep_research uses an adjective_noun pattern. All names use lowercase and underscores, so the deviation is minor and does not hinder readability.

Tool Count5/5

Three tools is well-scoped for a web search server: search, fetch, and deep research cover the core needs without redundancy or bloat.

Completeness4/5

The surface covers the essential operations of searching, fetching, and synthesizing. Minor gaps exist (e.g., no tool for image search or specific engine metadata), but they are not critical for typical use.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

qsearch A
io.github.theYahia
Multi-engine search for AI agents. Trust scoring, local corpus, MCP-native. Self-hostable, BYOK.
Search RAG Systems
22
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
Keenable Web Search A
ai.keenable.api
Docs: https://docs.keenable.ai/mcp-server Keenable is a free, remote MCP server that gives agents access to the web index. Search the web with ranked results and date/site filters, then fetch any indexed page as clean markdown. Works out of the box with no account or API key.
Research & Data Search Web Scraping
23
MESSORA A
dev.messora
Scrape, crawl and search the web for AI agents via MCP.
Web Scraping Browser Automation Search
51

Related MCP Servers

evo-scry
Search Web Scraping
krich11
A
license
Not graded
quality
D
maintenance
MCP server for internet search via direct Google and DuckDuckGo HTML scraping with AI-powered result normalization and optional summarization, requiring no API keys for search.
Updated 5 months ago (2026-04-06 21:02 UTC)
MIT
serp-it
Search Browser Automation Web Scraping
luka-dev
A
license
Not graded
quality
C
maintenance
An MCP server that aggregates web search results from multiple engines and optionally renders pages to Markdown, providing a unified search interface.
Updated 7 months ago (2026-01-31 23:31 UTC)
10 npm
3
ISC
web-basics-mcp
Browser Automation Search
yoloyash
A
license
A
quality
A
maintenance
A self-hosted MCP server providing web search and URL fetching tools, running locally without external API keys or accounts.
Updated 21 days ago (2026-08-26 07:41 UTC)
2
81 npm
MIT
fast-web-search-mcp
Browser Automation Web Scraping Search
iPraBhu
A
license
A
quality
B
maintenance
A production-ready MCP server for free web search, news search, and webpage content extraction using DuckDuckGo and Bing.
Updated 2 months ago (2026-07-13 23:49 UTC)
4
8 npm
MIT

web-search MCP server

Installation

Prerequisites

Build

Wire into Claude Code

Verify

(Recommended) Disable Claude Code's built-in WebFetch

Highlights

Architecture

deep_research pipeline

Principles

1. Auto proxy routing (CN direct / international via proxy)

2. RRF rank fusion (Reciprocal Rank Fusion)

3. SimHash near-duplicate dedup

4. Per-host token bucket + exponential backoff (anti frequent-access detection)

5. Result caching + frequency-aware TTL (incremental)

6. TLS/JA3 fingerprint impersonation fallback (curl_cffi)

7. Engine adapters

8. Key undici v7 handling

Tools

web_search

fetch_url

deep_research

Environment variables

Referenced papers

Result fusion / ranking

Near-duplicate detection

Parallel / incremental crawling / rate limiting

Anti-bot / blocking evasion

Project structure

Known limitations

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

(Recommended) Disable Claude Code's built-in `WebFetch`

`deep_research` pipeline

`web_search`

`fetch_url`

`deep_research`