SearxNG input/output format support

[drzraf]

Here and there are popping up more and more agents/MCP/... supporting SearxNG as a search backend (often falling back on a online search/research engine like Qwant, DDG etc...).

I wonder what keeps Hister from being plug'n'play to be used in place of a true SearxNG instance.
AFAICT it's all about a specific URL endpoint supporting q, format=json, pageno, engines, language query-string parameters and returning json like {"result":{"title" + "url" + "content"}}

Such a SearxNG formalized I/O compatibility layer, written once inside Hister would open to door to use it with many existing libraries/tools without patching each and every one of them.

[asciimoo]

I'm very well aware of the searx search format, since I wrote it back in the days. =]

The results are available in JSON format in Hister as well, but there are a few incompatibilities with the original Searx API:

• Paging is done by using page cursors, which is more versatile and resilient than numbered pages when new items arrive while searching
• Filtering by various dimensions is done in the query string in Hister
• engines makes no sense

Non of these are blockers, but adding the compatibility would result in less accurate paging and increased filtering complexity. Hister has way more flexible filtering than searx, providing an HTTP parameter for each would require significant amount of work.

Could you list existing libs/tools that could be used this way?

[asciimoo]

These are mostly MCP servers and AI integrations, which we already have one built-in: https://hister.org/docs/mcp . I'm not entirely against this change, but currently I'm not convinced that the required work/code would justify the gains.

[drzraf]

Can't it be a self-contained/not invasive parallel endpoint wrapper, just transforming query-string into JSON and passing it to the usual function, then transforming the output (with, some limited modifications to handle pagination)?

The main effects are reducing the overall stack complexity/burden and since LLM integrations are already full of brand-new/vibe-coded components stacks, it's not bad to just being compatible with an existing set of semantics.
It doesn't mean users/MCP won't make the best out of Hister specifically, but rather that it may ease integrating Hister into existing setups.
(the way its done for browsers' search-bar across all search engines)

[asciimoo]

Sorry, but I'm struggling to see what is the added benefit of using the linked projects instead of the built-in MCP endpoint. Could you explain the advantages?

[drzraf]

relying on one MCP instead of two. Or because one of these has convincing features but only missing Hister instead of SearxNG.
(It's basically not bundling Hister and a specific MCP, but Hister as a versatile services usable with any MCP)
[and not enabling multiple & very similar MCPs]

[asciimoo]

I personally don't mind having +1 MCP server if in exchange I can have more detailed filtering options, proper pagination, and access to other features like the history endpoint.

Keep this discussion open and check if others are interested in this workflow.