Search Keyword Tool

If Load URL Content or a file-reading node in this pack gets you a big block of text into your workflow, Search Keyword Tool is what turns that block into something an LLM agent can actually query rather than just dump wholesale into its context. Instead of stuffing the whole document into every prompt (expensive, and the model still has to find the relevant bit itself), you index it once and let the agent search it as a tool call, pulling back only the chunks that actually matter for a given question.

How it works

file_content is the text to index - a whole document's worth, typically piped in from another node rather than typed by hand. Like this pack's Wikipedia Tool, retrieval isn't done against the raw text directly; it's chunked first. chunk_size (default 200) and chunk_overlap (default 50) control that split the same way they do on the Wikipedia node - smaller chunks give more precise matches at the cost of context, more overlap protects against a relevant sentence getting cut in half at a chunk boundary. k (default 5) sets how many top-matching chunks come back per query - raise it if the agent seems to be missing relevant context, lower it if you're trying to keep the tool's responses tight and fast.

One thing worth flagging explicitly: is_enable on this node is not a boolean the way it is on almost every other node in this pack - it's an enum with the string values "enable" and "disable". If you're used to wiring a BOOLEAN toggle into is_enable fields elsewhere in this pack (which is the norm here), this node breaks that pattern and expects the string value instead. Small inconsistency, but exactly the kind of thing that produces a confusing type-mismatch error if you're copy-pasting a toggle setup from another node in the same graph.

Output is a single tool string, wired into an LLM/agent node's tool list - same pattern as every other tool node in this pack.

Where it fits

This is the pack's lightweight answer to "build a knowledge base out of a document without standing up a real vector database." Feed it a document (from a URL fetch, a loaded file, wherever), and the agent gets keyword-searchable access to it as one of its available tools, deciding for itself when a user's question calls for checking the document versus answering from what it already knows. For anything beyond a single document or two, you'd probably want this pack's dedicated embedding-backed knowledge-base path instead - this node is closer to "quick lookup tool for one chunk of text" than a full document-management system.

Installing it

Standard pack install, nothing extra for this node specifically:

• ComfyUI Manager: search "comfyui_LLM_party", install, restart ComfyUI.
• Manual: cd ComfyUI/custom_nodes && git clone https://github.com/heshengtao/comfyui_LLM_party, then pip install -r requirements.txt inside your ComfyUI Python environment, restart.

Common issues

The is_enable string-vs-boolean mismatch above is the single most likely "why doesn't this work" moment for this specific node - if a connection error mentions a type mismatch on is_enable, that's almost certainly it, and the fix is wiring in the enum string rather than a BOOLEAN toggle node.

Beyond that, the same chunking caveats as any RAG-style tool apply: if k is too low, the agent may not get enough matching chunks to actually answer a question that spans more than one part of the source document; if chunk_size is too small relative to how the source content is structured, you risk fragmenting ideas across chunks in a way that hurts retrieval quality. Start from the defaults, and only tune them once you've actually seen a real query come back with too little (or too much irrelevant) context.