What can you do with this server?

The open-webSearch server enables multi-engine web searches and content fetching from various platforms without requiring API keys. Core Functions: * Web Search: Search across multiple engines (Bing, Baidu, CSDN, DuckDuckGo, Exa, Brave, Juejin) with customizable parameters for query terms, result limits, and engine selection * Content Fetching: Retrieve full article content from CSDN posts, GitHub repository READMEs, Juejin articles, and Linux.do forum posts * No Authentication Required: All operations work without API keys or authentication Configuration Options: * HTTP Proxy Support: Configure proxies to access restricted resources or region-blocked search engines * CORS Support: Enable cross-origin resource sharing * Environment Variables: Customize default search engine, proxy settings, port, and other server behaviors deployment & Integration: * Flexible Deployment: Run locally, via Docker, or NPX quick start * MCP Client Integration: Works with Cherry Studio, VSCode, and Claude Desktop

Which integrations are available for this server?

Enables web search through Baidu's search engine, retrieving search results with titles, URLs, and descriptions. Provides web search functionality through the Brave search engine, returning structured search results. Supports searching the CSDN platform and fetching complete content of CSDN blog articles using the fetchCsdnArticle tool. Enables web search using the DuckDuckGo search engine, returning structured results with metadata. Supports repository forking and publishing of custom Docker images via GitHub Container Registry integration. Provides CI/CD workflow configuration for automatic Docker image building and publishing when changes are pushed.

How do I use open-webSearch?

1. Click on "Install 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., "@open-webSearch find recent articles about AI advancements in healthcare" 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.

open-webSearch

by Aas-ee

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Open-WebSearch

ModelScope Version License Issues

🇨🇳 中文 | 🇺🇸 English

open-websearch provides an MCP server, CLI, and local daemon, and can also be paired with skill-guided agent workflows for live web search and content retrieval without API keys.

Swiftproxy provides high-quality static residential proxies with stable IPs for multi-account management, automation, web scraping, and secure online operations. Protect your accounts with clean IPs and reliable proxy infrastructure. Static proxy traffic is valid for 30 days with unlimited usage. Get 10% off with code PROXY90.

Related MCP server: Multi-Search MCP Server

Features

Web search using multi-engine results
- bing
- baidu
- ~~linux.do~~ temporarily unsupported
- csdn
- duckduckgo
- exa
- brave
- juejin
- startpage
- sogou
- hackernews
HTTP proxy configuration support for accessing restricted resources
No API keys or authentication required
Returns structured results with titles, URLs, and descriptions
Configurable number of results per search
Customizable default search engine
Support for fetching individual article content
- csdn
- github (README files)
- generic HTTP(S) page / Markdown content

Choose the Right Path

MCP
- Best when you want to connect open-websearch to Claude Desktop, Cherry Studio, Cursor, or another MCP client.
CLI
- Best for one-shot local commands, shell scripts, and direct terminal usage.
Local daemon
- Best when you want a reusable long-lived local HTTP service exposing status, GET /health, and POST /search / POST /fetch-*. Start it explicitly with open-websearch serve and check it with open-websearch status.
Skill
- Best as an agent-facing guidance layer for setup and usage. A skill does not replace MCP, CLI, or the local daemon; it typically works together with the CLI and/or local daemon to help an agent discover, activate, and use the smallest working path.

Use with a Skill

Install the open-websearch skill for your agent first:

npx skills add https://github.com/Aas-ee/open-webSearch --skill open-websearch

On first use, the skill typically follows this path: detect whether a usable open-websearch path already exists, guide setup/enablement if it does not, validate that the capability is active, and only then continue with search or fetch through the smallest working path.

If the current environment cannot complete setup or activation automatically, you can explicitly have the agent start the local daemon first:

open-websearch serve
open-websearch status

Keep installation proxy settings separate from runtime proxy settings:

Installation proxy / mirror
- Use this when the skill or agent is installing open-websearch, playwright, or other npm packages.
- In restricted networks, npm-specific flags or npm config often work better than generic shell proxy variables, for example:

npm --proxy http://127.0.0.1:7890 --https-proxy http://127.0.0.1:7890 install -g open-websearch

Runtime proxy
- Use this when the daemon is already installed and is about to perform live search / fetch work.
- This affects the open-websearch network traffic after serve starts, for example:

USE_PROXY=true PROXY_URL=http://127.0.0.1:7890 open-websearch serve

If the agent can only get through the package-install step with npm proxy settings, but live search/fetch also needs a proxy after startup, those are two separate configuration steps and should be handled separately.

CLI and Local Daemon

CLI is for one-shot execution. The local daemon is a long-lived local HTTP service for repeated calls with lower startup friction. Use open-websearch serve as the explicit daemon start command and open-websearch status as the explicit daemon status command.

Action commands such as search and fetch-web try the default local daemon first when it is available. If you pass --daemon-url, that daemon path becomes explicit and silent fallback to direct execution is disabled.

Build first:

npm run build

Start the local daemon:

npm run serve
# globally installed: open-websearch serve

Check status:

npm run status -- --json
# globally installed: open-websearch status --json

Run a one-shot local CLI search:

npm run search:cli -- "open web search" --json

Notes:

Bare open-websearch is the MCP server compatibility entrypoint, not the recommended daemon start command for agent automation.
For content extraction, prefer searching first and then fetching a more specific result page. Some homepages and JS-heavy landing pages may not expose readable article text through fetch-web.

