Skip to main content
Glama
FivePebblesGPT

SearXNG MCP Server

by FivePebblesGPT
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

searxng_web_search

Read-only

Search the web through a SearXNG instance and return paginated results with titles, URLs, and snippets, with filters for engines, language, time range, and safe search.

Instructions

Searches the web using SearXNG and returns a list of results, each with a title, URL, and content snippet. CRITICAL: The required parameter name is exactly query (not prompt, q, or any other name). Calls an external SearXNG instance; availability depends on the SEARXNG_URL configuration. Use pageno to paginate results; combine time_range and language to narrow scope. When engines and time_range are both provided, every selected engine must explicitly advertise time-range support via SearXNG /config; otherwise the request is rejected before search. To read the full text of a result URL, follow up with web_url_read.

Input Schema

NameRequiredDescriptionDefault
pagesNoFetch 1 to 5 consecutive pages concurrently starting at pageno; merge and deduplicate before applying the result limit. Failed pages are reported in failedPages in JSON output.
queryYesThe search query string. This is the required parameter name — use exactly `query`, not `prompt` or `q`.
pagenoNoSearch page number (starts at 1)
enginesNoComma-separated SearXNG engine names to query (e.g. 'google,bing,ddg'). Live /config capabilities are aggregated across reachable instances; prefer searxng_instance_info engines.common.enabled for consistent multi-instance results. Values in engines.available.enabled are best-effort and may only be honored by some instances. Known values are normalized case-insensitively; unknown values are forwarded trimmed so SearXNG can ignore or honor them. If /config is unavailable, values are forwarded as-is with a warning. If omitted, each instance uses its server-side default.
languageNoLanguage code for search results (e.g., 'en', 'fr', 'de'). Default is instance-dependent.all
min_scoreNoMinimum relevance score threshold from 0.0 to 1.0. Results below this score are filtered out.
categoriesNoComma-separated SearXNG categories. Live /config capabilities are aggregated across reachable instances; prefer searxng_instance_info categories.common for consistent multi-instance results. Values in categories.available are best-effort and may only be honored by some instances. Known values are normalized case-insensitively; unknown values are forwarded trimmed so SearXNG can ignore or honor them. If /config is unavailable, values are forwarded as-is with a warning. If omitted, each instance uses its server-side default.
safesearchNoSafe search filter level (0: None, 1: Moderate, 2: Strict)
time_rangeNoTime range of search (day, week, month, year). With explicit engines, all selected engines must confirm time_range_support=true via /config.
num_resultsNoMaximum number of results to return (1-20). Operator cap SEARXNG_MAX_RESULTS applies as a ceiling.
result_detailNoResult detail: full preserves SearXNG metadata and search signals; compact returns only title, URL, and content-snippet fields for each result (JSON keys: title, url, content). If omitted, full is used.
response_formatNoResponse format: formatted text for agents or raw JSON for programmatic clients. If omitted, SEARXNG_DEFAULT_RESPONSE_FORMAT applies; if unset or invalid, text is used. An explicit response_format always takes precedence.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.9.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds substantial context beyond them: an external SearXNG instance is called, availability depends on SEARXNG_URL, and requests combining `engines` with `time_range` are rejected pre-search unless every engine advertises time-range support in /config. These failure modes are exactly what an agent needs to avoid dead calls.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Roughly six sentences, front-loaded with the purpose and return shape before constraints. The all-caps CRITICAL warning is slightly heavy but justified by the common mistake of sending `prompt` or `q`.

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 12-parameter tool with no output schema, the description covers the return shape, pagination, scope narrowing, engine/time-range compatibility, and the follow-up path to full text. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by emphasizing the exact `query` parameter name, the interaction constraint between `engines` and `time_range`, and by telling the agent where to get full text. Most other parameter detail is already in the schema and not repeated at length.

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?

States a specific verb and resource ('Searches the web using SearXNG') plus the return shape (title, URL, content snippet). It also distinguishes itself from the sibling web_url_read by naming it as the follow-up for full-text reading.

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?

Gives concrete usage guidance: use `pageno` to paginate, combine `time_range` and `language` to narrow scope, and follow up with `web_url_read` for full text. It does not mention when to prefer the sibling searxng_search_suggestions or searxng_instance_info, so the routing is clear 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

Other Tools