mcp-searxng：把 SearXNG 接到 AI 助手上的 MCP 服务器

它解决的其实是一个凭据与归属问题

多数 AI 客户端的联网搜索走的是搜索厂商的托管 API：注册、拿 key、按量计费，查询内容经过第三方。mcp-searxng 换了一条路径。它是一个独立的 Node.js 进程，通过 MCP 协议向 Claude、Cursor 等客户端暴露搜索与读取工具，后端则指向一个 SearXNG 实例。README 的对比表把这件事写得很直白：在 Brave MCP、Exa MCP、Firecrawl MCP 与它自己之间，只有它同时勾选了自建与免 API key。

目标读者因此相当具体。已经有一台 SearXNG 在跑的人，接上这个服务器几乎是零成本增量；在意查询归属、不希望把检索行为交给搜索厂商的人，也多了一个可选项。但 README 同时给了一句必须读进去的限定：隐私取决于 SearXNG 的部署方式，运维方自控的实例可以避免信任第三方搜索运营者，公共实例照样会收到查询并可能记录，SearXNG 与本集成本身不提供匿名性。这句话把项目的定位划得很清楚，它是把搜索的所有权交回给你，不是把你藏起来。

工具面：搜索、正文读取与实例自省

从 README 描述看，服务器暴露的能力分三类。第一类是搜索：支持 general、news、article 查询，带分页、时间范围、语言与 safe-search 过滤，可用 min_score 做相关性过滤，输出格式按调用选择 formatted-text 或 raw-JSON，也可以由运维方用 SEARXNG_DEFAULT_RESPONSE_FORMAT 设默认值。返回内容里，SearXNG 的 answers、corrections、suggestions 与 infoboxes 会排在结果列表之前，这一点对需要直接答案而非十条蓝色链接的场景有实际意义。

第二类是 web_url_read，做 URL 正文读取，按 content-type 转 Markdown，包含有边界的 PDF 文本抽取，支持分页、章节过滤、段落区间与标题提取。注意 SSRF 保护是默认开启的：README 说 web_url_read 在所有传输模式下都会拦截私有与内部 URL 及其重定向。这是一条硬边界，不是可选项。

第三类是自省与辅助：通过 SearXNG 的 /autocompleter 端点做查询补全，通过 /config 查看实例配置的类别、引擎、默认值、locale 与插件。后者的价值常被低估，它让客户端在动手搜索前先知道这个实例到底能搜什么。

实例故障转移与扇出：SEARXNG_URL 的两种语义

配置项里最有设计感的是 SEARXNG_URL。它接受分号分隔的多个 URL，例如 https://one.example.com;https://two.example.com，语义是互为副本。默认行为是按顺序故障转移：前一个不可用就换下一个。开启 SEARXNG_FANOUT 后语义改变，服务器会并行查询所有健康副本并合并结果。

这两种模式对应两种不同的失败假设。顺序故障转移假设副本之间结果等价，要的是可用性；扇出假设单个实例的结果覆盖不全，要的是召回，代价是延迟取决于最慢的那个副本，并且合并逻辑要处理重复项。README 没有展开合并去重的具体规则，这一点需要自己验证。

另外两条降级路径值得留意。一是 HTML fallback：公共实例常常拒绝 format=json，此时可以选择解析 HTML 页面拿结果。这等于把结构化接口换成对页面结构的依赖，页面改版就会失效，属于能用但不稳的兜底。二是 Lite Tools Mode，为上下文窗口很小的本地模型提供精简的工具 schema。这是给本地小模型让路的务实做法，代价是功能面收窄。

浏览器求解器：能力很强，边界也很硬

对每个未命中缓存、通过静态 URL 校验并且通过 HEAD 大小预检的 URL，服务器可以选择向 FlareSolverr、Byparr 或两者申请浏览器会话，然后把返回的 user-agent 与限定范围的 cookie 回放到有边界的 URL 读取器里。双提供方模式下 FlareSolverr 始终是主，只有在主提供方繁忙或暂时不可用时才尝试 Byparr。README 给出的验证信息很具体：FlareSolverr 3.5.0 与 Byparr 2.1.0 于 2026-07-30 验证，并附了 linux/amd64 多架构 manifest 的 digest。