For the local daemon HTTP API (serve, status, GET /health, POST /search, POST /fetch-*), see docs/http-api.md.

TODO

Support for ~~Bing~~ (already supported), ~~DuckDuckGo~~ (already supported), ~~Exa~~ (already supported), ~~Brave~~ (already supported), ~~Sogou~~ (already supported), ~~Hacker News~~ (already supported), Google and other search engines
Support for more blogs, forums, and social platforms
Optimize article content extraction, add support for more sites
~~Support for GitHub README fetching~~ (already supported)

Installation Guide

If you are using open-websearch as an MCP server, continue with the MCP-oriented setup below.

NPX Quick Start (Recommended)

The fastest way to get started:

# Basic usage
npx open-websearch@latest

# With environment variables (Linux/macOS)
DEFAULT_SEARCH_ENGINE=duckduckgo ENABLE_CORS=true npx open-websearch@latest

# Windows PowerShell
$env:DEFAULT_SEARCH_ENGINE="duckduckgo"; $env:ENABLE_CORS="true"; npx open-websearch@latest

# Windows CMD
set MODE=stdio && set DEFAULT_SEARCH_ENGINE=duckduckgo && npx open-websearch@latest

# Cross-platform (requires cross-env, Used for local development)
npm install -g open-websearch
npx cross-env DEFAULT_SEARCH_ENGINE=duckduckgo ENABLE_CORS=true open-websearch

Environment Variables:

Variable	Default	Options	Description
`ENABLE_CORS`	`false`	`true`, `false`	Enable CORS
`CORS_ORIGIN`	`*`	Any valid origin	CORS origin configuration
`DEFAULT_SEARCH_ENGINE`	`bing`	`bing`, `duckduckgo`, `exa`, `brave`, `baidu`, `csdn`, `linuxdo`, `juejin`, `startpage`, `sogou`, `hackernews`	Default search engine
`USE_PROXY`	`false`	`true`, `false`	Enable HTTP proxy
`PROXY_URL`	`http://127.0.0.1:7890`	Any valid URL	Proxy server URL
`FAKE_IP_CIDRS`	empty	Comma-separated CIDR list	Treat DNS answers in these CIDRs as synthetic fake-IP results and do not block them as private-network DNS answers. Literal private/local targets and other private-network DNS answers remain blocked
`FETCH_WEB_INSECURE_TLS`	`false`	`true`, `false`	Disable TLS verification only for the request leg of `fetchWebContent`; it does not affect Playwright browser navigation. Use only for broken certificate chains
`MODE`	`both`	`both`, `http`, `stdio`	Server mode: both HTTP+STDIO, HTTP only, or STDIO only
`PORT`	`3000`	1-65535	Server port
`ALLOWED_SEARCH_ENGINES`	empty (all available)	Comma-separated engine names	Limit which search engines can be used; if the default engine is not in this list, the first allowed engine becomes the default
`SEARCH_MODE`	`auto`	`request`, `auto`, `playwright`	Search strategy. Currently only affects Bing: force HTTP request mode (`request`), force Playwright mode (`playwright`), or let the agent choose (`auto`, default). Forced modes never expose a `searchMode` override to the agent. In `auto` mode the server checks whether Playwright is really usable (the client module can actually be loaded, and for local launches a real browser binary exists: explicit `PLAYWRIGHT_EXECUTABLE_PATH`, bundled browser, or system Chrome/Edge); if available, the search tool exposes a `searchMode` parameter and directs the agent to stay on the default `auto` and only retry with `playwright` when request results fail, return empty, or look blocked; otherwise it behaves as forced request mode. If `playwright` is forced but not usable, searches fail with a `browser_unavailable` error
`PLAYWRIGHT_PACKAGE`	`auto`	`auto`, `playwright`, `playwright-core`	Which Playwright client package to resolve when browser mode is enabled
`PLAYWRIGHT_MODULE_PATH`	empty	Absolute path or project-relative path	Reuse an existing Playwright client package outside this project
`PLAYWRIGHT_EXECUTABLE_PATH`	empty	Any valid browser binary path	Launch an existing Chromium/Chrome executable without installing bundled browsers
`PLAYWRIGHT_WS_ENDPOINT`	empty	Valid Playwright `ws://` / `wss://` endpoint	Connect to an existing remote Playwright browser server
`PLAYWRIGHT_CDP_ENDPOINT`	empty	Valid Chromium CDP endpoint	Connect to an existing Chromium instance over CDP
`PLAYWRIGHT_HEADLESS`	`true`	`true`, `false`	Whether Playwright Chromium runs in headless mode
`PLAYWRIGHT_NAVIGATION_TIMEOUT_MS`	`20000`	Positive integer	Timeout for Playwright navigation and Bing result waits
`OPEN_WEBSEARCH_PROFILE_DIR`	`<tmpdir>/open-websearch-browser-profiles`	Any writable directory	Base directory for persistent local browser profiles (see browser state note below)
`MCP_TOOL_SEARCH_NAME`	`search`	Valid MCP tool name	Custom name for the search tool; set to `<disabled>` (quote as `'<disabled>'` in bash/zsh, `"<disabled>"` in Windows cmd) to disable the tool. Invalid names fallback to default with a warning
`MCP_TOOL_FETCH_LINUXDO_NAME`	`fetchLinuxDoArticle`	Valid MCP tool name	Custom name for the Linux.do article fetch tool; set to `<disabled>` (quote as `'<disabled>'` in bash/zsh, `"<disabled>"` in Windows cmd) to disable the tool. Invalid names fallback to default with a warning
`MCP_TOOL_FETCH_CSDN_NAME`	`fetchCsdnArticle`	Valid MCP tool name	Custom name for the CSDN article fetch tool; set to `<disabled>` (quote as `'<disabled>'` in bash/zsh, `"<disabled>"` in Windows cmd) to disable the tool. Invalid names fallback to default with a warning
`MCP_TOOL_FETCH_GITHUB_NAME`	`fetchGithubReadme`	Valid MCP tool name	Custom name for the GitHub README fetch tool; set to `<disabled>` (quote as `'<disabled>'` in bash/zsh, `"<disabled>"` in Windows cmd) to disable the tool. Invalid names fallback to default with a warning
`MCP_TOOL_FETCH_JUEJIN_NAME`	`fetchJuejinArticle`	Valid MCP tool name	Custom name for the Juejin article fetch tool; set to `<disabled>` (quote as `'<disabled>'` in bash/zsh, `"<disabled>"` in Windows cmd) to disable the tool. Invalid names fallback to default with a warning
`MCP_TOOL_FETCH_WEB_NAME`	`fetchWebContent`	Valid MCP tool name	Custom name for generic web/Markdown fetch tool; set to `<disabled>` (quote as `'<disabled>'` in bash/zsh, `"<disabled>"` in Windows cmd) to disable the tool. Invalid names fallback to default with a warning

