Feishu Tool

This pack's plain feishu node sends a message every time the workflow runs - the send is baked into the graph's fixed order. This node is the same underlying webhook-post capability, repackaged as a tool an LLM agent can choose to call or not call, based on what it decides is happening in a given conversation. Same destination, very different control flow.

How it works

Feishu tool follows this pack's tool-node pattern, which you'll recognize if you've looked at its other _tool nodes: instead of doing the action directly, it produces a tool string describing the capability, and that string plugs into an LLM/agent node's tool-list input. At inference time, the model decides whether calling this tool makes sense for what the conversation actually needs - "notify the team this finished" or "flag this for a human" being the obvious use cases - rather than a Feishu message going out unconditionally on every single workflow run.

The inputs and outputs that matter

• is_enable - the pack's usual bypass toggle; turn it off to pull this tool out of an agent's available toolset without deleting the node.
• key_word - required, and it's the same Feishu concept as on the plain feishu node: the security keyword your Feishu group's custom bot requires in any message it accepts. It has to match whatever the group's webhook settings actually enforce, or messages the agent sends through this tool get silently rejected on Feishu's end.
• Optional url - presumably a target/webhook reference; leave it unset if your setup only ever posts to one fixed destination.

One output: tool, a string, feeding into an agent node's tool list exactly like this pack's other _tool nodes (DuckDuckGo Tool, Wikipedia Tool, and so on).

Notably, this tool version only carries key_word and url - no app_id/app_secret fields like the pack's fuller Feishu bot nodes (FeishuSendMsg and friends) have. That means it's built on the simpler webhook-bot auth path, not the registered-app path - appropriate for a tool whose job is a quick one-way notification, not reading history or managing a real conversation.

Where it fits

Give an agent this tool alongside whatever else it has access to (search, file tools, other app-link tools) and it becomes one more action the model can reach for autonomously - "if something's worth flagging, post it to Feishu" as agent behavior rather than a scripted step. It's the tool-calling sibling of the plain feishu node the same way duckduckgo_loader/duckduckgo_tool split into a fixed step versus an agent-callable one.

Installing it

Standard pack install, nothing extra for this node:

• ComfyUI Manager: search "comfyui_LLM_party", install, restart.
• Manual: cd ComfyUI/custom_nodes && git clone https://github.com/heshengtao/comfyui_LLM_party, then pip install -r requirements.txt from inside the pack folder using ComfyUI's Python, then restart.

You'll also need a Feishu custom bot set up in the target group to get the webhook this tool posts to and the keyword it needs to match - same one-time Feishu-side setup as the plain feishu node.

Common issues & troubleshooting

Agent never calls the tool. Check is_enable is actually on and the tool is genuinely wired into the agent node's tool-list input, not just sitting unconnected in the graph - a tool node that isn't plugged into the agent simply isn't part of its available toolset, no matter how well-configured it is on its own.

Agent calls it, but the message never arrives in Feishu. Same failure mode as the plain feishu node: a key_word mismatch is the most common cause, and Feishu drops the message silently rather than surfacing an error back through this pipeline.

Want more than a one-way notification - reading replies, targeting a specific person, sending richer message types. That's past what a webhook-based tool can do; look at this pack's app-credential Feishu bot nodes (FeishuSendMsg, FeishuGetHistory) instead, which need the heavier setup but aren't limited to posting into one pre-configured group.