Open Websearch
Route agent web lookups through the right search engine or fetch path for English, Chinese, GitHub, or single-URL content.
Overview
open-websearch is an agent skill most often used in Idea (also Validate, Build) that selects search engines and fetch modes for agent-driven web research.
Install
npx skills add https://github.com/aas-ee/open-websearch --skill open-websearchWhat is this skill?
- Heuristic engine map: Startpage/Bing for broad English, Baidu/CSDN/Juejin for Chinese developer sources
- Dedicated paths: fetchGithubReadme for repos, fetchWebContent for article or doc URLs
- Anti-bot guidance: switch engines or SEARCH_MODE=auto when Bing verification pages appear
- Setup ladder: validate/reconnect, local CLI/daemon, or full install only when workspace lacks open-websearch
- TLS escape hatch documented only for broken certificate chains via FETCH_WEB_INSECURE_TLS
- 6 named retrieval modes: startpage, bing, baidu, csdn, juejin, plus GitHub README and web content fetch
Adoption & trust: 780 installs on skills.sh; 1.4k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent keeps using one broken or wrong search engine for the query language, region, or URL type you actually need.
Who is it for?
Solo builders running agents that need bilingual web discovery, GitHub README pulls, or single-page doc extraction.
Skip if: Fully offline workflows, paid SERP APIs you already standardized on, or compliance environments that forbid arbitrary web fetch.
When should I use this skill?
Agent needs broad web search, Chinese-source discovery, GitHub README retrieval, or single-URL content fetch via open-websearch.
What do I get? / Deliverables
Lookups follow documented engine and fetch rules, with fallback and setup paths so research and doc fetches complete without redundant installs.
- Search results from the chosen engine
- Fetched README or web page content for downstream summarization
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Idea research is the primary shelf because engine selection and fetch tooling matter most when validating markets and gathering sources early. Research subphase fits heuristic engine choice, GitHub README retrieval, and targeted page fetches before build commitments.
Where it fits
Compare competitor positioning with Startpage before committing to a niche.
Use Baidu and Juejin to map Chinese-market alternatives in the same category.
fetchWebContent on a pricing page to sanity-check positioning before prototyping.
fetchGithubReadme on an integration repo before wiring an API dependency.
How it compares
Procedural routing over generic “search the web”—not a hosted search API product by itself.
Common Questions / FAQ
Who is open-websearch for?
Indie developers and agent operators who use open-websearch MCP/CLI and want consistent engine and fetch behavior across research tasks.
When should I use open-websearch?
Use it in Idea for market and competitor research, in Validate when checking pricing or landing examples, and in Build when fetching GitHub READMEs or specific documentation URLs.
Is open-websearch safe to install?
Web search and fetch expose network traffic and page content; review the Security Audits panel on this page and avoid FETCH_WEB_INSECURE_TLS unless you understand the certificate risk.
SKILL.md
READMESKILL.md - Open Websearch
# Engine Selection Engine choice is heuristic, not mandatory. If a preferred engine is unavailable, restricted, or clearly low quality for the current query, switch to a better available engine. ## Broad public web search - Prefer `startpage` for general English-language discovery. - Use `bing` when Startpage is insufficient or when a second broad engine is useful. ## Chinese-language or China-hosted sources - Use `baidu` for broad Chinese web discovery. - Use `csdn` for developer blog content and tutorial-style posts. - Use `juejin` for Chinese developer posts and frontend/backend engineering topics. ## Source-specific retrieval - Use `fetchGithubReadme` for GitHub repositories. - Use `fetchWebContent` for a specific article, doc page, or Markdown URL. ## Failure handling - If `bing` returns verification or anti-bot pages, prefer `SEARCH_MODE=auto` or switch engines. - If a page fetch fails due to network restrictions, check proxy configuration. - If `fetchWebContent` fails on a site with a broken certificate chain, only then consider `FETCH_WEB_INSECURE_TLS=true`. # Setup Use these setup paths only when the current workspace does not yet have a usable `open-websearch` path. ## Choose the smallest matching path - Prefer validation or reconnection if the user already configured `open-websearch` and the issue is only that the current workspace is not seeing it. - Prefer local CLI/daemon mode when the runtime can launch `open-websearch` directly and no better existing path is already active. - Prefer existing MCP validation or reconnection when the workspace is supposed to expose the tools already. - Prefer an existing HTTP endpoint if the user already has a reachable `open-websearch` server. - Prefer local source/build mode if the user already has a local checkout with a usable entrypoint. ## Local CLI/daemon mode Use when: - the runtime can launch `open-websearch` directly - the user wants the lowest-friction local setup - there is no already-working MCP or HTTP path to reuse Stage script: 1. Collect prerequisites. - First check whether the command is already available. - Confirm whether the user wants a quick one-shot path or a reusable local CLI/daemon path. - Confirm whether the environment needs npm proxy, npm mirror, or runtime proxy settings. - Check whether the user already has a reusable local checkout instead of needing package installation. - If daemon startup is expected to be followed immediately by live `search`, `fetch-web`, or other public-page retrieval, confirm runtime proxy needs before starting the daemon. If the goal is only `serve` plus `status`, runtime proxy can wait. 2. Confirm risky actions. - Ask before package installation, global installation, daemon startup, or MCP/client config changes. 3. Perform the smallest matching action. - If the command already exists, reuse it. - If package installation is needed, guide installation before writing config. - Start or validate the local daemon path with explicit commands: `open-websearch serve` to start and `open-websearch status` to check readiness. - Do not treat bare `open-websearch` as the recommended daemon start command for agent automation. - If the host runtime still needs MCP exposure, only then add or adjust MCP/client config. 4. Validate. - Confirm daemon readiness with `open-websearch status`. - If possible, run a minimal one-shot smoke check. - Do not treat installation alone as completion. 5. If package installation hangs, times out, or fails on network access, suspect proxy or mirror configuration before treating it as an `open-websearch` failure. Useful npm-oriented guidance: - One-shot proxied installs may work better with explicit npm flags such as `npm --proxy ... --https-proxy ... install ...`. - Persistent npm access may work better with `npm config set proxy`, `npm config set https-proxy`, and `npm config set registry`. - Do not assume runtime env vars like `USE_PROXY` or `PROX