Common configurations:

# Enable proxy for restricted regions
USE_PROXY=true PROXY_URL=http://127.0.0.1:7890 npx open-websearch@latest

# Only if a target website has a broken certificate chain
FETCH_WEB_INSECURE_TLS=true npx open-websearch@latest

# Request first, then fallback to Playwright if available
SEARCH_MODE=auto npx open-websearch@latest

# Force request-only Bing search
SEARCH_MODE=request npx open-websearch@latest

# Rename search tool to webSearch
MCP_TOOL_SEARCH_NAME=webSearch npx open-websearch@latest

# Disable search tool
MCP_TOOL_SEARCH_NAME='<disabled>' npx open-websearch@latest

# Full configuration
DEFAULT_SEARCH_ENGINE=duckduckgo ENABLE_CORS=true USE_PROXY=true PROXY_URL=http://127.0.0.1:7890 PORT=8080 npx open-websearch@latest

Note: The <disabled> sentinel contains shell-special characters. In bash/zsh, quote it as '<disabled>'; in Windows cmd, use double quotes "<disabled>".

Browser-enhanced Bing fallback is opt-in. The published package does not bundle Playwright anymore. Enable it manually with one of these setups:

Full local Playwright install:

npm install playwright
npx playwright install chromium
SEARCH_MODE=auto npx open-websearch@latest

Reuse an existing browser binary with a slim client:

npm install playwright-core
PLAYWRIGHT_PACKAGE=playwright-core PLAYWRIGHT_EXECUTABLE_PATH=/path/to/chromium SEARCH_MODE=auto npx open-websearch@latest

Reuse a Playwright package that already exists elsewhere on the machine:

PLAYWRIGHT_MODULE_PATH=/absolute/path/to/node_modules/playwright SEARCH_MODE=playwright npx open-websearch@latest

Connect to an existing remote browser:

npm install playwright-core
PLAYWRIGHT_PACKAGE=playwright-core PLAYWRIGHT_WS_ENDPOINT=ws://127.0.0.1:3000/ SEARCH_MODE=auto npx open-websearch@latest

Reuse a local Chrome/Chromium session over CDP:

npm install playwright-core

# Start Chrome/Chromium with a debugging port first
chrome --remote-debugging-port=9222 --user-data-dir=/tmp/open-websearch-chrome

# Then connect through CDP
PLAYWRIGHT_PACKAGE=playwright-core PLAYWRIGHT_CDP_ENDPOINT=http://127.0.0.1:9222 SEARCH_MODE=auto npx open-websearch@latest

This is the most practical setup when you want to reuse your own logged-in or previously verified browser session.

Windows PowerShell example:

npm install playwright-core

& "$env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe" `
  --remote-debugging-port=9222 `
  --user-data-dir="$env:TEMP\open-websearch-chrome"

$env:PLAYWRIGHT_PACKAGE="playwright-core"
$env:PLAYWRIGHT_CDP_ENDPOINT="http://127.0.0.1:9222"
$env:SEARCH_MODE="auto"
npx open-websearch@latest

Mode behavior:

request: only uses request-based Bing scraping; the search tool exposes no searchMode parameter and no mode guidance
playwright: forces Playwright; the search tool exposes no searchMode parameter and no mode guidance. Playwright availability is checked at startup and an invalid configuration logs a warning; searches then fail with a clear browser_unavailable error
auto: checks whether Playwright is really usable (the client module actually loads; for local launches a real browser binary must exist). If available, the search tool exposes a searchMode parameter (request / auto / playwright) and directs the agent to stay on the default auto, retrying with playwright only when request results fail, return empty, or look blocked; otherwise the server behaves as request mode

Notes:

