DuckDuckGo Loader

If you've seen this pack's DuckDuckGo Tool node, this is its quieter sibling. Tool nodes exist so an LLM agent can decide at runtime whether and what to search for. This one skips the agent entirely - you type the keywords in on the node itself, the search runs every time the workflow runs, and you get the results back as plain text. No decision-making, no API key, no signup. It's the version for when you already know what you want to search for and just want it baked into the graph.

What it does

keywords is the search query, and it's the one field you're actually filling in. searchType picks between web (regular search results) and image (image search) - a two-way switch rather than separate nodes for each mode. paper_num controls how many results come back; the name reads like it was written with academic-paper searches in mind, but functionally it's just "how many hits to pull," and it works the same whether you're searching for a research topic or a product name. is_enable is this pack's standard bypass toggle - flip it off and the node passes through without hitting the network, useful while you're wiring up the rest of a workflow and don't want to burn requests. One output: text, everything the search returned, concatenated into a single string.

Where it fits

This lives in the pack's knowledge-base category, not its tools category, and that placement is the tell. It's meant to feed a fixed chunk of live web context into a downstream node - most naturally this pack's Word Vector Search / embeddings node, or straight into an LLM's prompt - as a one-shot "go get me current information about X" step at the start of a workflow, rather than something an agent calls repeatedly mid-conversation. If you want the LLM itself deciding when to search and what for, that's what DuckDuckGo Tool is for; this node is for when the search is a fixed part of the pipeline every time it runs.

Why no API key

DuckDuckGo doesn't publish an official search API the way Google (which this pack also supports, via google_api_key and cse_id in config.ini) and Bing do. Tools built around "DuckDuckGo search" generally work by querying DuckDuckGo's own search-facing endpoints directly instead of a documented, versioned API. That's exactly why there's no key field on this node - and also why it's worth not building anything you need to run unattended for months on top of it without a fallback plan.

Installing it

Standard pack install, nothing extra for this node specifically:

• ComfyUI Manager: search "comfyui_LLM_party", install, restart.
• Manual: cd ComfyUI/custom_nodes && git clone https://github.com/heshengtao/comfyui_LLM_party, then run pip install -r requirements.txt from inside the pack folder using ComfyUI's own Python (on a portable/embedded install that's python_embeded\python.exe -m pip install -r requirements.txt), then restart.

Common issues

Empty or thin results. Since this leans on an unofficial interface rather than a stable API, expect occasional empty returns or rate-limiting under heavy repeated use - that's more likely the explanation than a problem with your keywords or paper_num setting, especially if it was working a minute ago and now isn't.

text output is messier than you expected. This node returns raw search-result text, not a curated summary - if you're feeding it straight into a prompt, expect to do some cleanup or truncation, or route it through a chunking/embedding step (this pack's Word Vector Search node) before it hits your LLM, rather than dumping it in raw.

Need something more dependable for production. If reliability matters more than avoiding a signup step, this pack also wires up Google and Bing search via config.ini (google_api_key/cse_id, or bing_api_key) - worth the extra setup if this node's results start feeling flaky under real use.