Skip to main content
Glama
nkapila6

mcp-local-rag

by nkapila6
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Deep research

deep_research
Read-only

Run multi-term, multi-engine web research: search each query across chosen backends, re-rank results locally, remove duplicates, and fetch top pages as text for synthesis.

Instructions

Research a topic across several search terms and engines. Each term is searched on each backend, results are re-ranked locally by relevance, duplicates are removed, and the best pages are fetched as text.

Backends: auto, brave, duckduckgo, google, grokipedia, mojeek, startpage, wikipedia, yahoo.

  • "auto" (default): ddgs metasearch over several engines, skipping blocked ones. Most reliable.

  • "brave": fast and usually available.

  • "wikipedia": exact article lookups, best with title-like terms.

  • "google", "startpage", "yahoo", "mojeek": often blocked. Empty engines are reported as warnings, and if every chosen engine is empty the terms are retried with "auto".

Input Schema

NameRequiredDescriptionDefault
backendsNoBackends to use. Defaults to ["auto"]. Unknown names are skipped with a warning.
include_urlsNoWhether to include each page's source URL.
search_termsYes2-5 specific, related search queries covering different angles. Example: ["postgres query planner", "postgres index types", "EXPLAIN ANALYZE tutorial"]
top_k_per_termNoNumber of top-ranked results to keep per search term per backend.
num_results_per_termNoNumber of results to rank per search term per backend.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.1.1
    • changedInput schema / properties / backends / description
      Previous value: -"List of search backends to use. Defaults to [\"duckduckgo\", \"google\"].\n                 Can include: bing, brave, duckduckgo, google, grokipedia, \n                 mojeek, yandex, yahoo, wikipedia. If None, uses default."New value: +"Backends to use. Defaults to [\"auto\"]. Unknown names are skipped with a warning."
    • changedInput schema / properties / include_urls / description
      Previous value: -"Whether to include URLs in the results."New value: +"Whether to include each page's source URL."
    • changedInput schema / properties / num_results_per_term / description
      Previous value: -"Number of results to fetch per search term per backend."New value: +"Number of results to rank per search term per backend."
    • changedInput schema / properties / search_terms / description
      Previous value: -"List of search terms to research. Provide multiple \n                      related search queries for comprehensive coverage.\n                      Example: [\"machine learning fundamentals\", \"neural networks\", \"deep learning best practices\"]"New value: +"2-5 specific, related search queries covering different angles.\n                      Example: [\"postgres query planner\", \"postgres index types\", \"EXPLAIN ANALYZE tutorial\"]"
    • changedInput schema / properties / top_k_per_term / description
      Previous value: -"Number of top scored results to keep per search term per backend."New value: +"Number of top-ranked results to keep per search term per backend."
  2. Changed5 schema fields changedv1.0.4
    • addedInput schema / properties / backends / description
      Added value: +"List of search backends to use. Defaults to [\"duckduckgo\", \"google\"].\n                 Can include: bing, brave, duckduckgo, google, grokipedia, \n                 mojeek, yandex, yahoo, wikipedia. If None, uses default."
    • addedInput schema / properties / include_urls / description
      Added value: +"Whether to include URLs in the results."
    • addedInput schema / properties / num_results_per_term / description
      Added value: +"Number of results to fetch per search term per backend."
    • addedInput schema / properties / search_terms / description
      Added value: +"List of search terms to research. Provide multiple \n                      related search queries for comprehensive coverage.\n                      Example: [\"machine learning fundamentals\", \"neural networks\", \"deep learning best practices\"]"
    • addedInput schema / properties / top_k_per_term / description
      Added value: +"Number of top scored results to keep per search term per backend."
  3. Addedv1.0.1

TDQS

A4/5.0
Behavior4/5

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

With readOnlyHint and openWorldHint already declaring the safety profile, the description adds real value: it discloses the internal pipeline (search, local re-rank, dedupe, fetch page text) and the failure semantics (empty engines reported as warnings, retry with 'auto' if all chosen engines are empty). It stops short of disclosing cost/latency characteristics, which matters for a tool that fetches pages.

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?

Front-loaded with a pipeline summary, then a scannable backend bullet list — well structured and mostly waste-free. The bullet list is slightly long but each entry carries decision-relevant information about reliability.

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?

An output schema exists so return format need not be covered, and annotations cover the read-only/open-world profile; the description fills in pipeline and fallback behavior. The remaining gap is sibling disambiguation, which is the one thing an agent must know before choosing among the five search tools.

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, but the description genuinely enriches the 'backends' parameter by enumerating valid values and characterizing each one's reliability and best use, which the schema's one-line description does not do. The interaction between num_results_per_term and top_k_per_term (rank N, keep K) is implied but not explicitly explained.

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 states a specific verb and resource ('Research a topic across several search terms and engines') and the following sentence spells out the pipeline: multi-term search, local re-ranking, deduplication, page fetching. It does not explicitly state how it differs from siblings like deep_research_google or deep_research_ddgs, though the backend list implies this tool is the superset that can target either.

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?

Backend selection guidance is concrete and actionable: 'auto' is flagged as the most reliable default, 'brave' as fast, 'wikipedia' for title-like lookups, and google/startpage/yahoo/mojeek as often blocked with an auto-retry fallback. What is missing is guidance on when to pick this tool over the sibling search tools (search, rag_search_ddgs, deep_research_google), which an agent must infer.

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