PLAYWRIGHT_MODULE_PATH takes precedence over PLAYWRIGHT_PACKAGE
PLAYWRIGHT_WS_ENDPOINT takes precedence over PLAYWRIGHT_CDP_ENDPOINT
Remote endpoints ignore PLAYWRIGHT_EXECUTABLE_PATH and local proxy launch flags
When Playwright is available, blocked CSDN/Zhihu article fetches and generic web fetches can also retry with browser-acquired cookies
Without Playwright, fetchWebContent stays on the request-only path. Public pages can still work, but pages that require browser cookies or browser-rendered HTML may fail.

Browser state note (local shared profiles):

Local browser mode reuses persistent contexts/pages across fetches and across process restarts. Cookies, storage, cache, and Service Worker state for the same origin therefore persist between browser-mode fetches.
This is intentional for single-user, stateful scraping (it keeps anti-bot state warm and avoids repeated browser launches). If you share a daemon between mutually distrusting callers, connect those callers to an isolated browser via PLAYWRIGHT_WS_ENDPOINT/PLAYWRIGHT_CDP_ENDPOINT instead of relying on local shared profiles, or point each caller at its own OPEN_WEBSEARCH_PROFILE_DIR.
This shared state is service-level and intended only for anonymous access to public web pages: the service itself never logs into sites, so it should never carry personal credentials. Do not rely on it to store logged-in or personalized sessions. Remote endpoints (PLAYWRIGHT_WS_ENDPOINT/PLAYWRIGHT_CDP_ENDPOINT) inherit the connected browser's state, so pointing them at a personal logged-in browser also shares that browser's login and personalization state with this service.
To clear profile state, delete the browser profile directories under OPEN_WEBSEARCH_PROFILE_DIR (default: <tmpdir>/open-websearch-browser-profiles) while no local browser is running.

Local Installation

Clone or download this repository
Install dependencies:

npm install

This installs the core MCP server only. Browser fallback remains optional until you install or connect a Playwright client yourself. 3. Build the server:

npm run build

Add the server to your MCP configuration:

Cherry Studio:

{
  "mcpServers": {
    "web-search": {
      "name": "Web Search MCP",
      "type": "streamableHttp",
      "description": "Multi-engine web search with article fetching",
      "isActive": true,
      "baseUrl": "http://localhost:3000/mcp"
    }
  }
}

VSCode (Claude Dev Extension):

{
  "mcpServers": {
    "web-search": {
      "transport": {
        "type": "streamableHttp",
        "url": "http://localhost:3000/mcp"
      }
    },
    "web-search-sse": {
      "transport": {
        "type": "sse",
        "url": "http://localhost:3000/sse"
      }
    }
  }
}

Claude Desktop:

{
  "mcpServers": {
    "web-search": {
      "type": "http",
      "url": "http://localhost:3000/mcp"
    },
    "web-search-sse": {
      "type": "sse",
      "url": "http://localhost:3000/sse"
    }
  }
}

NPX Command Line Configuration:

{
  "mcpServers": {
    "web-search": {
      "args": [
        "open-websearch@latest"
      ],
      "command": "npx",
      "env": {
        "MODE": "stdio",
        "DEFAULT_SEARCH_ENGINE": "duckduckgo",
        "ALLOWED_SEARCH_ENGINES": "duckduckgo,bing,exa"
      }
    }
  }
}

Windows NPX configuration:

{
  "mcpServers": {
    "web-search": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "open-websearch@latest"
      ],
      "env": {
        "MODE": "stdio",
        "DEFAULT_SEARCH_ENGINE": "duckduckgo",
        "SYSTEMROOT": "C:/Windows"
      }
    }
  }
}

Proxy and TLS notes:

open-websearch now disables Axios environment-proxy auto-detection internally and only uses the explicit USE_PROXY + PROXY_URL path.
When USE_PROXY=true, all Axios-based network requests follow the configured PROXY_URL path instead of mixing direct requests with environment-proxy behavior.
If PROXY_URL points to a local rule-based proxy client, that client can still decide which destinations go DIRECT and which ones are proxied.
If PROXY_URL points to a fixed upstream proxy or overseas egress, region-sensitive sites such as Baidu, CSDN, Juejin, Linux.do, or GitHub may behave differently than before.
If your host machine already sets HTTP_PROXY or HTTPS_PROXY, they will no longer override the server's internal request behavior.
Prefer configuring NODE_EXTRA_CA_CERTS on Windows when a site has a missing intermediate CA.
Use FETCH_WEB_INSECURE_TLS=true only as a last resort for the request leg of fetchWebContent; it weakens TLS verification and does not affect Playwright browser navigation.

Local STDIO Configuration for Cherry Studio (Windows):

{
  "mcpServers": {
    "open-websearch-local": {
      "command": "node",
      "args": ["C:/path/to/your/project/build/index.js"],
      "env": {
        "MODE": "stdio",
        "DEFAULT_SEARCH_ENGINE": "duckduckgo",
        "ALLOWED_SEARCH_ENGINES": "duckduckgo,bing,exa"
      }
    }
  }
}

Docker Deployment

Quick deployment using Docker Compose:

docker-compose up -d

Or use Docker directly:

docker run -d --name web-search -p 3000:3000 -e ENABLE_CORS=true -e CORS_ORIGIN=* ghcr.io/aas-ee/open-web-search:latest

Environment variable configuration:

