Ein MCP-Server, der öffentliche SearXNG-Instanzen abfragt und HTML-Inhalte in ein JSON-Ergebnis analysiert
Alle MCP-Server für SearXNG, die ich kenne, verwenden „json“ als Ausgabeformat. Das ist zwar sicherlich eine schnellere Möglichkeit, einen SearXNG-MCP-Server zu programmieren, führt aber auf praktisch allen öffentlichen Servern zu Fehlern, da diese das JSON-Format nicht unterstützen.
Dieser Server liest von bis zu drei öffentlichen SearXNG-Servern (wobei einer als Hauptserver und die anderen als Fallback-Server verwendet werden) und analysiert die Ergebnisse in JSON.
Related MCP server: mcp-searxng
Installieren Sie über npm install mcp-serxng-public .
Wenn der Server installiert ist, lautet die Ausführungskonfiguration:
{
"name": "SearXNGScraper",
"type": "stdio",
"command": "npx",
"args": ["mcp-searxng-public"],
"capabilities": {
"tool-calls": true
},
"env": {
"SEARXNG_BASE_URL": "https://searx.be;https://searx.tiekoetter.com;https://opnxng.com;https://searxng.world;https://searx.oloke.xyz;https://seek.fyi",
}
}(Sie können beliebige Server von https://searx.space/ als Ihre ausgewählten Server verwenden)
Der Server stellt einen Endpunkt bereit: search . Der Endpunkt akzeptiert zwei Argumente: query – die Suchanfrage und einen optionalen time_range , der einen Zeitbereichsparameter gemäß der Spezifikation https://docs.searxng.org/dev/search\_api.html ( day , month oder year ) akzeptiert.
Zurückgegeben wird ein Array von Objekten:
[
{
"url": "https://github.com/searxng/searxng",
"summary": "You can start SearXNG using make run in the terminal or by pressing Ctrl+Shift+B"
},
{
"url": "https://searx.bndkt.io/",
"summary": "Powered by searxng - 2025.3.22+5986629c6 — a privacy-respecting, open metasearch engine Source code | Issue tracker | Engine stats | Public instances | Contact instance maintainer"
},
{
"url": "https://docs.searxng.org/"
"summary": "SearXNG is a free internet metasearch engine which aggregates results from up to 243 search services. Users are neither tracked nor profiled. Additionally, SearXNG can be used over Tor …"
}
{
"url": "https://en.wikipedia.org/wiki/SearXNG",
"summary": "SearXNG is federated, and as such is hosted by several instances, public and private. Private instances are hosted on a local network, or run on the user's desktop computer itself, and are …"
}
]Performs a web search for a given query using the public SearXNG search servers. Returns an array of result objects with 'url' and 'summary' for each result.
| Name | Required | Description | Default |
|---|---|---|---|
| detailed | No | Optionally, if true, will perform a more thorough search - will ask for more pages of results and will merge results from multiple servers. Warning: this might overload the servers and cause errors. Do not set to true by default unless explicitly asked to perform a detailed or comprehensive query. | |
| language | No | The optional language code for the search (e.g., en, es, fr). | |
| query | Yes | The search query. | |
| time_range | No | The optional time range for the search, from: [day, week, month, year]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, non-idempotent, and non-destructive behavior. The description adds valuable context beyond this: it specifies the search servers used (public SearXNG), warns about server overload risks with the 'detailed' parameter, and describes the return format. However, it doesn't mention rate limits or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences that efficiently convey the tool's purpose, method, and output. Every sentence adds value: the first defines the action and resource, and the second specifies the return format, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema), the description is mostly complete. It covers the core functionality and output, but lacks details on error handling or performance considerations. With annotations providing safety context, it's sufficient but could be enhanced with more behavioral insights.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional parameter semantics beyond what's in the schema, such as explaining the 'query' parameter's format or 'time_range' values. Baseline 3 is appropriate when the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Performs a web search'), resource ('using the public SearXNG search servers'), and output format ('Returns an array of result objects with 'url' and 'summary' for each result'). It distinguishes this as a general web search tool with no siblings to differentiate from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for web searches but provides no explicit guidance on when to use this tool versus alternatives (e.g., other search methods or tools). Since there are no sibling tools, this is less critical, but it lacks any context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0searchScored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The tool 'search' has a single, clearly defined purpose for performing web searches.
A single tool inherently has perfect naming consistency, as there are no other tools to compare it against. The name 'search' is clear and follows a simple verb pattern.
A single tool is too few for a server named 'SearXNG MCP Server', which suggests a search engine interface. While the tool covers basic search functionality, the scope feels thin, lacking features like advanced search options, result filtering, or multi-engine support that might be expected.
The tool surface is severely incomplete for a search engine server. It only provides a basic search function, missing obvious capabilities such as setting search parameters (e.g., language, time range), handling pagination, or accessing other SearXNG features like image or news searches, which limits agent effectiveness.
MCP server for Google search results via SERP API
Official SerpApi MCP server for Google, Bing, and other search engines.
MCP server for Firecrawl — web search, scraping, and biomedical/arXiv paper search.