这里有一个必须提前接受的失败模式：客户端取消会及时停止本地工作，但远端浏览器可能在 HTTP 客户端断开后继续运行，直到其配置的提供方超时。也就是说，用户按了停止，浏览器那边的资源还在烧。对按量计费的浏览器服务或者资源紧张的机器，这是实打实的成本。

还有一层判断：引入浏览器求解器意味着你的部署里多了一个能访问任意 URL 的组件。SSRF 保护拦的是私有与内部地址，但公网抓取本身的风险、以及把外部内容回灌进模型上下文的风险，并不在这个项目的职责范围内。

HTTP 传输与缓存：为横向扩展准备的部分

默认形态是 stdio，本地进程，客户端拉起。README 还提供可选的 MCP SDK v2 Streamable HTTP 模式，带可选的硬化、限流，以及为无服务器或横向扩展部署准备的有界无状态兼容。文档称 2026-07-28 的现代请求与保留的旧客户端共享同一套工具与资源面。

缓存方面，搜索结果与 URL 正文都放在内存里，TTL 可配，淘汰策略是 LFU。这里有个容易忽略的推论：内存缓存意味着多副本部署时缓存不共享，每个实例各存一份，命中率随副本数下降。用 Streamable HTTP 做水平扩展的人应该先想清楚这一点，README 没有提供外部缓存后端的选项。

代理支持是全局或按工具的 HTTP/HTTPS 代理，分别作用于搜索流量与 URL 读取流量。对需要在出网链路上做审计或收敛出口的环境，这是必要的开关。

什么时候它反而是错的工具

最直接的一种情况：你没有 SearXNG，也不打算运维一个。这个项目不自带搜索引擎，它只是 SearXNG API 的 MCP 封装，README 的免 API key 表述后面紧跟着一句限定，你仍然需要自己运行或选择一个底层的 SearXNG 实例。把这句话读漏，上手第一步就会卡住。

第二种情况：你需要的是托管服务的检索质量与稳定性。Brave MCP、Exa MCP、Firecrawl MCP 走的是另一条路，由厂商维护索引与接口，你付出费用与查询可见性，换来不用管实例。mcp-searxng 把这份运维责任转移给了你，故障转移配置得再好，也替代不了一个正常运行的实例。

第三种情况：你把它当成匿名搜索方案。README 已经写明不提供匿名性。第四种情况：你依赖公共实例并且需要 JSON 输出。公共实例拒绝 format=json 是常见情形，此时只能退回 HTML 解析，稳定性由别人的页面结构决定。

维护成本与许可

项目采用 MIT 许可，这是最宽松的一档，商用与修改都没有额外约束，README 里也没有出现额外的条款说明。这里只陈述许可标识，具体合规判断需要你按自己的使用方式处理。

维护成本分成两块。属于这个项目的部分相对轻：一个 Node.js 进程，通过 npx -y mcp-searxng 拉起，升级就是换版本号，客户端配置里改 args 即可。属于你的部分更重：SearXNG 实例本身要更新、要防滥用、要处理被上游引擎限流；如果启用了浏览器求解器，还要维护 FlareSolverr 或 Byparr 的容器。README 提到部署配置文档里有实测的 MCP 进程 CPU 与内存起点，但那是进程本身的数字，不含 SearXNG 与浏览器求解器。

版本节奏上，仓库近期发布了 v2.2.0、v2.1.0、v2.0.0，其中 v2.0.0 是一次主版本跳跃，跨版本升级前值得先读 release notes 确认配置项与工具面是否变动。

编辑结论

适合已经或愿意自建 SearXNG 的团队与个人：你不需要向搜索厂商申请 API key，查询落在自己控制的实例上，并且能通过 SEARXNG_URL 配置多个可互换副本做故障转移。不适合只想填一个 API key 就开始用的人，也不适合把隐私等同于匿名的场景，README 明确写了 SearXNG 与本集成本身不提供匿名性，公共实例仍会收到并可能记录查询。上手前先确认三件事：你的 SearXNG 实例是否允许 format=json，否则要打开 HTML fallback；是否需要 web_url_read 抓取外部页面，如果需要就先把 SSRF 与浏览器求解器的边界想清楚；部署形态是本地 stdio 还是 Streamable HTTP，后者要自己配硬化与限流。

官方来源

1. ihor-sokoliuk/mcp-searxng on GitHub
2. License: MIT
3. Project website
4. README
5. Releases