mcp-searxng: Private Web Search for MCP Clients, With a SearXNG Instance You Control
Private web search for AI assistants via SearXNG — supports Claude, Cursor, and any MCP client
At a glance
- What is it?
- mcp-searxng is a TypeScript MCP server that exposes SearXNG search and URL reading to Claude, Cursor and other MCP clients. It is a good fit if you already run or trust a SearXNG instance; it is the wrong tool if you want a managed search API with someone else operating the index.
- Who is it for?
- Adopt mcp-searxng if you already operate a SearXNG instance or can point at one you trust, and if you want search plus URL reading inside an MCP client without a paid search-vendor key. Do not adopt it if you have no SearXNG deployment and no intention of running one, or if you need a managed index with a vendor SLA, because this project is a client to a search service you supply.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap mcp-searxng fills between an AI assistant and a search engine
An MCP client such as Claude Desktop or Cursor can call tools, but it has no built-in way to search the web. The usual fix is a vendor search API, which means an API key, a per-query bill, and queries leaving your infrastructure for someone else's index. mcp-searxng takes the other route. It is a standalone Node.js process that speaks the Model Context Protocol and translates tool calls into requests against a SearXNG instance.
The project's own comparison table, dated 2026-07-29 and covering Brave MCP, Exa MCP and Firecrawl MCP, lists self-hosting and no-API-key operation as the two rows where mcp-searxng differs from all three. That is the whole pitch in one line: you bring the search backend, the server brings the MCP plumbing. The audience is engineers who already run SearXNG, or who are willing to, and who want their assistant's search traffic to land on a host they picked rather than a vendor endpoint.
The README is careful about what this buys you. It states plainly that privacy depends on the SearXNG deployment, that a public instance receives the query and may log it, and that neither SearXNG nor this integration provides anonymity by itself. That caveat is worth taking literally. Running this server against a random public instance is a different privacy posture from running it against your own.
What the server actually does with a query
The architecture is a proxy with policy in the middle. The MCP client calls a tool; the server validates the call, checks its in-memory cache, and if there is no hit, issues an HTTP request to the SearXNG API and reshapes the response into what the client expects.
Search is not a single endpoint passthrough. The README lists general, news and article queries with pagination, time-range, language and safe-search filters, a min_score relevance filter, and a per-call response_format that selects formatted text or raw JSON, with SEARXNG_DEFAULT_RESPONSE_FORMAT setting the operator default. Results are not just links: text results surface SearXNG answers, corrections, suggestions and infoboxes ahead of the result list, so the model sees the engine's own computed answer when one exists. A separate tool wraps SearXNG's /autocompleter endpoint for query suggestions, and another reads the instance /config to report configured categories, engines, defaults, locales and plugins.
URL reading is the second half. The server fetches a page, converts it to Markdown in a content-type-aware way, and supports bounded PDF text extraction plus pagination, section filtering, paragraph ranges and heading extraction. That is a deliberate design choice: rather than dumping an entire page into the context window, the caller can ask for a slice. There is no claim in the material about extraction fidelity across arbitrary pages, so treat PDF handling as a convenience rather than a document pipeline.
Failover, fan-out and the caching layer
SEARXNG_URL accepts more than one instance. Replicas are separated by semicolons, for example https://one.example.com;https://two.example.com. By default the server fails over in order: if the first replica does not answer, the next is tried. With SEARXNG_FANOUT enabled, the server instead queries all healthy replicas in parallel and merges the results. Failover buys availability; fan-out buys coverage at the cost of more upstream requests per tool call. The README does not describe the merge or deduplication rules, so if result ordering matters to your application, that is a behaviour to inspect in the source rather than assume.
Both search results and URL content are cached in memory with a configurable TTL and least-frequently-used eviction. LFU rather than LRU is an interesting pick. It favours entries that get hit repeatedly, which suits a pattern where an assistant re-reads the same documentation page across a session, and it penalises one-off fetches. The trade-off is that a newly popular URL can be evicted while an old, frequently requested one lingers until its TTL expires. The cache is in-memory, so it does not survive a restart, and the README does not describe a shared cache for multi-process deployments.
Getting it running: the config block and the keys that matter
The README's quick start is a single JSON block for an MCP client config such as claude_desktop_config.json. The server is launched with npx -y mcp-searxng, and the one required environment variable is SEARXNG_URL, set to your instance, for example https://searxng.example.com. That is the minimum viable setup: one command, one URL.
Beyond that, the keys named in the material are SEARXNG_FANOUT for parallel querying across replicas, SEARXNG_DEFAULT_RESPONSE_FORMAT for the operator-level output format, and the per-call response_format and min_score parameters. Caching TTL is described as configurable but the variable name is not given in the supplied text, so check the repository before writing it into a deployment manifest. Proxy support is described as global or per-tool for both search and URL-reader traffic.
The project also ships an optional HTTP transport built on the MCP SDK v2 Streamable HTTP mode, with opt-in hardening, rate limiting and what the README calls bounded stateless compatibility for serverless or horizontally scaled deployments. The README notes that modern 2026-07-28 requests and retained legacy clients share the same tool and resource surface. Docker images are published under isokoliuk/mcp-searxng on Docker Hub, and the README points to a client configuration cookbook with recipes for Claude Desktop, Claude Code, Codex CLI, Cursor, VS Code, Windsurf, Cline and OpenCode. Those recipes are the right starting point rather than guessing at each client's schema.
SSRF blocking, browser solvers and the limits of both
web_url_read blocks private and internal URLs and redirects by default in all transport modes. For a tool that fetches arbitrary URLs on behalf of a language model, that is a sensible default, and it is on unless you change it. It is also a constraint: internal documentation hosts, staging environments and split-horizon DNS names will be refused, and the failure will look like a fetch error rather than a policy decision unless you know the guard is there.
The browser solver support is the most operationally heavy feature. For each uncached URL that passes static URL validation and a HEAD size preflight, the server can optionally acquire a browser session from FlareSolverr, Byparr, or both, then replay the returned user-agent and scoped cookies through the bounded URL reader. In dual-provider mode FlareSolverr is always primary and Byparr is attempted only after a busy or transient-unavailable primary. The README states that FlareSolverr 3.5.0 and Byparr 2.1.0 were verified on 2026-07-30, and gives image digests for the verified linux/amd64 manifests.
One documented failure mode deserves attention: client cancellation stops local work promptly, but a remote browser may continue until its configured provider timeout after the HTTP client disconnects. If your users cancel often, you are still paying for browser sessions you no longer want. The README also notes an HTML fallback for public instances that reject format=json, which is a useful escape hatch but implies a second parsing path with its own breakage surface when an instance changes markup.
Where it is the wrong tool
The clearest disqualifier is not having a SearXNG instance. mcp-searxng does not ship a search index. It is a client. If you point it at nothing, it does nothing, and the README's own framing says you still operate or select the underlying instance. Teams that want search working in ten minutes without running a service should use a hosted search MCP server instead, accepting the API key and the vendor seeing the queries.
The second case is scale. The cache is in-memory and the README describes stateless HTTP compatibility for serverless deployments, but there is no shared cache described across processes. Several replicas behind a load balancer will each hold their own cache and their own LFU state, so cache hit rates fall as you scale out. If your assistant traffic is high enough that upstream SearXNG load matters, that is a design constraint to plan around rather than a tuning knob.
The third case is anonymity. If the requirement is that queries cannot be attributed to you at all, this project does not meet it and says so. An operator-controlled instance avoids trusting a third-party search operator, which is a real reduction in exposure, but it is not the same property.
How it compares with Brave MCP and Exa MCP
The difference is where the index lives. Brave MCP and Exa MCP are front ends to vendor-operated search infrastructure: you supply an API key, the vendor runs the crawler, the index and the query path, and the MCP server is a thin adapter over that API. mcp-searxng inverts the arrangement. The MCP server is the part you install, and the search service is the part you supply. SearXNG itself aggregates results from other engines, so the underlying index is still someone else's, but the query path, the logging and the retention policy sit on a host you choose.
The comparison table in the README also marks URL reading, pagination and self-hosting as differentiators, with Firecrawl MCP listed as partial on self-hosting. Read that table as a statement of interface coverage rather than a quality ranking. It says nothing about result relevance, latency or extraction accuracy, and the material does not contain measurements for any of those.
A practical middle path exists inside the project's own framing: point SEARXNG_URL at a trusted public instance if you do not want to run one, accepting that the instance receives and may log your queries. That is a smaller operational commitment than self-hosting, and the README is explicit that the privacy properties change accordingly.
Maintenance cost, licence and what to check before adopting
The project is MIT licensed, which permits commercial and private use, modification and redistribution with the licence and copyright notice retained. That is the standard permissive arrangement, and it also means there is no warranty and no support obligation from the author. Nothing here is legal advice; if you redistribute the server inside a product, have counsel read the MIT text rather than this paragraph.
Maintenance effort comes from four places, not from the server's own code. You maintain the SearXNG instance and its engine configuration. You maintain the browser solver containers if you enable them, and the README pins specific verified versions (FlareSolverr 3.5.0, Byparr 2.1.0) with image digests, which implies version drift is something the project tracks deliberately. You maintain the MCP client configuration across whichever assistants your team uses, and the cookbook exists because those schemas differ. And you absorb upstream SearXNG API changes, which is where the HTML fallback matters.
The release history shows three releases between 2026-08-21 and 2026-09-09, including a major version bump at v2.0.0. A major bump inside a three-week window is a signal to read the changelog before upgrading rather than pinning blindly or upgrading blindly. For a first evaluation, the concrete next step is to run the npx command from the quick start against one instance with SEARXNG_DEFAULT_RESPONSE_FORMAT set to raw JSON, confirm the tool returns structured results, then enable SEARXNG_FANOUT only after you have a second replica answering.
Editorial conclusion
Adopt mcp-searxng if you already operate a SearXNG instance or can point at one you trust, and if you want search plus URL reading inside an MCP client without a paid search-vendor key. Do not adopt it if you have no SearXNG deployment and no intention of running one, or if you need a managed index with a vendor SLA, because this project is a client to a search service you supply. Verify three things first: that your instance returns JSON for the search endpoint (or enable the HTML fallback), that SEARXNG_URL points at a reachable instance with the replicas you intend, and that web_url_read's SSRF blocking does not reject hosts you legitimately need.
Community notes