Variable	Default	Options	Description
`ENABLE_CORS`	`false`	`true`, `false`	Enable CORS
`CORS_ORIGIN`	`*`	Any valid origin	CORS origin configuration
`DEFAULT_SEARCH_ENGINE`	`bing`	`bing`, `duckduckgo`, `exa`, `brave`, `baidu`, `csdn`, `linuxdo`, `juejin`, `startpage`, `sogou`, `hackernews`	Default search engine
`USE_PROXY`	`false`	`true`, `false`	Enable HTTP proxy
`PROXY_URL`	`http://127.0.0.1:7890`	Any valid URL	Proxy server URL
`FAKE_IP_CIDRS`	empty	Comma-separated CIDR list	Treat DNS answers in these CIDRs as synthetic fake-IP results and do not block them as private-network DNS answers. Literal private/local targets and other private-network DNS answers remain blocked
`PORT`	`3000`	1-65535	Server port

Then configure in your MCP client:

{
  "mcpServers": {
    "web-search": {
      "name": "Web Search MCP",
      "type": "streamableHttp",
      "description": "Multi-engine web search with article fetching",
      "isActive": true,
      "baseUrl": "http://localhost:3000/mcp"
    },
    "web-search-sse": {
      "transport": {
        "name": "Web Search MCP",
        "type": "sse",
        "description": "Multi-engine web search with article fetching",
        "isActive": true,
        "url": "http://localhost:3000/sse"
      }
    }
  }
}

Usage Guide

The server provides six tools: search, fetchLinuxDoArticle, fetchCsdnArticle, fetchGithubReadme, fetchJuejinArticle, and fetchWebContent.

For the local daemon HTTP API (serve, status, GET /health, POST /search, POST /fetch-*), see docs/http-api.md.

search Tool Usage

{
  "query": string,        // Search query
  "limit": number,        // Optional: Number of results to return (default: 10)
  "engines": string[],    // Optional: Engines to use (bing,baidu,linuxdo,csdn,duckduckgo,exa,brave,juejin,startpage,sogou,hackernews) default runtime-configured engine
  "searchMode": string    // Optional: request, auto, or playwright (currently only affects Bing)
}

Usage example:

use_mcp_tool({
  server_name: "web-search",
  tool_name: "search",
  arguments: {
    query: "search content",
    limit: 3,  // Optional parameter
    engines: ["bing", "csdn", "duckduckgo", "exa", "brave", "juejin", "sogou"] // Optional parameter, supports multi-engine combined search
  }
})

Response example:

[
  {
    "title": "Example Search Result",
    "url": "https://example.com",
    "description": "Description text of the search result...",
    "source": "Source",
    "engine": "Engine used"
  }
]

fetchCsdnArticle Tool Usage

Used to fetch complete content of CSDN blog articles.

{
  "url": string    // URL from CSDN search results using the search tool
}

Usage example:

use_mcp_tool({
  server_name: "web-search",
  tool_name: "fetchCsdnArticle",
  arguments: {
    url: "https://blog.csdn.net/xxx/article/details/xxx"
  }
})

Response example:

[
  {
    "content": "Example search result"
  }
]

fetchLinuxDoArticle Tool Usage

Used to fetch complete content of Linux.do forum articles.

{
  "url": string    // URL from linuxdo search results using the search tool
}

Usage example:

use_mcp_tool({
  server_name: "web-search",
  tool_name: "fetchLinuxDoArticle",
  arguments: {
    url: "https://xxxx.json"
  }
})

Response example:

[
  {
    "content": "Example search result"
  }
]

fetchGithubReadme Tool Usage

Used to fetch README content from GitHub repositories.

{
  "url": string    // GitHub repository URL (supports HTTPS, SSH formats)
}

Usage example:

use_mcp_tool({
  server_name: "web-search",
  tool_name: "fetchGithubReadme",
  arguments: {
    url: "https://github.com/Aas-ee/open-webSearch"
  }
})

Supported URL formats:

HTTPS: https://github.com/owner/repo
HTTPS with .git: https://github.com/owner/repo.git
SSH: git@github.com:owner/repo.git
URLs with parameters: https://github.com/owner/repo?tab=readme

Response example:

[
  {
    "content": "<div align=\"center\">\n\n# Open-WebSearch MCP Server..."
  }
]

fetchWebContent Tool Usage

Fetch content directly from public HTTP(S) links, including Markdown files (.md), ordinary pages, and JavaScript-rendered pages when Playwright is configured.

{
  "url": string,          // Public HTTP(S) URL
  "maxChars": number,     // Optional: max returned content length (1000-200000, default 30000)
  "renderMode": string,   // Optional: request, auto (default), or browser
  "readability": boolean, // Optional: use Mozilla Readability for HTML
  "includeLinks": boolean // Optional: preserve links from Readability output
}

request never starts a browser or uses browser cookies. auto preserves the existing request-first behavior and uses browser assistance only when needed. browser renders the page directly and returns a clear error if Playwright or its browser target is unavailable. Initial and final URLs remain subject to public-network safety checks.

Browser requests are revalidated before continuation, but this process does not pin DNS answers to Chromium's eventual socket. Remote Playwright/CDP endpoints must therefore enforce their own trusted DNS and egress policy.

Usage example:

use_mcp_tool({
  server_name: "web-search",
  tool_name: "fetchWebContent",
  arguments: {
    url: "https://raw.githubusercontent.com/Aas-ee/open-webSearch/main/README.md",
    maxChars: 12000,
    renderMode: "auto"
  }
})

