Skip to main content
Glama
nkapila6

mcp-local-rag

by nkapila6
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Deep research (ddgs auto)

deep_research_ddgs
Read-only

Aggregate multi-engine web research: submit related queries, skip blocked engines, re-rank and de-duplicate results, then fetch selected pages as text for analysis.

Instructions

Deep research using ddgs "auto" metasearch, which queries several engines per term and skips blocked ones. Results are re-ranked locally, de-duplicated and the best pages fetched as text. Same as deep_research with its default backend.

Input Schema

NameRequiredDescriptionDefault
include_urlsNoWhether to include each page's source URL.
search_termsYes2-5 specific, related search queries.
top_k_per_termNoNumber of top-ranked results to keep per search term.
num_results_per_termNoNumber of results to rank per search term.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.1.1
    • 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."New value: +"Number of results to rank per search term."
    • changedInput schema / properties / search_terms / description
      Previous value: -"List of search terms to research. The LLM should provide \n                      multiple related search queries for comprehensive coverage."New value: +"2-5 specific, related search queries."
    • changedInput schema / properties / top_k_per_term / description
      Previous value: -"Number of top scored results to keep per search term."New value: +"Number of top-ranked results to keep per search term."
  2. Changed4 schema fields changedv1.0.4
    • 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."
    • addedInput schema / properties / search_terms / description
      Added value: +"List of search terms to research. The LLM should provide \n                      multiple related search queries for comprehensive coverage."
    • addedInput schema / properties / top_k_per_term / description
      Added value: +"Number of top scored results to keep per search term."
  3. Addedv1.0.1

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnly and openWorld, but the description adds real pipeline detail beyond them: multi-engine querying, skipping blocked engines, local re-ranking, de-duplication, and fetching of top pages as full text — which signals latency and network cost. It does not mention rate limits, failure modes, or how many pages get fetched.

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?

Three short sentences with the backend mechanism first and the sibling equivalence last; every clause carries information an agent cannot get from the schema. No filler or repetition of annotations.

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 shape need not be explained, and annotations cover the safety profile. The description covers mechanism and scope well; only secondary operational facts such as cost, expected latency, or failure behavior are absent.

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 four parameters (search_terms, top_k_per_term, num_results_per_term, include_urls) are already documented in the schema. The description adds no guidance on how many terms, how terms relate to each other, or how top_k interacts with the ranking stage, so the baseline 3 applies.

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 operation (deep research) plus the exact backend mechanism: ddgs "auto" metasearch querying several engines per term while skipping blocked ones. It also explicitly relates itself to a sibling ("Same as deep_research with its default backend"), so an agent can distinguish it from deep_research without opening schemas.

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 sentence "Same as deep_research with its default backend" gives clear selection context: this is the default/alias variant rather than a distinct capability. It stops short of naming when to prefer deep_research_google or rag_search_ddgs instead, so there are no explicit exclusions.

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