A
licenseB
qualityC
maintenanceProvides web search capabilities using SearxNG, allowing AI assistants like Claude to search the web with a privacy-respecting metasearch engine.
1
11
MIT
searxlens-mcp
by RyhemMekni
Provides web search capabilities through a SearXNG instance, including single searches, parallel multi-query searches with merged and deduplicated results, and reading and extracting readable text from URLs.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@searxlens-mcpResearch the effects of remote work on productivity from several angles"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
searxlens-mcp
An MCP server for web search via SearXNG, built for research-style workflows: it can fan a topic out across several related queries and merge the results, not just answer one query at a time.
Inspired by the broader mcp-searxng ecosystem.
Tools
web_search
A single search against SearXNG. Supports count, language, categories,
time_range, pageno, and min_score (drops results below a relevance
threshold, when the instance reports scores). Results are cached in-memory
for SEARXLENS_SEARCH_CACHE_TTL_MS.
multi_search — the differentiator
Takes 2+ related queries, runs them in parallel, and merges the results:
deduplicates by normalized URL (ignores
utm_*tracking params, trailing slashes, and fragments)a URL surfaced by more than one sub-query is ranked above one found by only a single sub-query — cross-query agreement is treated as a stronger signal than any one engine's relevance score
ties are broken by SearXNG's own score, when present
Good for "research this topic from a few angles" prompts, where a single query would miss results that a slightly different phrasing would catch.
read_url
Fetches a URL and extracts its readable text — strips <script>, <nav>,
<footer>, etc., and picks the largest remaining content block (a light
readability heuristic, not a full port of Mozilla Readability). Cached for
SEARXLENS_URL_CACHE_TTL_MS.
Related MCP server: Web Search MCP Server
Configuration
Variable | Default | Description |
|
| One instance, or several separated by |
|
| Default results for |
|
| Hard ceiling on |
|
| Search result cache TTL. |
|
|
|
|
| Max sub-queries per |
|
| Timeout per outbound HTTP request. |
Your SearXNG instance needs JSON output enabled — in settings.yml:
search:
formats:
- html
- jsonInstall & run
npm install
npm run buildMCP client config (e.g. claude_desktop_config.json):
{
"mcpServers": {
"searxlens": {
"command": "node",
"args": ["/absolute/path/to/searxlens-mcp/build/index.js"],
"env": { "SEARXNG_URL": "http://localhost:8080" }
}
}
}Roadmap
Rough priority order for what's next — not committed, just notes for whoever picks this up:
HTTP transport (
MCP_HTTP_PORT), for remote/shared deploymentsInstance capability discovery (
/config) toolHTML fallback when an instance rejects
format=jsonReal test suite (currently just a manual smoke script) + CI
Docker image
Optional: rank fusion in
multi_searchusing reciprocal rank fusion instead of raw hit-count, for more principled merging
License
MIT
Available Tools
3 toolsmulti_searchA
Run several related queries in parallel and merge the results, deduplicated by URL and ranked by how many sub-queries agreed on them. Use this for exploratory research on a topic ('search this from a few angles') rather than a single precise lookup.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | 2+ related search queries. | |
| language | No | ||
| time_range | No | ||
| count_per_query | No | Results fetched per sub-query before merging (default 8). |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden, and it does: it reveals parallel execution, result merging, URL deduplication, and an agreement-based ranking rule. It doesn't mention potential rate limits, failure behavior, or exact output shape, but the core operational behavior is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tightly written sentences with behavior and usage guidance front-loaded. Every clause contributes semantic value, and there is no redundant restating of the tool name or schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex search tool with no output schema and no annotations, the description covers the key conceptual behavior, use case, and ranking logic. It does not explicitly describe what each result contains, but the mention of deduplication by URL and agreement ranking gives an agent enough to anticipate the output and decide whether to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the description repeats the 'related queries' idea but adds little about the actual parameters. The language and time_range parameters are not described in the schema or the description, though their names are reasonably self-explanatory. The count_per_query default is already in the schema, so the description adds minimal parameter-level value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Run several related queries in parallel'), the target resource, and the distinctive behavior of merging, deduplicating by URL, and ranking by sub-query agreement. This clearly differentiates the tool from a ordinary web search and makes its purpose obvious without needing to inspect the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool for exploratory research on a topic, 'search this from a few angles', and contrasts it with a single precise lookup. It gives clear usage context and an exclusion, but it does not name the exact alternative tool (e.g., web_search), making this slightly incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_urlA
Fetch a URL and extract its readable text (boilerplate stripped), for reading an article found via search in more depth.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to fetch. | |
| max_length | No | Max characters to return (default 4000). |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses that the tool fetches a URL and returns boilerplate-stripped readable text, which is good. However, it does not mention potential failure modes, handling of non-HTML content, external network side effects, or any constraints—leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, tightly worded sentence conveys the action, the output format, the key behavioral detail (boilerplate stripping), and the intended use case. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with fully documented parameters and no output schema, the description is largely sufficient: it explains the output (readable text), the processing (boilerplate stripped), and the workflow context. It only lacks explicit alternative routing and edge-case behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Fetch a URL and extract its readable text') and states that it strips boilerplate. This clearly distinguishes it from the sibling search tools, which find content rather than fetch and read a specific URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for reading an article found via search in more depth' gives a clear contextual trigger: use this after search, when a result needs deeper reading. It does not explicitly name the alternatives or state when not to use it, but the intended workflow is inferable from the sibling names and the stated purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
web_searchA
Search the web via SearXNG. Use for a single, well-formed query when you need current information.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Results to return (default 8, max 20). | |
| query | Yes | The search query. | |
| pageno | No | Result page number (default 1). | |
| language | No | Language code, e.g. 'en', 'fr'. | |
| min_score | No | Drop results below this relevance score (0-1). | |
| categories | No | Comma-separated SearXNG categories. | |
| time_range | No |
TDQS
A3.7/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions SearXNG and 'current information' but does not describe result shape, freshness limits, rate limits, error behavior, or any side effects. This is a significant gap for an unannotated network tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence with no wasted words. The action and use-case are front-loaded, and every phrase contributes to selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with a required query and well-documented optional parameters, the description gives enough to begin invocation. However, without annotations or an output schema, it leaves the return format and behavioral expectations largely implicit, so it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 86%, so the schema already explains the parameters well. The description adds only the guidance that the query should be 'single' and 'well-formed,' which is useful but not substantial enough to raise the score above the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Search the web via SearXNG.' The phrase 'single, well-formed query' distinguishes this from the sibling tool multi_search, making its scope clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use for a single, well-formed query when you need current information' gives an explicit use case and selection criterion. It does not explicitly name when not to use read_url or multi_search, but the 'single query' phrasing implies the boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.1.0- First observed
multi_search - First observed
read_url - First observed
web_search
TDQS
A4.1/5.0
Scored across 3 tools
Disambiguation5/5
Each tool has a clear, non-overlapping purpose: web_search for single precise queries, multi_search for exploratory multi-query research, and read_url for fetching page content. The descriptions explicitly contrast the two search tools, leaving no ambiguity.
Naming Consistency4/5
web_search and multi_search follow a consistent [modifier]_search pattern, while read_url uses a verb_noun pattern. The naming is predictable and readable, with only a minor deviation in the third tool's structure.
Tool Count5/5
Three tools is a well-scoped set for a search-and-read server. Each tool serves a distinct need without redundancy, and the count feels appropriately minimal yet complete for the stated purpose.
Completeness4/5
The toolset covers the core workflow of searching (both single and multi-query) and reading results. Minor gaps like advanced search filters or pagination are not included, but these are optional conveniences rather than essential dead ends for basic research.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
LLM-ready web search + instant answers + URL-to-clean-text fetch for agents and RAG.
Web search, fetch, extract, and research for AI agents. Markdown output + AI-synthesized answers.
Search the web and extract clean, readable text from webpages. Process multiple URLs at once to sp…
Related MCP Servers
- FlicenseNot gradedqualityCmaintenanceEnables web search across multiple search engines (DuckDuckGo, Bing, Startpage) with parallel execution and result deduplication. Also provides web page content extraction capabilities.2-
- AlicenseAqualityDmaintenanceEnables AI assistants to perform web searches and read URL content via a SearXNG instance.213 npmMIT
- AlicenseAqualityDmaintenanceEnables private web search and webpage content extraction using a local SearxNG instance, prioritizing user privacy and autonomy.22MIT