☁️SQL tool

If you've wired up an agent in LLM Party, you've probably noticed a family of nodes that don't produce a visible result themselves - they output a plain STRING called tool. That's not a bug in the UI; it's the pack's tool-calling pattern. Each of these nodes packages up a capability, not a value, and you feed the packaged capability into tool_combine (or tool_combine_plus), which feeds into your LLM/agent node's tool input. The model then decides at runtime, mid-conversation, whether it actually needs to use it. sql_tool is the one that gives your agent the ability to query a real database.

This is the difference between "the agent knows some facts" and "the agent can go look something up." Instead of stuffing your entire database into a prompt (which doesn't scale and goes stale instantly), you hand the model a tool it can invoke with a natural-language ask, and it gets back real, current data from your own database.

Inputs and outputs that matter

• db_connection_string - the DSN for the database this tool can query. The placeholder (postgresql://user:password@host:port/dbname) tells you Postgres is the intended shape.
• query_str - a query field on the node itself; likely a default/seed query or scoping hint rather than something you fill in for every call, since the whole point of a tool node is that the agent supplies the actual ask at runtime.
• model_name, base_url, api_key (optional, default gpt-4o-mini / https://api.openai.com/v1/ / sk-XXXXX) - this trio is a second, smaller LLM call this tool makes internally, separate from whatever model is driving your main agent. My read: it's what translates the agent's plain-language ask into an actual SQL query before it touches your database - the same base_url-ending-in-/v1/ pattern the README uses everywhere else in this pack for API config.
• is_enable - the standard skip switch.

The single output, tool, is the packaged capability - wire it into tool_combine or tool_combine_plus, not directly into anything that expects real query results.

Installing it

Search comfyui_LLM_party in ComfyUI Manager, or clone it manually:

cd ComfyUI/custom_nodes
git clone https://github.com/heshengtao/comfyui_LLM_party

Then pip install -r requirements.txt inside your ComfyUI environment and restart. This is a big all-in-one pack, so expect a heavier install than a single-purpose node set - if you only need API-based LLM calls and not local model loading, the README's only_api branch is a lighter alternative.

Common issues

Same landmine as any node here that touches a database: db_connection_string has to actually be reachable from wherever ComfyUI is running, not just correct-looking. A localhost connection string only works if the database is on the same machine as the executor. If you're running this on a remote box, make sure the database accepts connections from that host - firewall rules bite people here as often as typos do.

The second-model setup is worth being deliberate about, not just leaving on defaults: if api_key is still the placeholder sk-XXXXX when the agent tries to use this tool, the SQL-generation step will fail even though your main LLM node is configured fine - it's an easy thing to miss because the two API configs live on different nodes. And letting an LLM generate arbitrary SQL against a real database is worth treating with the same caution you'd give any tool that can write, not just read - know what permissions the connection string's user actually has before you hand this to an agent unsupervised.