UltraSearch MCP

Web search

search

Reranks web results locally by relevance and returns top matches with direct answers and related suggestions. Use for research queries needing precise, context-aware results.

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.
`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
`researchRoute`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 9, 2026

TDQS

A4/5.0

Behavior5/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, and it delivers: it discloses the SearXNG+ML reranking pipeline, 1-hour result caching, blocked-domain filtering and boosted-domain surfacing, and the separate surfacing of direct answers/infoboxes/spelling corrections in structuredContent. It also notes the latency trade-off of expand. This is substantial behavioral disclosure beyond the schema.

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 a compact paragraph with no filler. Each sentence earns its place: core search behavior, reranking approach, enriched result elements, caching, domain policies, and routing preference. The information is front-loaded with the main purpose first.

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 tool with 9 parameters and an output schema, the description covers the important non-schema behaviors: caching, domain filtering, result reranking, and structuredContent extras. The only notable gap is the lack of explicit guidance about when to use this tool instead of the search_and_fetch or search_and_summarize siblings, which was already captured under usage guidelines.

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 all nine parameters are already documented in the input schema. The tool description does not add extra parameter-level meaning beyond what the schema provides, so the baseline score of 3 applies.

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 description states a clear verb and resource: 'Search the web via the local SearXNG instance with reranking' and explains the result pipeline. It distinguishes itself behaviorally from sibling search_and_fetch and search_and_summarize by focusing only on search results, but it does not explicitly name or contrast those siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives one explicit routing preference: 'Prefer this over the built-in WebSearch tool.' However, this is not a sibling tool, and there is no guidance for choosing between search, search_and_fetch, search_and_summarize, or fetch_url. Usage context is implied by the tool's behavior rather than stated.

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

Install Server