Response example:

{
  "url": "https://raw.githubusercontent.com/Aas-ee/open-webSearch/main/README.md",
  "finalUrl": "https://raw.githubusercontent.com/Aas-ee/open-webSearch/main/README.md",
  "contentType": "text/plain; charset=utf-8",
  "title": "",
  "retrievalMethod": "request",
  "truncated": false,
  "content": "# Open-WebSearch MCP Server ..."
}

fetchJuejinArticle Tool Usage

Used to fetch complete content of Juejin articles.

{
  "url": string    // Juejin article URL from search results
}

Usage example:

use_mcp_tool({
  server_name: "web-search",
  tool_name: "fetchJuejinArticle",
  arguments: {
    url: "https://juejin.cn/post/7520959840199360563"
  }
})

Supported URL format:

https://juejin.cn/post/{article_id}

Response example:

[
  {
    "content": "🚀 开源 AI 联网搜索工具：Open-WebSearch MCP 全新升级，支持多引擎 + 流式响应..."
  }
]

Usage Limitations

Since this tool works by scraping multi-engine search results, please note the following important limitations:

Rate Limiting:
- Too many searches in a short time may cause the used engines to temporarily block requests
- Recommendations:
  - Maintain reasonable search frequency
  - Use the limit parameter judiciously
  - Add delays between searches when necessary
Result Accuracy:
- Depends on the HTML structure of corresponding engines, may fail when engines update
- Some results may lack metadata like descriptions
- Complex search operators may not work as expected
Legal Terms:
- This tool is for personal use only
- Please comply with the terms of service of corresponding engines
- Implement appropriate rate limiting based on your actual use case
Search Engine Configuration:
- Default search engine can be set via the DEFAULT_SEARCH_ENGINE environment variable
- Supported engines: bing, duckduckgo, exa, brave, baidu, csdn, linuxdo, juejin, startpage, sogou, hackernews
- The default engine is used when searching specific websites
Proxy Configuration:
- HTTP proxy can be configured when certain search engines are unavailable in specific regions
- Enable proxy with environment variable USE_PROXY=true
- Configure proxy server address with PROXY_URL
- For Clash fake-ip / TUN setups, configure synthetic DNS ranges with FAKE_IP_CIDRS (for example 198.18.0.0/15)

Contributing

Welcome to submit issue reports and feature improvement suggestions!

Contributor Guide

If you want to fork this repository and publish your own Docker image, you need to make the following configurations:

GitHub Secrets Configuration

To enable automatic Docker image building and publishing, please add the following secrets in your GitHub repository settings (Settings → Secrets and variables → Actions):

Required Secrets:

GITHUB_TOKEN: Automatically provided by GitHub (no setup needed)

Optional Secrets (for Alibaba Cloud ACR):

ACR_REGISTRY: Your Alibaba Cloud Container Registry URL (e.g., registry.cn-hangzhou.aliyuncs.com)
ACR_USERNAME: Your Alibaba Cloud ACR username
ACR_PASSWORD: Your Alibaba Cloud ACR password
ACR_IMAGE_NAME: Your image name in ACR (e.g., your-namespace/open-web-search)

CI/CD Workflow

The repository includes a GitHub Actions workflow (.github/workflows/docker.yml) that automatically:

Trigger Conditions:
- Push to main branch
- Push version tags (v*)
- Manual workflow trigger
Build and Push to:
- GitHub Container Registry (ghcr.io) - always enabled
- Alibaba Cloud Container Registry - only enabled when ACR secrets are configured
Image Tags:
- ghcr.io/your-username/open-web-search:latest
- your-acr-address/your-image-name:latest (if ACR is configured)

Fork and Publish Steps:

Fork the repository to your GitHub account
Configure secrets (if you need ACR publishing):
- Go to Settings → Secrets and variables → Actions in your forked repository
- Add the ACR-related secrets listed above
Push changes to the main branch or create version tags
GitHub Actions will automatically build and push your Docker image

Use your image, update the Docker command:

docker run -d --name web-search -p 3000:3000 -e ENABLE_CORS=true -e CORS_ORIGIN=* ghcr.io/your-username/open-web-search:latest

Notes:

If you don't configure ACR secrets, the workflow will only publish to GitHub Container Registry
Make sure your GitHub repository has Actions enabled
The workflow will use your GitHub username (converted to lowercase) as the GHCR image name

Star History

If you find this project helpful, please consider giving it a ⭐ Star!

Star History Chart

Available Tools

5 tools

fetchCsdnArticleB

Fetch full article content from a csdn post URL

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('fetch full article content') but doesn't describe what 'full article content' includes (e.g., text, images, metadata), potential errors (e.g., invalid URLs, network issues), or any constraints (e.g., rate limits, authentication needs). This leaves significant gaps for an agent to understand how the tool behaves beyond the basic operation.

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 a single, efficient sentence that front-loads the core action ('fetch full article content') and resource ('from a csdn post URL'). There is no wasted language, and it directly communicates the essential information without unnecessary elaboration.

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

Completeness3/5

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

Given the tool's low complexity (one parameter, no annotations, no output schema), the description is minimally complete. It covers the basic purpose but lacks details on usage guidelines, behavioral traits, and output specifics. For a simple fetch operation, this might be adequate, but it doesn't provide enough context for an agent to handle edge cases or alternatives effectively.

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?

