Search the web using Baidu as the search engine, returning structured results with titles, URLs, and descriptions.
Search the web using Brave Search, returning structured results with titles, URLs, and descriptions.
Search the web using CSDN and fetch individual article content from CSDN pages.
Search the web using DuckDuckGo, returning structured results with titles, URLs, and descriptions.
Fetch README files from GitHub repositories as content.
Search the web using Juejin, returning structured results with titles, URLs, and descriptions.
Search the web using Sogou, returning structured results with titles, URLs, and descriptions.
Search the web using Startpage, returning structured results with titles, URLs, and descriptions.
🇨🇳 中文 | 🇺🇸 English
my-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.
Web search using multi-engine results
Domestic engines (no proxy needed): bing, baidu, csdn, juejin, sogou
Overseas engines (⚠️ proxy required in mainland China): duckduckgo, exa, brave, startpage
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
Related MCP server: grok-mcp
MCP
Best when you want to connect my-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 my-websearch serve and check it with my-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.
Install the my-websearch skill for your agent first:
npx skills add https://gitee.com/wtznicy/my-websearch --skill my-websearchOn first use, the skill typically follows this path: detect whether a usable my-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:
my-websearch serve
my-websearch statusKeep installation proxy settings separate from runtime proxy settings:
Installation proxy / mirror
Use this when the skill or agent is installing my-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 my-websearchRuntime proxy
Use this when the daemon is already installed and is about to perform live search / fetch work.
This affects the my-websearch network traffic after serve starts, for example:
USE_PROXY=true PROXY_URL=http://127.0.0.1:7890 my-websearch serveIf 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 is for one-shot execution. The local daemon is a long-lived local HTTP service for repeated calls with lower startup friction. Use my-websearch serve as the explicit daemon start command and my-websearch status as the explicit daemon status command.
Windows console note: CLI JSON output is UTF-8. On the legacy Windows console (GBK code page 936) Chinese characters may render as mojibake in cmd/other terminals (redirecting to a file is fine). Run
chcp 65001first, or use Windows Terminal.
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 buildStart the local daemon:
npm run serve
# globally installed: my-websearch serveCheck status:
npm run status -- --json
# globally installed: my-websearch status --jsonRun a one-shot local CLI search:
npm run search:cli -- "open web search" --jsonNotes:
Bare my-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.
--min-results N on search auto-runs additional engines (not already requested) until at least N results come back; defaults to off.
Bing's HTTP mode is the most anti-bot-prone engine. If you hit verification pages often: (a) spread load with engines: ["duckduckgo", "brave"] on Bing-unrelated queries, or (b) set BING_PLAYWRIGHT_FALLBACK=false plus --min-results so a blocked Bing automatically cascades to lighter engines instead of launching a Playwright browser.
cache-clear clears the in-memory search TTL cache — useful after an engine recovers from an outage or when a stale anti-bot page got cached:
my-websearch cache-clearFor the local daemon HTTP API (serve, status, GET /health, POST /search, POST /fetch-*, POST /cache/clear), see docs/http-api.md.
If you are using my-websearch as an MCP server, continue with the MCP-oriented setup below.
The fastest way to get started:
# Basic usage
npx my-websearch@latest
# With environment variables (Linux/macOS)
DEFAULT_SEARCH_ENGINE=bing ENABLE_CORS=true npx my-websearch@latest
# Windows PowerShell
$env:DEFAULT_SEARCH_ENGINE="bing"; $env:ENABLE_CORS="true"; npx my-websearch@latest
# Windows CMD
set MODE=stdio && set DEFAULT_SEARCH_ENGINE=bing && npx my-websearch@latest
# Cross-platform (requires cross-env, Used for local development)
npm install -g my-websearch
npx cross-env DEFAULT_SEARCH_ENGINE=bing ENABLE_CORS=true my-websearchEnvironment Variables:
Variable | Default | Options | Description |
|
|
| Enable CORS |
|
| Any valid origin | CORS origin configuration |
|
|
| Default search engine |
|
|
| Enable HTTP proxy |
|
| Any valid URL | Proxy server URL |
| empty (all engines) | Comma-separated engine names | With |
| 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 |
|
|
| Disable TLS certificate verification for |
|
|
| Server mode: both HTTP+STDIO, HTTP only, or STDIO only |
|
| 1-65535 | Server port (MCP HTTP/S; CLI daemon uses 3210 by default) |
| 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 strategy. Currently only affects Bing: request only, request then Playwright fallback, or force Playwright |
|
| Any curl-cffi-node impersonate target (e.g. | Browser fingerprint target for Bing's HTTP mode. Bing soft-degrades pure-HTTP requests by TLS/HTTP2 fingerprint; this enables Chrome fingerprint impersonation (2/3 requests return full results vs stable degradation otherwise). Fallback to the default HTTP client is automatic if the native module is unavailable |
|
|
| In auto mode, when Bing's request mode hits an anti-bot page: |
|
|
|
|
|
|
| Which Playwright client package to resolve when browser mode is enabled |
| empty | Absolute path or project-relative path | Reuse an existing Playwright client package outside this project |
| empty | Any valid browser binary path | Launch an existing Chromium/Chrome executable without installing bundled browsers |
| empty | Valid Playwright | Connect to an existing remote Playwright browser server |
| empty | Valid Chromium CDP endpoint | Connect to an existing Chromium instance over CDP |
|
|
| Whether Playwright Chromium runs in headless mode |
|
| Positive integer | Timeout for Playwright navigation and Bing result waits |
|
| Valid MCP tool name | Custom name for the search tool |
|
| Valid MCP tool name | Custom name for the CSDN article fetch tool |
|
| Valid MCP tool name | Custom name for the GitHub README fetch tool |
|
| Valid MCP tool name | Custom name for the Juejin article fetch tool |
|
| Valid MCP tool name | Custom name for generic web/Markdown fetch tool |
| empty | Any valid Exa API key | 可选（仅 exa 引擎需要）。exa 的免 key 网页端点已失效，想用 exa 引擎时在 https://dashboard.exa.ai/api-keys 免费申请并配置到 MCP 客户端 env；不配置只影响 exa 一个引擎，其余引擎不受影响 |
|
| Non-negative integer | 全局并发搜索限制（daemon 模式下多客户端生效）。 |
|
|
| 启用引擎指标收集（成功率、缓存命中率、平均响应时间） |
|
|
| 启用安全审计日志（SSRF 拦截、TLS 白名单触发等事件） |
|
|
| 日志级别。 |
|
|
| 抑制启动配置日志（兼容开关， |
Optional: configure EXA_API_KEY (only needed if you want to use the exa engine)
EXA_API_KEY is optional — every other engine (bing, baidu, csdn, juejin, sogou, duckduckgo, brave, startpage) works without it. Only configure it if you want to use exa: its old keyless web endpoint has been shut down by upstream (returns 500), so exa needs a free key from https://dashboard.exa.ai/api-keys, configured in your MCP client:
Claude Desktop (claude_desktop_config.json):
{
"mcpServers": {
"web-search": {
"command": "npx",
"args": ["-y", "my-websearch@latest"],
"env": {
"MODE": "stdio",
"EXA_API_KEY": "<your-key>"
}
}
}
}Cherry Studio / VSCode (Claude Dev): same env field, add "EXA_API_KEY": "<your-key>" to the server's environment variables.
ZCode (~/.zcode/cli/config.json → mcp.servers):
"my-websearch": {
"type": "stdio",
"command": "D:/nodejs/node.exe",
"args": ["D:/path/to/build/index.js"],
"env": {
"MODE": "stdio",
"EXA_API_KEY": "<your-key>"
}
}CLI one-shot (no config file needed):
EXA_API_KEY=<your-key> my-websearch search "query" --engines exa
# Windows PowerShell:
# $env:EXA_API_KEY="<your-key>"; my-websearch search "query" --engines exaIf the key is missing, the exa engine fails fast with an error message that includes these instructions instead of silently returning nothing.
Common configurations:
# Enable proxy for restricted regions
USE_PROXY=true PROXY_URL=http://127.0.0.1:7890 npx my-websearch@latest
# Only if a target website has a broken certificate chain
FETCH_WEB_INSECURE_TLS=true npx my-websearch@latest
# Request first, then fallback to Playwright if available
SEARCH_MODE=auto npx my-websearch@latest
# Force request-only Bing search
SEARCH_MODE=request npx my-websearch@latest
# Full configuration
DEFAULT_SEARCH_ENGINE=bing ENABLE_CORS=true USE_PROXY=true PROXY_URL=http://127.0.0.1:7890 PORT=8080 npx my-websearch@latestProxy guidance for mainland China:
duckduckgo, exa, brave, and startpage are overseas engines and cannot be reached without a proxy from mainland China — they will time out or return errors. Domestic engines (bing, baidu, csdn, juejin, sogou) work without a proxy.
Use PROXY_ENGINES to keep domestic engines on a fast direct connection while routing only the overseas engines through the proxy (avoiding the redirects/timeouts that a global proxy causes for Chinese engines):
USE_PROXY=true PROXY_URL=http://127.0.0.1:7890 PROXY_ENGINES=duckduckgo,exa,brave,startpage npx my-websearch@latestIf a search includes overseas engines but the proxy is off, those engines will fail fast instead of hanging until timeout: my-websearch probes direct connectivity to duckduckgo/brave/startpage (3s timeout, one retry, result cached for 5 minutes) — unreachable engines immediately return a "proxy required, or use domestic engines" error, while reachable engines (e.g. overseas users) work normally. exa is excluded from probing because api.exa.ai is directly reachable from mainland China. When the proxy is on, engines in PROXY_ENGINES are never probed — they go straight through the proxy.
Browser-enhanced Bing fallback and the startpage engine work out of the box: playwright-core is bundled as an optional dependency (auto-installed with the package, no browser download — system browsers are auto-discovered, e.g. Edge on Windows). If that install fails (network/platform), browser-based features degrade gracefully and all other engines stay unaffected.
Optional advanced setups (full Playwright with its own browser, custom module paths, remote/CDP browsers):
Full local Playwright install:
npm install playwright
npx playwright install chromium
SEARCH_MODE=auto npx my-websearch@latestReuse 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 my-websearch@latestReuse a Playwright package that already exists elsewhere on the machine:
PLAYWRIGHT_MODULE_PATH=/absolute/path/to/node_modules/playwright SEARCH_MODE=playwright npx my-websearch@latestConnect 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 my-websearch@latestReuse 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/my-websearch-chrome
# Then connect through CDP
PLAYWRIGHT_PACKAGE=playwright-core PLAYWRIGHT_CDP_ENDPOINT=http://127.0.0.1:9222 SEARCH_MODE=auto npx my-websearch@latestThis 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\my-websearch-chrome"
$env:PLAYWRIGHT_PACKAGE="playwright-core"
$env:PLAYWRIGHT_CDP_ENDPOINT="http://127.0.0.1:9222"
$env:SEARCH_MODE="auto"
npx my-websearch@latestMode behavior:
request: only uses request-based Bing scraping
auto: tries request first, and only falls back to Playwright when request fails and a manually accessible Playwright client + browser are available
playwright: forces Playwright and errors if the configured Playwright client or browser target is unavailable
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.
Clone or download this repository
Install dependencies:
npm installThis 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 buildAdd 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:3211/mcp"
}
}
}VSCode (Claude Dev Extension):
{
"mcpServers": {
"web-search": {
"transport": {
"type": "streamableHttp",
"url": "http://localhost:3211/mcp"
}
},
"web-search-sse": {
"transport": {
"type": "sse",
"url": "http://localhost:3211/sse"
}
}
}
}Claude Desktop:
{
"mcpServers": {
"web-search": {
"type": "http",
"url": "http://localhost:3211/mcp"
},
"web-search-sse": {
"type": "sse",
"url": "http://localhost:3211/sse"
}
}
}NPX Command Line Configuration:
{
"mcpServers": {
"web-search": {
"args": [
"my-websearch@latest"
],
"command": "npx",
"env": {
"MODE": "stdio",
"DEFAULT_SEARCH_ENGINE": "bing",
"ALLOWED_SEARCH_ENGINES": "bing,duckduckgo,exa"
}
}
}
}Windows NPX configuration:
{
"mcpServers": {
"web-search": {
"command": "cmd",
"args": [
"/c",
"npx",
"-y",
"my-websearch@latest"
],
"env": {
"MODE": "stdio",
"DEFAULT_SEARCH_ENGINE": "bing",
"SYSTEMROOT": "C:/Windows"
}
}
}
}Proxy and TLS notes:
my-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, 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 fetchWebContent, since it weakens TLS verification.
Local STDIO Configuration for Cherry Studio (Windows):
{
"mcpServers": {
"my-websearch-local": {
"command": "node",
"args": ["C:/path/to/your/project/build/index.js"],
"env": {
"MODE": "stdio",
"DEFAULT_SEARCH_ENGINE": "bing",
"ALLOWED_SEARCH_ENGINES": "bing,duckduckgo,exa"
}
}
}
}The server provides seven tools: search, resolveLibraryId, queryDocs, fetchCsdnArticle, fetchGithubReadme, fetchJuejinArticle, and fetchWebContent.
For the local daemon HTTP API (serve, status, GET /health, POST /search, POST /fetch-*), see docs/http-api.md.
{
"query": string, // Search query
"limit": number, // Optional: Number of results to return (default: 10)
"engines": string[], // Optional: Engines to use (bing,baidu,csdn,duckduckgo,exa,brave,juejin,startpage,sogou) default runtime-configured engine. Note: duckduckgo/exa/brave/startpage need a proxy from mainland China (see PROXY_ENGINES)
"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"
}
]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"
}
]Used to fetch README content from GitHub or Gitee repositories (Gitee uses the official API, reachable without a proxy).
{
"url": string // GitHub/Gitee repository URL (supports HTTPS, SSH formats)
}Usage example:
use_mcp_tool({
server_name: "web-search",
tool_name: "fetchGithubReadme",
arguments: {
url: "https://gitee.com/wtznicy/my-websearch"
}
})Supported URL formats:
GitHub HTTPS: https://github.com/owner/repo
GitHub HTTPS with .git: https://github.com/owner/repo.git
GitHub SSH: git@github.com:owner/repo.git
URLs with parameters: https://github.com/owner/repo?tab=readme
Gitee HTTPS: https://gitee.com/owner/repo
Gitee SSH: git@gitee.com:owner/repo.git
Response example:
[
{
"content": "<div align=\"center\">\n\n# MyWebSearch MCP Server..."
}
]Fetch content directly from public HTTP(S) links, including Markdown files (.md) and ordinary web pages.
{
"url": string, // Public HTTP(S) URL
"maxChars": number // Optional: max returned content length (1000-200000, default 30000)
}Usage example:
use_mcp_tool({
server_name: "web-search",
tool_name: "fetchWebContent",
arguments: {
url: "https://gitee.com/wtznicy/my-websearch/raw/main/README.md",
maxChars: 12000
}
})Response example:
{
"url": "https://gitee.com/wtznicy/my-websearch/raw/main/README.md",
"finalUrl": "https://gitee.com/wtznicy/my-websearch/raw/main/README.md",
"contentType": "text/plain; charset=utf-8",
"title": "",
"truncated": false,
"content": "# MyWebSearch MCP Server ..."
}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 联网搜索工具：MyWebSearch MCP 全新升级，支持多引擎 + 流式响应..."
}
]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
Brave is the strictest: it throttles consecutive automated requests aggressively — a burst of searches triggers HTTP 429 for minutes (even from residential proxy IPs), and the block window outlasts short cooldowns. Use brave at low frequency; prefer duckduckgo / startpage as the daily overseas engines (they are stable and of similar quality). A 429 on brave fails fast and minResults cascade automatically falls back to other engines.
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, juejin, startpage, sogou
Overseas engines (duckduckgo, exa, brave, startpage) require a proxy from mainland China (see PROXY_ENGINES); domestic engines (bing, baidu, csdn, juejin, sogou) work direct
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
With USE_PROXY=true, PROXY_ENGINES (comma-separated whitelist) limits which engines route through the proxy; empty = all engines proxied. Overseas engines (duckduckgo, exa, brave, startpage) require a proxy from mainland China, while domestic engines stay direct — recommended: PROXY_ENGINES=duckduckgo,exa,brave,startpage
For Clash fake-ip / TUN setups, configure synthetic DNS ranges with FAKE_IP_CIDRS (for example 198.18.0.0/15)
Welcome to submit issue reports and feature improvement suggestions!
Resolves a library/package name into a Context7-compatible library ID, with reputation and quality metadata. Powered by the Context7 documentation index — official, version-specific library docs without needing a separate MCP server.
{
"libraryName": string, // e.g. "Next.js", "express", "prisma"
"query": string, // The user's question, used to rank matches (e.g. "how to implement authentication")
"limit": number // Optional: max matches (default 5, max 10)
}Usage example:
use_mcp_tool({
server_name: "web-search",
tool_name: "resolveLibraryId",
arguments: {
libraryName: "Next.js",
query: "how to set up middleware with auth"
}
})Retrieves up-to-date, version-specific documentation snippets and code examples for a library. Use resolveLibraryId first if you don't know the library ID.
{
"libraryId": string, // Context7-compatible ID, e.g. "/vercel/next.js", "/packages/express" (optional version: "/vercel/next.js@v15.1.8")
"query": string, // The question or task to get relevant documentation for
"limit": number // Optional: max code snippets (default 5, max 10)
}Usage example:
use_mcp_tool({
server_name: "web-search",
tool_name: "queryDocs",
arguments: {
libraryId: "/vercel/next.js",
query: "how to set up middleware with authentication"
}
})Note: Both Context7 tools call the public REST API directly (no API key required at low rate limits). Set
CONTEXT7_API_KEYfor higher rate limits.
Author: wtznicy
This project is a modified fork of Open-WebSearch (originally by Aas-ee) — thanks to the original author for the great work.
Thanks also to these open-source projects:
context7 (Upstash): powers the resolveLibraryId / queryDocs library-docs lookup
fetch (official MCP servers): reference for the fetchWebContent web-fetching design
Fetch full article content from a csdn post URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safe read-only profile is established. The description adds the notion of 'full article content' but discloses nothing about potential anti-scraping blocks, page variation, or response behavior, which would have raised the 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 a single, front-loaded sentence with no filler words. It is slightly thin on context, which keeps it from a 5, but it is appropriately sized for a one-parameter 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?
For a simple one-parameter read-only tool, the description is minimally adequate: annotations cover the safety profile and the schema covers the parameter. However, with no output schema, it does not describe the return format, failure modes, or content limitations, which an agent might need to handle results correctly.
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?
There is a single url parameter with 0% schema description coverage, so the description carries some weight. The phrase 'csdn post URL' clarifies the expected parameter meaning beyond the schema's generic 'uri' format, but it adds little else about format, validation, or accepted URL variants.
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 states a specific verb (Fetch) and resource (full article content from a csdn post URL), making the tool's function clear. However, it does not explicitly differentiate itself from siblings like fetchJuejinArticle or fetchWebContent beyond the platform name, so it stops short of a 5.
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?
There is no explicit guidance on when to use this tool vs. alternatives such as fetchWebContent or fetchJuejinArticle. The CSDN-specific wording implies its context, but no exclusions, prerequisites, or routing logic are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch README content from a GitHub repository URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds no extra behavioral context beyond the obvious fetching action, but doesn't contradict annotations.
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 sentence, extremely concise, and front-loaded with the action and resource. It earns its place without being verbose.
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 is simple (one parameter, no output schema), the description covers the core purpose. However, it lacks guidance on what the returned content format is (e.g., raw markdown) or how it handles non-existent READMEs, which could be important for an agent.
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. It mentions 'GitHub repository URL', which aligns with the single 'url' parameter, but doesn't add details like URL format or accepted patterns. With only one parameter, the description provides minimal but sufficient guidance.
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 fetches README content from a GitHub repository URL, using the specific verb 'Fetch' and a clear resource ('README content from a GitHub repository URL'). It is distinct from siblings like fetchWebContent, though it doesn't explicitly differentiate itself.
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 the tool is for GitHub repository URLs but doesn't specify when to use it over fetchWebContent or search. It gives some context (GitHub README) but lacks explicit exclusions or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full article content from a Juejin(掘金) post URL
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint false, covering the safety profile. The description adds 'full article content' as a slight behavioral qualifier, suggesting it returns the whole article rather than a snippet, but it does not disclose output format, failure behavior, or handling of invalid URLs.
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 sentence with no filler. Every word contributes: verb, resource, and source format. It is front-loaded and immediately tells the agent what the tool does.
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 simple one-parameter tool with safety annotations, the description covers what it does and the target URL type. However, there is no output schema, and the description does not clarify whether the returned content is markdown, HTML, or plain text, leaving some ambiguity about the return contract.
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 input schema only defines a generic uri string with 0% description coverage. The description meaningfully narrows this by specifying the URL must be a Juejin post URL, which is valuable context the schema lacks. For a single parameter, this is sufficient compensation for the coverage gap.
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?
Description clearly states the verb 'Fetch' + resource 'full article content' + target 'Juejin post URL'. It is unambiguous about the operation and platform, and the platform reference implicitly separates it from siblings like fetchCsdnArticle and fetchGithubReadme. It does not explicitly differentiate itself from the broader fetchWebContent tool but still makes the scope clear.
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 establishes a clear context: use this when targeting a Juejin post URL. It does not explicitly state when not to use it nor name alternatives, leaving the agent to infer the distinction from sibling tool names and the platform mention.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch content from a public HTTP(S) URL (supports Markdown files and normal web pages)
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | Return the raw response body (HTML/plain text) without extraction | |
| url | Yes | ||
| maxChars | No | ||
| startIndex | No | Character offset to start reading from (for paging through long content) | |
| readability | No | ||
| includeLinks | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the public URL scope and Markdown/web page support. It does not disclose extraction behavior, the effect of readability/raw, or whether output is transformed. This is adequate given annotations, but the additional behavioral context is thin.
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, front-loaded sentence with no filler. Every word contributes to the core purpose, and it is appropriately sized for a tool whose annotations cover safety. It is concise without losing necessary information.
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?
This is a six-parameter tool with no output schema and several closely related sibling tools. The one-sentence description omits paging via startIndex, the purpose of readability/raw, the response format, and when to choose specialized fetchers. Annotations only cover safety, not operational completeness, so the definition leaves significant gaps.
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 only 33% (raw and startIndex have descriptions). The description only adds meaning to the url parameter by specifying 'public HTTP(S)'. It does not compensate for the undocumented maxChars, readability, includeLinks, or the overall behavior of raw. The tool description fails to help an agent understand five of the six 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 verb ('Fetch'), resource ('content from a public HTTP(S) URL'), and supported content types (Markdown files and normal web pages). It is readily distinguishable from specialized siblings such as fetchGithubReadme or fetchCsdnArticle, but it does not explicitly name them, so it falls short of a 5.
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 gives no guidance on when to use this tool versus the specialized fetch tools (fetchCsdnArticle, fetchGithubReadme, fetchJuejinArticle) or alternatives like search/queryDocs. There are no conditions, exclusions, or selection criteria. The mention of supported formats only implies scope, not when to prefer this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get up-to-date, version-specific official docs and code snippets for a Context7 library ID (e.g. /vercel/next.js, version-pinnable like /vercel/next.js@v15.1.8). Use with resolveLibraryId for official documentation lookups — direct, reliable, no proxy needed.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of code snippets to return (default 5) | |
| query | No | The question or task to get relevant documentation for (optional; defaults to an overview when omitted, e.g. 'how to set up middleware with auth') | |
| libraryId | Yes | Exact Context7-compatible library ID (e.g. /vercel/next.js, /packages/express; optional version like /vercel/next.js@v15.1.8) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent behavior. The description adds meaningful behavioral context: results are up-to-date, version-pinnable, and obtained without a proxy. It does not describe return format or pagination, but those are minor for a read-only docs lookup tool.
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 sentences, front-loaded with the core action, and each sentence carries useful information: what it does and how to use it. No filler or redundancy.
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 read-only tool with rich annotations and full schema coverage, the description covers purpose, usage workflow, and result expectations. It lacks an explicit return-value shape and edge-case behavior, but the overall picture is adequate.
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 100%, and the schema already provides examples for libraryId, including version suffixes. The tool description repeats those examples rather than adding new semantic detail for query or limit, so it does not go beyond the schema baseline.
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 states a specific verb ('Get') and resource ('official docs and code snippets for a Context7 library ID'), with concrete examples. It also distinguishes this tool from web-fetch and search siblings by framing it as 'official documentation lookups' and naming resolveLibraryId as its companion.
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 explicitly advises using this tool with resolveLibraryId for official documentation lookups and gives a clear benefit ('direct, reliable, no proxy needed'). It does not explicitly state when to prefer alternatives like search or fetchWebContent, so exclusions are missing, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PREFERRED for official docs: resolve a library/package name to a Context7 library ID (e.g. /vercel/next.js). Use this (then queryDocs) FIRST when the task needs official library/framework documentation — more reliable than web search and works without a proxy.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of library matches to return (default 5) | |
| query | No | The user's question or task, used to rank results by relevance (optional; defaults to the library name when omitted, e.g. 'how to implement authentication') | |
| libraryName | Yes | The library or package name to search for (e.g. 'Next.js', 'express', 'prisma') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive. The description adds operational context beyond annotations: proxy-independent behavior and reliability relative to web search. These behavioral traits help the agent decide under network constraints.
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 tight sentences: the first states purpose with an example, the second gives usage priority and comparison. There is no filler, and the key directives ('PREFERRED', 'FIRST') are front-loaded.
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 simple lookup tool, the description covers when to use it, what it returns (a Context7 library ID with an example format), and how to chain it with queryDocs. With no output schema, the gap around empty results or error behavior is minor but not fully addressed.
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 input schema covers 100% of parameters with clear descriptions, so the baseline applies. The description adds a useful output example and implies the query-reranking behavior, but does not materially enhance parameter understanding beyond the schema.
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 states a specific verb and resource — 'resolve a library/package name to a Context7 library ID' — and provides a concrete example ('/vercel/next.js'). It clearly differentiates the tool from queryDocs and web search by positioning it as the resolution step before queryDocs.
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?
It explicitly tells the agent when to use the tool ('when the task needs official library/framework documentation'), in what order ('then queryDocs'), and why it beats alternatives ('more reliable than web search and works without a proxy'). This is direct, actionable selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the web across multiple engines with no API key required. searchMode: omit/auto = server SEARCH_MODE; request/playwright force that mode. For OFFICIAL library/framework documentation, prefer resolveLibraryId + queryDocs (more reliable, works without proxy). Use the site: operator for site-specific queries (e.g. "update site:docs.elastic.co").
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| engines | No | ||
| minResults | No | Auto-run additional engines when fewer than this many results come back (default: disabled) | |
| searchMode | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, open-world, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond annotations: no API key required, searchMode semantics for server default versus forced modes, and a reliability caveat about proxy usage. This meaningfully enriches what the agent knows before calling.
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 three tightly packed sentences with no filler. The primary action is front-loaded, followed by mode semantics and then routing guidance. Every sentence earns its place.
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 web search tool with five parameters and no output schema, the description covers the main decision points: when to search, when to use alternatives, how to scope queries, and how searchMode behaves. Minor gaps remain around result format and error behavior, but the description is largely complete for correct invocation.
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 only 20%, so the description must compensate. It does add meaning for searchMode and query, including the site: operator pattern, but it does not clarify limit defaults, engines normalization/aliases, or minResults behavior beyond what the schema already states. Partial compensation only.
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 states a specific verb and resource: 'Search the web across multiple engines.' It immediately clarifies a key differentiator, 'no API key required,' and distinguishes itself from sibling documentation tools by directing official docs to resolveLibraryId + queryDocs.
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 explicitly tells the agent when NOT to use this tool: for official library/framework documentation, prefer resolveLibraryId + queryDocs because they are more reliable and work without a proxy. It also gives concrete query guidance via the site: operator, making usage conditions actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.11fetchCsdnArticlefetchGithubReadmefetchJuejinArticlefetchWebContentqueryDocsresolveLibraryIdsearchMost tools have clear, distinct purposes: search for general web search, fetchWebContent for arbitrary URLs, and site-specific fetchers for CSDN/Juejin/GitHub READMEs. There is some potential confusion between fetchWebContent and the specialized fetch tools for the same URLs, but the descriptions make the intended use fairly clear.
The naming pattern is mostly consistent, with four fetch* tools, plus search, resolveLibraryId, and queryDocs. All names use lowercase camelCase and a verb-first style, though search is less descriptive than searchWeb and the three non-fetch verbs break the dominant fetch pattern.
Seven tools is well-scoped for a web search and content retrieval server. Each tool serves a legitimate purpose without the set feeling bloated or overly minimal.
The server covers the core domain well: general web search, generic page fetching, specialized article/README extraction, and a dedicated official-docs lookup flow. No obvious dead ends or critical missing operations are apparent for the stated purpose.
Search GitHub, npm, PyPI, StackOverflow, ArXiv from one MCP — built for coding agents.
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.
Serper MCP — wraps the Serper Google Search API (serper.dev)
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/wtznicy/my-websearch'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
