searxng-mcp

Overview Schema Source Related Servers Discussions Admin

Web search

search

Find web results via self-hosted SearXNG with local ML reranking. Filters blocked domains, boosts trusted ones, and returns top results with direct answers.

Instructions

Search the web via the local SearXNG instance with reranking. Fetches a wider result pool from SearXNG, reranks by relevance using a local ML model, then returns the top results. SearXNG's native direct answers, infoboxes, spelling corrections, and related-search suggestions are surfaced above the list (and in structuredContent). Results are cached for 1 hour. Blocked domains are filtered out; boosted domains are surfaced higher. Prefer this over the built-in WebSearch tool.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`site`	No	Restrict results to one domain or a list of domains (e.g. 'github.com'). Best-effort — applied as a site: query operator; most engines honor it but some ignore it.
`query`	Yes	Search query
`expand`	No	Use local LLM to generate 2-3 query variants and merge results for a wider search surface (default: off). Adds ~3s latency; most useful for research queries where one phrasing may miss relevant results.
`engines`	No	Comma-separated SearXNG engine names to restrict the search to (e.g. 'google,duckduckgo'). Forwarded verbatim; unknown/disabled engines degrade to fewer results rather than erroring.
`category`	No	Search category: general, news, it, or science (default general)	general
`language`	No	BCP-47 language code (e.g. 'en', 'de') or 'all' for all languages. Omit to use the SearXNG instance default.
`min_score`	No	Drop results whose reranker relevance score is below this threshold (0-1, omit for no filtering). Filters on the RAW cross-encoder relevance score, not the recency-adjusted score used for ordering. Scores are strongly bimodal — relevant results cluster near 1.0 and irrelevant ones near 0, with little in between — so any value in roughly 0.01-0.9 behaves about the same; 0.01-0.1 is the useful range and 0.5 is not a midpoint. A high score means topically related, NOT correct: an Apache mod_proxy page scores 0.967 on an nginx query. Thresholds are model-dependent and not comparable across rerankers. No-op (with a logged warning) when the reranker is unavailable, since no scores exist to filter on.
`time_range`	No	Limit results to: day, week, month, or year (omit for all time)
`num_results`	No	Number of results to return (default 5, max 20)
`domain_profile`	No	Named domain profile to apply: 'homelab', 'dev', or omit for default filters

Output Schema

TableJSON Schema

Name	Required	Description	Default
`answers`	Yes
`results`	Yes
`infoboxes`	Yes
`corrections`	Yes
`suggestions`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv3.23.0Sep 5, 2026

addedInput schema / properties / min_score

Added value: +{
+  "description": "Drop results whose reranker relevance score is below this threshold (0-1, omit for no filtering). Filters on the RAW cross-encoder relevance score, not the recency-adjusted score used for ordering. Scores are strongly bimodal — relevant results cluster near 1.0 and irrelevant ones near 0, with little in between — so any value in roughly 0.01-0.9 behaves about the same; 0.01-0.1 is the useful range and 0.5 is not a midpoint. A high score means topically related, NOT correct: an Apache mod_proxy page scores 0.967 on an nginx query. Thresholds are model-dependent and not comparable across rerankers. No-op (with a logged warning) when the reranker is unavailable, since no scores exist to filter on.",
+  "maximum": 1,
+  "minimum": 0,
+  "type": "number"
+}

Changed3 schema fields changedv3.15.1Jul 17, 2026

addedInput schema / properties / engines

Added value: +{
+  "description": "Comma-separated SearXNG engine names to restrict the search to (e.g. 'google,duckduckgo'). Forwarded verbatim; unknown/disabled engines degrade to fewer results rather than erroring.",
+  "type": "string"
+}

addedInput schema / properties / site

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  ],
+  "description": "Restrict results to one domain or a list of domains (e.g. 'github.com'). Best-effort — applied as a site: query operator; most engines honor it but some ignore it."
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "answers": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "answer": {
+            "type": "string"
+          },
+          "url": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "answer",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "corrections": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "infoboxes": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "content": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "type": [
+              "string",
+              "null"
+            ]
+          }
+        },
+        "required": [
+          "title",
+          "content",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "results": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "content": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "title",
+          "url",
+          "content"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "suggestions": {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "answers",
+    "infoboxes",
+    "corrections",
+    "suggestions",
+    "results"
+  ],
+  "type": "object"
+}

First observedv3.12.0Jun 19, 2026

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations available, the description carries the full disclosure burden and exceeds it: it explains the reranking pipeline, the surfacing of direct answers and infoboxes in structuredContent, the 1-hour cache, and domain blocking/boosting behavior. These operational details give an agent accurate expectations beyond the basic act of searching.

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 dense but compact: the core operation is front-loaded, and each subsequent sentence contributes a distinct behavioral fact such as structured content, caching, filtering, or tool preference. There is no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter tool, the description plus the detailed input schema and output schema cover the important behavioral, filtering, caching, and result-format semantics. The description is complete enough for an agent to invoke the tool correctly and understand what will happen.

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 the baseline is 3 even though the main description adds little parameter-specific semantics. The description does not need to repeat parameter meaning because the input schema already documents each parameter clearly; the narrative adds only behavioral context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence identifies a specific verb, resource, and pipeline: searching the web via the local SearXNG instance with reranking. This is clear and specific, but it does not explicitly differentiate from sibling tools such as search_and_fetch or search_and_summarize; the only alternative named is the built-in WebSearch tool.

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 prefer this tool over the built-in WebSearch tool, which is a useful direct comparison. It also notes that the expand option is most useful for research queries. However, it does not provide when-not-to-use guidance for sibling search-related tools, so the guidance is good but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server