The description implies the 'url' parameter must be a csdn post URL, which adds meaning beyond the schema's generic URI format. However, with 0% schema description coverage and only one parameter, the baseline is 4 for zero parameters, but here one parameter is partially clarified. The description doesn't specify URL format details (e.g., must include 'csdn.net'), so it compensates somewhat but not fully.

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

Purpose4/5

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

The description clearly states the verb 'fetch' and the resource 'full article content from a csdn post URL', making the purpose immediately understandable. It distinguishes from siblings like fetchGithubReadme by specifying the source (csdn) and content type (article), though it doesn't explicitly contrast with other article-fetching siblings like fetchJuejinArticle or fetchLinuxDoArticle.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose fetchCsdnArticle over fetchJuejinArticle or fetchLinuxDoArticle, nor does it indicate any prerequisites or exclusions. The only implied usage is for csdn URLs, but this is already covered in the purpose.

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

fetchGithubReadmeC

Fetch README content from a GitHub repository URL

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes

TDQS

C2.9/5.0

Behavior2/5

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 what the tool does but doesn't mention error handling (e.g., invalid URLs, private repos), rate limits, authentication needs, or output format. This leaves significant gaps in understanding how the tool behaves beyond the basic fetch operation.

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 a single, clear sentence with zero wasted words. It's front-loaded with the core purpose and efficiently communicates the essential information without unnecessary elaboration.

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

Completeness2/5

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 doesn't address error cases, return format, or behavioral constraints that an agent would need to use this tool effectively in real-world scenarios.

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?

The description adds minimal semantic context beyond the schema: it implies the 'url' parameter should be a GitHub repository URL. However, with 0% schema description coverage and only one parameter, this provides some value but doesn't fully compensate for the lack of schema documentation (e.g., URL format expectations).

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

Purpose4/5

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

