Key takeaways
- Default pick: ihor-sokoliuk/mcp-searxng, a standalone Node.js server your assistant connects to.
- It's a start, not a verdict. Choose differently when you need scraping or lower token cost.
- The stateless MCP spec ships July 28, 2026 and changes the transport you should wire in.
What a searxng MCP server actually is
SearXNG is a metasearch engine. It queries other engines and hands you the combined results, all on infrastructure you control. It is not an MCP server, and it does not speak the Model Context Protocol on its own.
An MCP (Model Context Protocol) is the wiring between a model and a tool. It's a small, standard contract. A server exposes tools, and a client, your assistant or agent, calls them during its agent loop. A searxng MCP server sits in the middle. In the canonical case it is a separate Node.js process that connects your assistant to a running SearXNG instance for web search, shown in ihor-sokoliuk/mcp-searxng.
So, who owns these servers? No one, and everyone. There is no official searxng MCP server blessed by the SearXNG project. What you find are independent community repos, each maintained by a different developer with different priorities. That is the honest answer to "who owns MCP servers." The protocol is open, and anyone can publish one. Which is exactly why the choice lands on you.
The searxng MCP servers you'll actually find
Search "searxng mcp" on GitHub and you hit a wall of near-identical repos. Four are worth telling apart.
The first is ihor-sokoliuk/mcp-searxng, the one most people land on. It's standalone Node.js, and it connects an assistant to one SearXNG instance for web search. It is the closest thing to a default.
The PyPI server installs with pip install searxng-mcp. It presents itself as a production-grade server built to interface directly with SearXNG for agentic use, and it leans on consolidated, action-routed tools to keep token overhead down. If your stack is Python, this is the natural reach.
Then there's secretiveshell/mcp-searxng. It connects agentic systems to SearXNG and exposes a straightforward web-search tool. Smaller surface, fewer moving parts.
The enhanced variant, overtlids/mcp-searxng-enhanced, is the one that does more than search. It adds category-aware search, web scraping, and a date/time tool. It runs through Docker, on the host network and pointed at your SearXNG API base URL, or natively on Python. If plain search isn't enough, this is where you look.
One split cuts across all of them: public instance versus self-hosted. You can point most of these servers at a public SearXNG instance and be querying in minutes, or at your own instance for privacy and rate control. The repos are public. The instance behind them does not have to be. For anything an agent hammers in a loop, run your own.
Which searxng mcp server to wire in
| Server | Runtime | Install | Standout | Best when |
|---|---|---|---|---|
| ihor-sokoliuk/mcp-searxng | Node.js | clone or npx | Standalone default | You want the well-trodden path |
| searxng-mcp (PyPI) | Python | pip install searxng-mcp | Action-routed tools, lower token overhead | Your stack is Python and cost matters |
| secretiveshell/mcp-searxng | Python | clone | Minimal web-search surface | You want the fewest moving parts |
| overtlids/mcp-searxng-enhanced | Docker or Python | Docker | Scraping, category-aware search, date/time | You need more than plain search |
Start with ihor-sokoliuk/mcp-searxng. It's the standalone Node.js server most agents already assume, and it does the one job cleanly.
Now, where that pick is wrong. If you need to scrape pages or route searches by category, the enhanced variant does what the default cannot. If token budget is your constraint and you live in Python, the PyPI server's consolidated tools win on overhead. The default is a safe first move. It is not the answer for every case.
Docker, SSE, and what the 2026-07-28 stateless spec changes
Most READMEs still show you a session-based transport. That means server-sent events (SSE), or an HTTP setup that keeps a session alive between calls. Wire that in today and you are baking in an assumption that is about to expire.
On May 21, 2026, the MCP maintainers published the release candidate for MCP 2026-07-28 and called it the largest revision of the protocol since launch. The final spec ships July 28, 2026. It removes sessions, drops the initialization handshake, deprecates three core features, and rewrites authorization.
The headline is a stateless core. The protocol now scales on ordinary HTTP, without the sticky sessions, shared session store, and gateway deep-packet inspection that horizontally-scaled remote servers used to need. The handshake is gone, the session header is gone, and any server instance can serve any request. The sticky-routing-and-shared-store dance is no longer part of the protocol.
For a searxng MCP server, that resets the SSE-versus-streamable-HTTP question. SSE was the pattern you reached for when a session had to stay pinned to one instance. Streamable HTTP over a stateless core does not need that pin. Treat this as a transition, not a finished state. The final spec is days out as of this writing, and servers will lag it. You may still be wiring a session-based transport today. Do it knowing it is the old default, and that stateless is where this is going.
Wire it into Open WebUI and other clients
Connecting one of these servers to a client like Open WebUI is the step that turns a repo into a working tool. The shape is the same across clients. Run the MCP server as its own process, then register it in the client as an external tool pointed at that process. Prefer a native streamable-HTTP MCP connection over an OpenAPI shim. The shim adds a translation layer you don't need when the client already speaks MCP.
The exact menu path, connection-type label, and any secret-key requirement move between versions. So check the current Open WebUI docs for your release, rather than trusting a screenshot from six months ago. The principle holds even as the labels drift. Point the client at the running server, pick the MCP-native connection, and confirm the tools appear before you rely on them.
Test it before you trust it
Never let an agent be the first thing to call a new server. Before it goes anywhere near a loop, test it in isolation.
The tool for this is MCP Inspector. Launch it with npx @modelcontextprotocol/inspector@latest while your server runs in a separate terminal. It gives you a graphical interface that lists the server's tools, handles authentication, and lets you run each tool with specific inputs. No natural-language prompting involved. You call the search tool directly, see the raw result, and know the wiring works.
That is how you test a remote MCP server without guessing. Drive the tools by hand first. What Inspector cannot show you is how the server behaves once a real agent is hammering it. That is the next problem.
After you ship: the failure modes local testing misses
A searxng MCP server that passes every Inspector check can still fall over in production. Local testing exercises one caller making one clean request at a time. An agent loop does not behave like that. It fans out, retries, and calls the search tool far more often than a human ever would.
The transport shift is where this bites. A deployment built on the old session-based pattern assumed sticky routing. A given session stayed pinned to the instance that opened it, backed by a shared store. Scale that horizontally and every layer has to cooperate to keep the session coherent: the load balancer, the store, the gateway. Under a stateless core, any instance answers any request, and that whole coordination problem disappears.
The failure mode is the gap between the two. A server you deployed on sticky sessions behaves differently under load than a stateless one. If you wired the old pattern from a pre-spec README, your scaling assumptions are already stale. This is reasoned from the spec, not a war story from a specific deployment. But the direction is not in doubt. Test under a request pattern that looks like your agent's, not like your hand.
A note on what you'll find if you go looking for real-world reports. Public discussion of which searxng MCP variant developers actually run is thin, and forum threads rarely say how a server held up at scale. Treat them as leads to test, not answers to copy.
The keeper: choose by the layer that decides survival
Here is the rule worth keeping. Choosing a searxng MCP server is two decisions, not one.
The first is the variant. That decides what you can build fast: plain search, scraping, category routing, or a Python-native install. Pick it for capability, and the decision table above gets you there in a minute.
The second is the operational layer. Your transport, and how the thing behaves when an agent is looping against it at scale. That is what rifty calls the agent harness, and it decides whether the server survives production. The stateless 2026-07-28 spec is exactly why this layer now demands attention. The transport you pick today is being rewritten under you.
For a throwaway prototype, ignore all of this and grab the default. For anything load-bearing, weigh the second axis harder than the first. The server you pick is easy to change later. The operational assumptions you bake in are the ones that hurt.
If you want the longer argument for designing agents that hold together under load, that's the throughline of rifty's writing on building agentic AI systems. Wiring a different tool into the same agent? The sibling guides, including Blender MCP, take the same which-server-to-run lens.