Open-WebSearch MCP

Quick Verdict

Open-WebSearch is a practical choice for developers who want to add web search and public-page retrieval to a local AI client without first buying access to a commercial search API. The Apache-2.0 community project can run as an MCP server, a one-shot CLI, or a long-lived local daemon. As of July 21, 2026, the current npm package is open-websearch 2.1.11. It can combine results from several engines and then fetch selected pages or GitHub READMEs for closer inspection.

The tradeoff is reliability and trust. These engines are reached through page requests or optional browser automation, not through a guaranteed commercial contract. HTML changes, rate limits, bot checks, regional behavior, and JavaScript rendering can all break a previously working query. Retrieved pages are also untrusted input: text on a site may try to instruct an agent to reveal data or call another tool. Use local STDIO or a daemon bound only to loopback for initial testing, pin version 2.1.11, and never keep a version below 2.1.7. Release 2.1.7 fixed a high-severity SSRF flaw in fetchWebContent.

Best For

• Developers adding occasional web research to Claude Desktop, Cursor, Cherry Studio, or another MCP host.
• Technical researchers who can tolerate failed fetches and verify important claims against original sources.
• Shell users who want the same search capability in scripts, one-shot commands, and agent workflows.
• Teams evaluating a local retrieval component before committing to a hosted search vendor.
• Not ideal for workloads that require an SLA, deterministic ranking, contractual support, or an unauthenticated service exposed to a shared network.

Key Features

Open-WebSearch exposes three operating paths. MCP connects the tools to an AI host; the CLI handles direct search and fetch commands; open-websearch serve starts a reusable local HTTP daemon with health and action endpoints. The search layer covers engines such as Bing, Baidu, DuckDuckGo, Brave, Exa, Startpage, and Sogou, with an allowlist for narrowing the available set. Retrieval includes generic public HTTP(S) pages, GitHub READMEs, and targeted handlers for several developer-content sites.

Bing can use request, automatic fallback, or Playwright mode. Playwright is optional rather than bundled, so browser-assisted behavior must be installed or connected deliberately. That separation is useful, but it also introduces a larger trust boundary. A CDP connection to a normal Chrome profile may expose cookies, signed-in pages, and active sessions to the process. Use a dedicated browser profile without personal accounts, keep CDP on loopback, and do not connect the service to a remote browser endpoint you do not control.

Version history matters here. Release 2.1.7 added DNS-aware target checks, safer redirect validation, and browser-path guards after an SSRF report involving private or local destinations. Version 2.1.11 is the current package baseline. The fix reduces a specific class of risk; it does not turn the daemon into an authenticated multi-user gateway.

Use Cases

A sensible research flow is search first, inspect the result list, and fetch only the few pages that answer the question. This keeps unknown content out of the model context until it is needed. The GitHub README fetcher is useful for checking installation and configuration details during development. The CLI works well for low-frequency monitoring or reproducible notes, provided failures are recorded rather than interpreted as proof that a page or fact does not exist.

Agent use needs a second control layer. Tell the model that fetched text is evidence, not authority. A page must not be allowed to grant itself permission to read files, run commands, send messages, or mutate external systems. Any tool with side effects should require a separate user decision. If the daemon is shared, place authentication, request limits, destination policy, and log redaction in front of it rather than relying on CORS as a security boundary.

Pricing

The source and core package are free under Apache 2.0, and the search path does not require an API key. Costs still exist: compute, an optional browser runtime, maintenance, and retries when parsers stop matching a site. A free package can be more expensive than a hosted API when engineers spend time repairing unstable extraction.

Pin 2.1.11 in reproducible environments. Avoid leaving production automation on @latest, because an unreviewed package update can change engines, parsers, dependencies, or behavior. Treat 2.1.7 as the absolute security floor due to the SSRF remediation, and check global installations, container layers, and lockfiles for older copies.

Pros

• One project supports MCP, CLI, and a reusable local daemon.
• Apache-2.0 licensing and an identifiable 2.1.11 package make the code and deployment baseline easy to audit.
• Multiple engines reduce complete dependence on one result page and parser.
• Search-then-fetch supports tighter control over how much external text enters model context.
• Browser automation is optional, so a basic installation does not need to inherit a full browser session boundary.
• The 2.1.7 security release documents the SSRF class and the minimum safe upgrade point clearly.

Cons

• Scraping can fail after layout changes, rate limiting, bot checks, or dynamic rendering changes.
• Search quality, metadata completeness, and ordering vary by engine and environment.
• Untrusted pages can contain prompt injection aimed at an agent with more powerful tools.
• The local HTTP service does not provide a complete multi-user authentication and authorization layer by itself.
• Reusing Chrome through CDP can expose cookies, authenticated sessions, and open-page data.
• Remote browser endpoints and broad CORS settings create avoidable network exposure.
• The SSRF issue remains relevant wherever pre-2.1.7 packages survive in old images or lockfiles.
• There is no commercial SLA or guaranteed parser repair time.

Alternatives

FAQ

Which Open-WebSearch version should I install?

As of July 21, 2026, npm reports version 2.1.11. Pin that exact version for reproducible work and use nothing below 2.1.7.

What did version 2.1.7 fix?

It fixed a high-severity SSRF issue in fetchWebContent, including bypasses involving bracketed IPv6 literals, DNS resolution to private addresses, redirect chains, and browser-assisted fetch paths. Upgrade even if the service currently runs only on a developer machine.

Can I expose the daemon directly to my team?

Not safely without another control layer. Bind it to loopback for individual use. For shared use, add identity, authorization, limits, destination rules, audit records, and sensitive-log handling.

Can an agent execute instructions found on a fetched page?

No. Web content is untrusted data. It may inform an answer, but it cannot authorize file access, command execution, outbound messages, or write operations. Those actions need independent approval.

When should I choose a commercial search service instead?

Choose one when the workflow needs an SLA, predictable quotas, contractual support, stable result formats, or governance documentation. Open-WebSearch is better suited to local experiments and research tasks that can tolerate partial failure.

Bottom Line

Open-WebSearch gives technical users a flexible Apache-licensed bridge from local agents to multi-engine search and page retrieval. Its best deployment is intentionally small: version 2.1.11 pinned, no package below 2.1.7, search before fetch, untrusted web text isolated from tool authority, and local services kept behind a strict network boundary. If the workflow requires shared exposure, authenticated browser sessions, or production reliability, add a real gateway and browser isolation or select a hosted search product with a clearer operational contract.