The description clearly states the action ('Fetch') and resource ('README content from a GitHub repository URL'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'fetchCsdnArticle' or 'fetchJuejinArticle' beyond specifying GitHub as the source, which is a minor gap.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'search' or other fetch tools. It mentions GitHub specifically, but doesn't explain when to prefer this over general search or other content-fetching tools, leaving usage context implied at best.

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

fetchJuejinArticleA

Fetch full article content from a Juejin(掘金) post URL

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'fetch full article content,' which implies a read-only operation, but does not disclose other traits such as authentication needs, rate limits, error handling, or what 'full content' entails (e.g., includes images, metadata). This leaves significant gaps for an agent to understand the tool's behavior.

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 a single, efficient sentence that is front-loaded with the core purpose. There is no wasted text, and every word contributes directly to understanding the tool's function, 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.

Completeness3/5

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

Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally complete. It covers the basic purpose and parameter semantics but lacks details on behavioral aspects like output format, error cases, or usage constraints, which could hinder an agent's ability to use it correctly in varied contexts.

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?

The description adds meaning beyond the input schema by specifying that the 'url' parameter must be a 'Juejin post URL,' which clarifies the expected content type. With schema description coverage at 0% and only one parameter, this compensation is effective, though it could further detail URL format or validation rules.

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 the specific action ('fetch full article content') and resource ('from a Juejin post URL'), distinguishing it from sibling tools like fetchCsdnArticle or fetchGithubReadme by specifying the Juejin platform. It uses precise verbs and identifies the exact resource type.

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 context by specifying 'Juejin post URL,' suggesting it should be used for articles from that platform. However, it does not explicitly state when to use this tool versus alternatives like search or other fetch tools, nor does it provide exclusions or prerequisites for usage.

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

fetchLinuxDoArticleC

Fetch full article content from a linux.do post URL

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool fetches content but lacks details on error handling, rate limits, authentication needs, or what 'full article content' entails (e.g., text format, metadata). This is a significant gap for a tool with zero 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.

Conciseness5/5

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

The description is a single, efficient sentence with zero waste. It front-loads the key action and resource, making it easy to parse quickly. Every word earns its place without redundancy.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'full article content' returns (e.g., plain text, HTML, structured data) or address potential behavioral aspects like errors or limitations. For a tool with no structured support, this leaves critical gaps for an AI agent.

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?

The input schema has 1 parameter with 0% description coverage, so the description must compensate. It implies the 'url' parameter should be a linux.do post URL, adding some context beyond the schema's generic URI format. However, it doesn't specify URL format details or validation rules, leaving gaps in parameter understanding.

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

Purpose4/5

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

The description clearly states the action ('fetch full article content') and the resource ('from a linux.do post URL'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like fetchCsdnArticle or fetchGithubReadme beyond the domain name, missing a direct comparison that would earn a 5.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose fetchLinuxDoArticle over other fetch tools (e.g., for linux.do posts specifically) or over the search tool, leaving the agent to infer usage from the name alone.

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

searchB

Search the web using multiple engines (e.g., Baidu, Bing, DuckDuckGo, CSDN, Exa, Brave, Juejin(掘金)) with no API key required

ParametersJSON Schema

Name	Required	Description	Default
`engines`	No
`limit`	No
`query`	Yes

TDQS

B3.2/5.0

Behavior2/5

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 'no API key required' which is useful context about authentication needs, but fails to describe critical behaviors like rate limits, result format, pagination, or whether this is a read-only operation. For a search tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.

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 perfectly concise - a single sentence that efficiently communicates the core functionality and key feature (no API key). Every word earns its place with no redundancy or unnecessary elaboration.

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

Completeness2/5

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

For a search tool with 3 parameters, 0% schema description coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what results look like, how they're structured, whether there are usage limits, or provide sufficient parameter guidance. The 'no API key required' is helpful but doesn't compensate for the overall lack of context.

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?

The schema description coverage is 0%, so the description must compensate for parameter documentation. It mentions 'multiple engines' and lists examples that correspond to the 'engines' parameter enum values, adding some semantic context. However, it doesn't explain the 'query' or 'limit' parameters at all, leaving half the parameters undocumented in both schema and description.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Search the web using multiple engines' with specific examples provided (Baidu, Bing, etc.). It distinguishes itself from sibling tools (which fetch specific articles from single sources) by offering multi-engine web search. However, it doesn't specify the exact verb+resource combination (e.g., 'retrieve web search results') with complete precision.

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 context by mentioning 'no API key required,' suggesting this tool is accessible without authentication. However, it provides no explicit guidance on when to use this tool versus the sibling article-fetching tools, nor does it mention any exclusions or alternatives for different search scenarios.

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. Dates show when Glama detected each change.

5 tool updatesv1.0.0Aug 15, 2025
- First observedfetchCsdnArticle
- First observedfetchGithubReadme
- First observedfetchJuejinArticle
- First observedfetchLinuxDoArticle
- First observedsearch

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: four tools fetch content from specific platforms (CSDN, GitHub, Juejin, Linux.do), while the search tool performs a general web search across multiple engines. There is no overlap in functionality, making tool selection straightforward.

Naming Consistency4/5

The naming is mostly consistent with a 'fetchX' pattern for four tools (fetchCsdnArticle, fetchGithubReadme, fetchJuejinArticle, fetchLinuxDoArticle), but the search tool deviates by using a simple verb without a noun. All tools use camelCase, so the convention is uniform, but the pattern is not fully applied across all tools.

Tool Count5/5

With 5 tools, the count is well-scoped for the server's purpose of open web search and content fetching. Each tool serves a specific, useful function without redundancy, making the set efficient and manageable for agents.

Completeness3/5

The tool surface covers fetching content from specific platforms and general web search, but there are notable gaps. For example, there is no tool to fetch content from other common sources (e.g., news sites, blogs beyond the listed ones), and no advanced search capabilities like filtering or pagination, which could limit agent effectiveness in broader web tasks.

Maintenance

ActivityMaintained

ResponsivenessResponsive

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

brave AOAuth
ai.smithery
Visit https://brave.com/search/api/ for a free API key. Search the web, local businesses, images,…
Search Browser Automation Web Scraping
31,409
Buscador Google A
io.github.mcp-dir
Search Google straight from your AI agent. Web results, images, videos, news, products, scholarly ar
Search Browser Automation
181
web-search
ai.groundroute
Web search for AI agents — one tool across 6 engines, routed to the cheapest + cached.
Search Browser Automation
21
Parallel Search MCP AOAuth
ai.parallel
The best web search for your AI Agent
Search Agent Orchestration Browser Automation
216

Related MCP Servers

Web Search MCP Server
Search Browser Automation Web Scraping
vishalkg
F
license
Not graded
quality
C
maintenance
Enables web search across multiple search engines (DuckDuckGo, Bing, Startpage) with parallel execution and result deduplication. Also provides web page content extraction capabilities.
Updated 2 months ago (2026-07-07 21:39 UTC)
2
-
Multi-Search MCP Server
Search Browser Automation RAG Systems
guptabhishek
A
license
A
quality
C
maintenance
Provides unified web search across multiple providers (Google, Tavily, DuckDuckGo, Brave) with automatic fallback, maximizing free API quota usage for AI workflows.
Updated a year ago (2025-08-03 10:30 UTC)
1
17
7
MIT
MCP MixSearch
Search Browser Automation Web Scraping
geosp
A
license
A
quality
D
maintenance
Enables advanced web search across multiple search engines (Brave, DuckDuckGo, Google, Bing, Yandex) with intelligent backend selection, full content extraction, and advanced filtering by time, language, geography, and content type.
Updated 10 months ago (2025-11-09 08:48 UTC)
3
MIT
Heventure Search MCP
Browser Automation Search
HughesCuit
A
license
A
quality
B
maintenance
Enables web search without API keys using DuckDuckGo and Bing search engines, and retrieves webpage content. Supports multiple search engines simultaneously with privacy protection and asynchronous processing.
Updated 4 months ago (2026-05-13 13:17 UTC)
2
9
MIT

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Aas-ee/open-webSearch'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Open-WebSearch

Sponsor

Features

Choose the Right Path

Use with a Skill

CLI and Local Daemon

TODO

Installation Guide

NPX Quick Start (Recommended)

Local Installation

Docker Deployment

Usage Guide

search Tool Usage

fetchCsdnArticle Tool Usage

fetchLinuxDoArticle Tool Usage

fetchGithubReadme Tool Usage

fetchWebContent Tool Usage

fetchJuejinArticle Tool Usage

Usage Limitations

Contributing

Contributor Guide

GitHub Secrets Configuration

CI/CD Workflow

Fork and Publish Steps:

Notes:

Star History

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API